Midimessage iterator seems not to retrieve multiple messages on a same timestamp


Ok One more. So I’ve got this sampler pretty much set up but when I tried to actually use it in Reaper, applied a midi clip with a drumloop…

The midinotes that happen absolutely at the same time, won’t all come through the synthesizer. Just the last one gets played. Even tho they’re on different channels and synthesizers.

I’ve got a noteOn override that removes the stopvoice-method from happening and instead the startvoice just uses notestealing if needed.

If I input 1 message to all channels(synths) they all play simultaneously it so it’s not about that…

Does the midimessage iterator work like it should, retrieving ALL the notes even if their timestamp is identical? It feels like the problem is at that point…

No, that’s not the problem, it definitely does iterate all notes. (You could just have looked at the code for that method if you wanted to make sure of that).

Most likely it’s just voice-stealing that means you don’t hear the earlier ones. (Or possibly the host isn’t even sending the previous note events?)


So if i understand correctly, you’re not sending any note off events at all? If it’s not just a polyphony-based note-killing problem, perhaps the problem stems from the same note-on being sent twice without an intervening note-off? I haven’t checked, but maybe Reaper will sanitize this to avoid potential stuck notes.

If so, I have two suggestions that may help:

  • Queue up note-offs to be sent automatically after a certain interval (set just beyond the maximum length of drum samples you’re using) and/or
  • Send a quick note-off just when the same note is sent again.

To do this you’d need to keep suitable records and avoid sending extra note-offs if both scenarios interact.

I’ve also had problems with Reaper missing MIDI events, but mine were either from using the old while syntax in JSFX or concerning text meta-events (0xFF), which Reaper doesn’t propagate externally for fear of reset.

Good luck!

Jules sorry for doubting… :slight_smile: Well I’m still at a noob level with C++ so I wouldn’t understand the whole code even if I wanted to!

Turns out there was a good ol’ bug/typo in my code… For-loop missed the { } bracets thus running the iterator for only the first line of code… So, no wonder it only output just 1 midi message per buffer, then. :smile:

Sorry for occupying your time.

Btw Jules, You’re the dev on this API? Incredible work, since even I can make functioning VST’s with it even if I don’t have but very little experience on C++!!

ijijin, yes that’s correct I’m not sending note Off’s this far, even tho, as above, that wasn’t the problem in the end. It fully functions now!

I’m wondering how bad thing it is not to send the note off’s in terms of plugin compatibility or functionality, buggy behaviour etc? I’m thinking about percussion midi system how it’s normally done. NoteOff would just increase computational stress of the plugin(not much but still), so if it’s not needed, I’d just leave it from happening since it’s easy at the same time. :slight_smile:

Thanks for all!!!

Thanks for the tips, I today found out that the samples were glitching during playback, harshly, and, the reason was the lack of note-offs, So I believe that multiple note on’s on a same note gave confilcts and resulted in audio glitching.

I created logic to check if the note’s playing and send a note-off just before playing it again. :slight_smile:

So, Note-offs are absolutely needed! :smiley: Thanks!


Sounds like a wise move. You’re welcome, and I hope it’s all working nicely for you now. :smile:

a Little update on this one:

After still battling this issue, I tracked the trouble elsewhere: in Synthesizer subclass noteOn override I had removed the stopvoice-part where it stops ALL the synthvoices playing the particular midinote that the noteOn is going to play. It seems that it wasn’t that wise idea, giving these audio glitches for a reason or another.

I just wanted to have the same samples play through on a same midinote despite there being multiple instances possibly at the same time. But in the end it’s quite trivial need for my plugin so I just decided to remove that behaviour for now and revert to the original, that stops all the voices of that particular note.

At the same time I was relieved a lot of trouble as it seems that this behaviour (stopping all the voices on 1 note during noteOn) removes the actual need for a note off event, as in, no audio glitching happening anymore. JUCE seems to handle the situation well even without note offs.

I’m not exactly sure what caused the glitches but for now it seems to be working great with this method!

Ok. Disregard everything on this topic, since my responses might not be solid. It turned out there are audio glitches in some of the wave samples I’m using!! There just were like a thousand of them so I didn’t look them all through as they were supposed to be prepared for this use by another dude.

Ha… ha… oh the Irony :joy: