I’m writing a piano roll. The piano roll basically manipulates a MidiMessageSequence (I think that this is a common approach with Juce). I’m now at the stage where I’m inserting new midi notes, and it’s working apart from a one situation. Here’s what I’m doing at the moment:
// create new midi note and add it to the sequence juce::MidiMessage noteOn(juce::MidiMessage::noteOn(kMidiChannel, noteNum, kVelocity)); midiSequence.addEvent(noteOn, ticks); juce::MidiMessage noteOff(juce::MidiMessage::noteOff(kMidiChannel, noteNum)); midiSequence.addEvent(noteOff, ticks+noteLength); midiSequence.updateMatchedPairs(); // tell the midi message sequence to connect the note-on and note-off messages
This works fine, unless we have the following situation (the timestamp values are just for illustration):
 My sequence has an existing note that plays from timestamp 100 to timestamp 200[/]
 I then add a new note (on the same channel, at the same pitch) that plays from timestamp 110 to timestamp 120[/]
The problem is that when I call MidiMessageSequence::updateMatchedPairs after adding the second note, it truncates the first note, so the first note is from timestamp 100 to timestamp 110, and the second note is from timestamps 110 to timestamp 120. (What I want is for the first note to be unaffected by adding the second note).
Reading the source for MidiMessageSequence::updateMatchedPairs it appears that the current behaviour is by design, which makes me wonder if I’m going about things the wrong way.
A simple solution would be to change MidiMessageSequence::addEvent() so it returns the index (or the pointer) of the MidiEventHolder object that it has just inserted into the sequence. This would mean that I could manually set up the MidiEventHolder::noteOffObject member of my new note-on event. This also has the benefit of preserving the current behaviour of MidiMessageSequence::updateMatchedPairs, which lots of people’s existing code will no doubt rely on!
Jules, do you think my suggested change a reasonable request?