Jump to content

Weird behavior with the drums?


m00dawg
 Share

Recommended Posts

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?

Link to comment
Share on other sites

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 :)

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

Edited by m00dawg
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :)

Either way, thanks for taking a look!

sammichFMDrumTest2.mp3

Link to comment
Share on other sites

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:

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ;)

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

Best Regards, Thorsten.

Link to comment
Share on other sites

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 :)

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.

Link to comment
Share on other sites

Finally I was able to reproduce the issue! :)

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.

Link to comment
Share on other sites

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! :D :cheer: I owe you zwei Biere. buy_beer_small.gifbuy_beer_small.gif

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...