dramatic change in logic and naming for operations related to adding a MIDI region on demand and cloning/unlinking

Existing code would cause data loss due to creation of two Source objects referring the same path, one with removable flags and one without. Careful code review suggested a variety of thinkos, function naming problems and other confusion that caused this. I have tried ot extensively comment what is going on with these operations, because it is one key area in which MIDI differs from audio: with audio, capture is the only way to add a new audio region, but for MIDI there are GUI input events that can add a new region.

1 files changed, 12 insertions, 6 deletions

diff --git a/libs/ardour/midi_diskstream.cc b/libs/ardour/midi_diskstream.cc
index 6fd40be57b..fdf155d78b 100644
--- a/libs/ardour/midi_diskstream.cc
+++ b/libs/ardour/midi_diskstream.cc
@@ -1198,7 +1198,7 @@ MidiDiskstream::use_new_write_source (uint32_t n)
 
 	try {
 		_write_source = boost::dynamic_pointer_cast<SMFSource>(
-			_session.create_midi_source_for_session (0, name ()));
+			_session.create_midi_source_for_session (name ()));
 
 		if (!_write_source) {
 			throw failed_constructor();
@@ -1223,13 +1223,19 @@ MidiDiskstream::use_new_write_source (uint32_t n)
 std::string
 MidiDiskstream::steal_write_source_name ()
 {
-	std::string our_new_name = _session.new_midi_source_name (_write_source->name());
-	std::string our_old_name = _write_source->name();
-	
-	if (_write_source->set_source_name (our_new_name, false)) {
+	string our_old_name = _write_source->name();
+
+	/* this will bump the name of the current write source to the next one
+	 * (e.g. "MIDI 1-1" gets renamed to "MIDI 1-2"), thus leaving the
+	 * current write source name (e.g. "MIDI 1-1" available). See the
+	 * comments in Session::create_midi_source_for_track() about why we do
+	 * this.
+	 */
+
+	if (_write_source->set_source_name (name(), false)) {
 		return string();
 	}
-
+	
 	return our_old_name;
 }