MidiMessageCollector suspicious code?

General JUCE discussion
1

Hi

I’m on iOS and testing with some external MIDI hardware. When the hardware is disconnected, I send an internal MIDI ‘all notes off’ to prevent any hanging notes, adding the event to MidiMessageCollector with the current timestamp. This same bit of hardware has an audio interface, so iOS also has to spend a bit of time sorting out its Audio Sessions when it disconnects. This extra ‘offline’ time seems to result in my MIDI message going missing, which I’ve managed to trace to MidiMessageCollector::removeNextBlockOfMessages:

            const int maxBlockLengthToUse = numSamples << 5;
            if (numSourceSamples > maxBlockLengthToUse)
            {
                startSample = numSourceSamples - maxBlockLengthToUse;
                numSourceSamples = maxBlockLengthToUse;
                iter.setNextSamplePosition (startSample);
            }

If I comment out this section it works fine. Firstly, the magic << 5 looks suspicious to me. Where does this come from? Secondly, it advances the starting point of the iterator and simply drops a load of MIDI events. Surely that’s going to cause problems? (stuck notes if they happened to be off events etc.)

Looking at the function as a whole, it doesn’t seem to do what I’d expect. By ‘removeNextBlockOfMessages’ I’d expect it to remove only the messages which fit in the time frame given and then leave any remaining ones in the incoming buffer for future (ie. more like a FIFO). Instead, it kind of squeezes/stretches all the incoming events into the given timeframe and then clears any remaining incoming data, or even drops events in the case above.

Have I misunderstood the rationale behind this function?

2

Maybe the name could have been chosen better… The idea is that the function is called to retrieve the entire contents of anything currently pending in the buffer, since it’s designed for buffering live input, and is expecting all kinds of bursty, badly-timed events to be arriving. If it left events behind in the buffer, it could start to overflow if they begin to drift out of sync.

Haven’t time to wrap my brain around exactly what your problem is or come up with a good answer, but certainly attempting to change that algorithm would most likely break things.

3

See also this thread: http://www.rawmaterialsoftware.com/viewtopic.php?f=8&t=9946

(as a result I have commented all this code in my juce tree)