We were using a given tempo or meter point as part of the metric used when
recomputing its position. In fact, the metric should be only use the
tempo/meter immediately preceding the given point.
This splits apart the actual signal handler from the work that needs to be done
to update the GUI in response to a tempo map change. This allows us to do the
visual update when we are manipulating the thread-local write copy of the map
during e.g. a drag operation.
It is more useful to get the actual TempoPoint than just the Tempo
that we discover.
Aside: it would be awesome to understand how to use boost::intrusive to get the
next tempo point directly from the tempo hook.
On M1, the cross-thread channel sets G_IO_PRI in addition to G_IO_IN
this breaks various assumptions in receivers, which test for ~G_IO_IN
as error condition.
We modify elements of the source object, not to mention the peakfiles on disk. This
was a regression introduced when switching from Lock to RWLock, caused by a failure
to recognize this as a case where a write lock was required.
The presence of scoped_array<> as a member of AudioSource (peak_cache) is suspicious
nevertheless, and we should establish that it serves a useful purpose.
This is in preparation to always show a line, which show
the current value in case there are no automation points yet.
It also unconditionally snapshots the current value without
changing automation modes to touch/write first.
Return from poll_for_request() when CrossThreadChannel is
closed/destroyed. -- see also f4166fb61d
This also cleans up poll API usage, and check for nonnegative
return value is added.
This is mainly relevant for Mixbus, which allows cyclic-connections
to record Master-out on a Track (which unconditionally has Mixbus send
and feeds master).
In Ardour it may also cause issues when creating loopback connections,
however latency is not usually updated with invalid graphs (old
process graph remains in use).
Otherwise it fixes a crash connecting Track 1 -> Track 2 -> Track 1.
This also optimizes Route::output_effectively_connected by caching
any prior lookup. This helps e.g. Track 1 -> Track 2 -> Master.
The connection "Track 2 -> Master" now only need to be looked up once.
See also 7958031287 and a556e96ed0
The virtual keyboard sends all events with the same timestamp.
When playing fast (mouse-sweep) note-on and note-off will have
the same timestamp.
Since dbd8089fb8, a393f75694 concurrent MIDI are sorted with note-off
first. This correctly handles events when played from the timeline:
note-on .. note-off|note-on ... note-off
But in case of a MIDI keyboard a note-off event must be send after
the note-on.
