Support multiple readers for MIDI source/model

Fixes the multiple reader issue #6541 properly without resorting to a
linear search kludge.

All the read state has been pulled out into a MidiCursor which the
caller is required to pass.  The playlist keeps cursors for all the
regions it is reading, any number of cursors are allowed at a time.

MidiCursor should probably be made a smarter and more fool-proof
object (and/or possibly merged with some of the other tracker/fixer
stuff) but for now I wanted to keep it simple.

1 files changed, 2 insertions, 4 deletions

diff --git a/libs/ardour/midi_model.cc b/libs/ardour/midi_model.cc
index c94fb5ec17..80bc38cb0b 100644
--- a/libs/ardour/midi_model.cc
+++ b/libs/ardour/midi_model.cc
@@ -1455,8 +1455,7 @@ MidiModel::sync_to_source (const Glib::Threads::Mutex::Lock& source_lock)
 
 	/* Invalidate and store active notes, which will be picked up by the iterator
 	   on the next roll if time progresses linearly. */
-	ms->invalidate(source_lock,
-	               ms->session().transport_rolling() ? &_active_notes : NULL);
+	ms->invalidate(source_lock);
 
 	ms->mark_streaming_midi_write_started (source_lock, note_mode());
 
@@ -1625,8 +1624,7 @@ MidiModel::edit_lock()
 		   Add currently active notes to _active_notes so we can restore them
 		   if playback resumes at the same point after the edit. */
 		source_lock = new Glib::Threads::Mutex::Lock(ms->mutex());
-		ms->invalidate(*source_lock,
-		               ms->session().transport_rolling() ? &_active_notes : NULL);
+		ms->invalidate(*source_lock);
 	}
 
 	return WriteLock(new WriteLockImpl(source_lock, _lock, _control_lock));