Background thread now *must* set "done" as last step. (they already do
since various error conditions don't result in "done")
This fixes a race: background thread Session::write_one_track() sets "done"
to true. Editor::freeze_route () continues, sets current_interthread_info
to NULL. thread continues and tries to set current_interthread_info.done
before terminating -> Crash.
This also ensures that singleton threads created with
"pthread_create_and_store" remain unique.
Too many users report they import their first tracks and can't find them.
Previous default was "at file timestamp". If a file has no timestamp,
the import dialog shows "00:00:00:00" but in absence of a timestamp,
Editor::add_sources() first checks target tracks and adds add it after
the last region, then falls back to use preferred edit position as
insert point.
In the rare case where a file has timestamps it may show up a few hours
in the future.
conclusion: import-at-timestamp is not a good default.
* pressing Esc or WM close button did not cancel import thread
* proper Abort does not wait for import thread either
It was possible to launch a 2nd (and Nth) import thread, all sharing
the Editor's ImportStatus data-structure, all having the same
registered thread-name and same thread-pool name. Plenty of room for
crashes.
This can happen on OS X. Audio Units did not have
a MIDI bypass. Ardour adds an implicit bypass and existing
"unknown/missing" plugins after the instrument will see
a different i/o config.
opening a recent session from a session can result in: Editor::constructed
and session_loaded() being true. A partial instant_save can occur (not
to mention: invalid XMLnode iterators)