Replaces the list of points in TempoMap with TempoSection functions, which
compute tempo-at or tick-at time relative to tempo section start.
TempoMap consults them additively to determine things like bbt_time(),
frame_time() get_grid() etc.
This has a marked effect on scrolling speed along with the code simplification
in the places it has been attempted.
Several things are broken here.
Currently every ramp except the last one is an exponential ramp. this may
be simple to fix :).
Mouse-over midi grid doesn't match mouse click grid. should also be simple.
Many things seem to work, but their accuracy should be in question until
each area has been addressed.
* don't use a static struct. this fixes a concurrency issue with flags
and valid values
* send kVstTransportChanged IFF there is an actual change
* set system time
* send loop location
Various session rt-events set "_send_timecode_update" to true,
but at the same time queue post-transport-work.
The timecode-update is generated, but due to pending transport work
session->silent() is true and the timecode was never sent.
Moving the mouse over another region's gain line changed
clicked_regionview. clicked_regionview is used along with range-time
when initiating an AutomationRangeDrag.
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.
