diff options
author | Robin Gareus <robin@gareus.org> | 2020-03-15 13:31:53 +0100 |
---|---|---|
committer | Robin Gareus <robin@gareus.org> | 2020-03-15 13:34:13 +0100 |
commit | 7f862298cfa4c11309a4fb8a5526f17c135c98cd (patch) | |
tree | 0237db3922dc677ffb54fa8bbfac0d727a9db444 /libs/ardour/ardour/audio_track.h | |
parent | 213b3cd59317176e94c451edecdf0eba0a26aeaa (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