MIDI buffer to local_vector

[jmidt]

To have an upper limit on how many new notes can be triggered in every audio buffer, We should probably limit the number of midi messages in the ProcessData (or whatever form it survives in) to some reasonable number.

We could then have a separate ringbuffer for unsent midi-messages, that are waiting until the next audio buffer starts.

[topisani]

I was looking in to this right now actually. I'm not really sure what the best way to do it is...
I would probably say, at least limiting it to 128 is totally doable. And in that case, i think we can also just discard any extra messages...

The main issue probably comes back to allocation and the use of ProcessData and AudioBufferHandles. I think it makes sense to refactor both at once.

[jmidt]

I get the ideological point in having a limit, and also for pre-allocation purposes. But 128 is so high it doesn't address the performance aspect of it. I was thinking in the range of 10-20 messages. We might even just decide to discard extra messages at that point. We are working with quite small audio buffers anyway.

[topisani]

128 would probably be fine, performance-wise. It is mainly to support weird external MIDI usage, like sending a note off for every note instead of using the STOP_ALL function.

I would probably use a solution like we use for the audio buffers.

it doesnt really matter anyway, when we have the solution for this, we can pick a number out of a hat