Non-allocating MidiMessageSequence

General JUCE discussion
1

Is there a technical reason why MidiMessageSequence internally uses an OwnedArray and allocates the MidiEventHolder objects on the heap?

I’m using it internally as a cache mainly because it has the extremely useful createControllerUpdatesForTime method but those allocations make it unsuitable for real-time use.

If it had a clearQuick method and used an Array or std::vector internally (and maybe a reserve would be helpful) I wouldn’t have to rewrite everything to use another type of container…

If I submitted a PR which doesn’t break the API would it likely be accepted?

2

I was under the impression that it was because MidiEventHolder holds pointers to the note off object, so using stack objects would invalidate that pointer when the container is resized/moved/copied/etc.

But I agree with you, and had to write my own version of similar containers multiple times. Usually I also prefer to store the begin/end objects as one element too, without pointers to each other, which makes operations easier.

3

I see what you mean.
I guess that could become a function without too many breaking changes.

I guess it can’t be done without moving the overhead elsewhere to update the matching note-off indicies when the sequence is resized/moved/copied/etc.

I’ll take another look at my code and see if I can work around the createMessagesForTime use.