Weird behavior with the drums?

MIDIbox FM
1

I just ran into an odd issue with the drums where if I setup a bunch of 1/16th’s notes for the closed hi-hat or bass that they would often drop out every 1-3 notes. Is this normal? Oddly enough if I have both the bass and hi-hat doing just 1/16th notes, it works as advertised - mostly. Occasionally there is a drop here or there but mostly they both work as they should.

I thought it might be a polyphony thing but even soloing just the hi-hat or drum and playing nothing else has this affect. It doesn’t seem to happen when playing on one of the instrument channels - just the drums, so I don’t think it’s a MIDI issue.

I’m feeding the synth using a GM5x5x5, Ableton Live, and OS X.

Thoughts? Amidoingitrite?

2

I use osx 10.6.7, ableton suite, and gm5x5x5 triggering a jomox xbase 999 never had notes dropping out. So something with the synth i think?

3

That is my thought, I’m just not sure what would be causing that or if I’m running into a known issue or really what’s going on there :slight_smile:

4

That is my thought, I’m just not sure what would be causing that or if I’m running into a known issue or really what’s going on there :slight_smile:

I have a similar problem with my mbfm hanging notes far too often. I think maybe its a short somewhere?

5

I don’t think my case is a short because using both the bassdrum and hi-hat makes the problem go away; and using normal instruments work just fine using the same 1/16th note repeating pattern. I tried it on my Windows box and same problem. I also tried adjusting the BPM down and up and it doesn’t change the drop-outs (they get rhythmically faster or slower matching the BPM).

The MP3 I’ve attached illustrates what I’m talking about. You can hear the bass drop out followed by the hi-hat. Both have the same dropout pattern more or less. Then both come in and the output is more consistent (I think there might be one drop). Then I do a standard instrument and you can hear no drops, followed by the whole lot.

If it were some sort of issue like short, I would have expected other behavior, but I’ve been wrong before :slight_smile:

Anyone else able to reproduce this test? I can provide my Live project file but all I’m doing is 16th notes in an 8 bar pattern for the bass, hi-hat, both, and then a lead. All straight 16th notes at 120BPM (though I tried 90 and 150, same exact phenomenon).

[sammichFMDrumTest.mp3](< base_url >/applications/core/interface/file/attachment.php?id=8729)

6

I can’t reproduce this issue, but for me it sounds like a firmware issue…

It could be related to OPL3 register access modifications which have been made for sammichFM.

Since they are slower than on the original MBFM design, and since interrupts are disabled while register values are transfered, incoming MIDI events could get lost.

I’m unable to test this by myself, as I haven’t got my sammichFM yet (seems to be stucked at german Zoll…)

However, I added a “blind change” in the hope that it helps - MIDI interrupt isn’t disabled anymore during register transfers.

Could you please check this version:

http://www.ucapps.de/mios/midibox_fm_v1_4b.zip

Best Regards, Thorsten.

7

Hi TK!

I tried the update and I think it sounds better but still seems to be dropping a lot of notes on the drum channel. I have attached an updated MP3 (this one is at 90 BPM instead of 120 BPM in case that helps). Guess we may have to wait and hope that your sammichFM arrives :slight_smile:

Either way, thanks for taking a look!

[sammichFMDrumTest2.mp3](< base_url >/applications/core/interface/file/attachment.php?id=8730)

8

TK, can you reproduce the issue with your MB-FM by enabling the extra instructions that write bits to port E?

It always writes the full byte to port B, so you would still get sound, this would just let you reproduce it and prove the extra three instructions cause the problem (the two blocks wrapped by #if ENABLE_MBNET in MBFM_REG_Write). If I’d known this would be a problem I would have scrapped the future support for MBNET and just stuck with port B connection to OPL3… :blush:

9

If I’d known this would be a problem I would have scrapped the future support for MBNET and just stuck with port B connection to OPL3… :blush:

Don’t worry, I proposed the PIC18F4685 because I knew that if necessary modifications would cause timing issues, the OPL3 register transfer routine could be optimized by putting it into a macro instead of a subroutine. This method would be possible thanks to the higher amount of available code memory, and it would save at least 6 cycles per register write. This would more than compensate the delay caused by PortE accesses.

(I haven’t tried it yet, and I haven’t checked if emulating the delay would help to reproduce the issue - I prefer to test it on the real device, because it can’t be excluded that the problem happens because of a programming error somewhere else :))

Are you able to reproduce the issue?

Best Regards, Thorsten.

10

Are you able to reproduce the issue?

Unfortunately yes… :huh:

11

Even with MBNET enabled it works fine at my side, just listen to this mp3

http://www.ucapps.de/tmp/mbfm_drum_test.mp3

Of course, I also tried BD or HH only, with different patterns, etc… this was only the final stress test :wink:

I’ve no glue, I have to test this on the original hardware to search for the failure mode.

Best Regards, Thorsten.

12

Hehe, Aphex Twin would be proud of you :wink:

13

I blame nILS then… :whistle: sammichFM was entirely his idea, I’m just the monkey that puts parts in boxes.

14

I tried the update and I think it sounds better but still seems to be dropping a lot of notes on the drum channel. I have attached an updated MP3 (this one is at 90 BPM instead of 120 BPM in case that helps). Guess we may have to wait and hope that your SammichFM arrives :slight_smile:

My base board is up&running, and I’m ready to test the “critical sequence”.

Could you please create a MIDI (.mid) file which causes the failures at your side, so that I’m able to reproduce this under the same conditions?

Best Regards, Thorsten.

15

Hi TK!

Will do! I’m up on a business trip so it may take me a day or two to get this to you. Just standard MIDI or would you prefer an Ableton Live set?

16

I would prefer standard MIDI to avoid DAW version dependencies (I’ve no Ableton Live installation anyhow and would have to install a demo version)

Best Regards, Thorsten.

17

Ok noted. I’ll post that as soon as I can!

18

Finally I was able to reproduce the issue! :slight_smile:

Previously I used MBSEQ in drum mode (or a MIDI keyboard) to play the drums.

MBSEQ plays the notes with 75% of the step length, with a MIDI keyboard the note length typically isn’t shorter than 10..20 mS

Today I used normal play mode instead, and came to the idea to vary the gatelength.

It turned out, that drum triggeres were sporadically missing with minimum gatelength (where MIDI Note On/Off are sent back-to-back).

So, the root cause is totally clear: in such a scenario MBFM set and cleared the gate before updating the OPL3 register -> no drum played.

It was sporadically played if there was a small gap between Note On and Off command.

However, I noticed that for OPL3 it doesn’t matter how long the gate flags are set, the drum instrument is always played with the same envelope.

Therefore I changed the handling from “gate” to “trigger” flags, and now it seems to work stable.

Please try midibox_fm_v1_4c

Best Regards, Thorsten.

19

I’ve just tested v1.4c with FL Studio and tempo up to 999 and there are no dropped drum notes at all.

Nicely done, TK! :smiley: :cheer: I owe you zwei Biere.

So now I can stop worrying that the sammichFM design is flawed.

20

1.4c did the trick for me as well. Thanks TK, Wilba, nILS and anyone else that had a hand in the sammichFM!