search

bitfieldaudio / OTTO

Sampler, Sequencer, Multi-engine synth and effects - in a box! [WIP]
https://bitfieldaudio.com
Other
2.63k stars 142 forks source link

MIDI buffer to `local_vector` #158

Open jmidt opened 4 years ago

jmidt commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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