summaryrefslogtreecommitdiff
path: root/libs/ardour/ardour/audio_track.h
diff options
context:
space:
mode:
authorRobin Gareus <robin@gareus.org>2020-03-15 13:31:53 +0100
committerRobin Gareus <robin@gareus.org>2020-03-15 13:34:13 +0100
commit7f862298cfa4c11309a4fb8a5526f17c135c98cd (patch)
tree0237db3922dc677ffb54fa8bbfac0d727a9db444 /libs/ardour/ardour/audio_track.h
parent213b3cd59317176e94c451edecdf0eba0a26aeaa (diff)
Fix loading playlists of old sessions
Previously when loading Ardour v2, v3-5 sessions, tracks were created with a dummy name "toBeResetFroXML". In v6, Track::init() creates a playlist when the track name is not empty. Later Track::set_state() calls set_name(). When a playlist exists, the playlist's name is set to match the track's name. When loading v6 sessions none of this happens. A previously loaded playlist will be assigned by ID. Older versions identified Playlists by name and by the time the playlist is assigned, there may be ambiguities. With the default (track-name = playlist-name) two playlists with the same name exist: (1) the playlist loaded from the session file (2) the playlist created by Track::init() Playlists are stored in an ordered std::set<shared_ptr<Playlist>>, and name-lookup iterates over the set. When loading an old session after starting Ardour, it is very likely to always lookup the playlist (1), because new, later allocations from (2) are on top of the heap and ordered last. The session seemingly loads correctly, except for lingering, unused empty playlists "toBeResetFroXML" renamed to "Track name" that were never deleted. However when loading an old session from a running instance, ordering is mostly random, and many tracks end up with using the empty playlist (2) instead of the correct playlist (1).
Diffstat (limited to 'libs/ardour/ardour/audio_track.h')
0 files changed, 0 insertions, 0 deletions