This can happen when a device is already connected
while Arodur is stating. The butler thread may activate it
(immediately post-engine), while the GUI thread tries
to do the same later when restoring state.
* correctly handle clicks on the immediate right or left of a beat line
* prefer Mid-Twist and End-Stretch terminology over Twist and Linear
* static-tempo vs ramped-tempo is orthogonal to mid- and end- drags (TODO)
Old code use the TempoMetric (Tempo + Meter) in effect at the old
location of the tempo/meter to compute the position of the edited tempo/meter,
using a BBT time from the dialog.
But this TempoMetric uses the very tempo/meter that we're editing!
So we have to use previous_tempo() or previous_meter() to construct
the relevant TempoMetric, and if it is the first tempo or meter, then
obviously it cannot move position at all.
* reserve "probe" to actually probe for devices
* use separate probe for libusb and MIDI port devices
* use "available" to check if surface can be used
* allow both methods to be NULL
* remove unused ControlProtocolDescriptor* argument
Most surface just return `true` for available.
In case of internal backends this allows to retrieve the
Device name for a given (hashed unique) port-name.
As opposed to "pretty-name" (which defaults to hw-port-name),
this cannot be changed by the user.
It is intended to be used when probing for control surfaces.
* in the 'fake_drag' case (dragging the playhead from the ruler), the
mouse events are delivered to the playhead during the drag so we need
to temporarily sensitize the playhead during that operation, then reset
the sensitivity via config
Historically, it was possible to grab the 1-pix-wide red line, and drag the playhead
In rare but annoying cases, the red playhead interferes with mouse clicks, because it is on top
De-sensitize the playhead by default, and provide a new config var for those who want the old operation
Don't clear the processor box selection when leaving for
a non-linearly related widget/window (e.g. a context menu)
Note that the deselect is a little buggy but that was
true before the referenced commit too. If you move the mouse too
fast out of a processor box, then depending on where the
mouse stops, no leave notify message is sent
In case there are any unconnected tracks, the track's output is
assumed to align to the master bus (see Route::update_signal_latency).
For this to work correctly the master bus port's public latency
has to be set first.
This fixes e.g. the following issue: add a latent plugin to
the monitor section. Then toggle its bypass or remove it.
Previously the worst-case latency remained unchanged.
Bindings were not loaded until after ProcessorBoxen were created,
meaning they had no effect (the ProcessorBoxen set their ardour
bindings to null).
Also handle leave-means-deselect at ProcessorBox level rather than
MixerStrip level, to include MonitorSection PB
VST3PI::performEdit already updates the shadow data, so
since 979f9876a7
VST3Plugin::set_parameter effectively did nothing (unless a user
rapidly moves the control slider, in which case the next process
cycle sets a previous value).
We now use the same actions in all modes, and the logic is:
1. is there a selected mixer strip and are we in it: if so, delete selected
processors
2. are we in draw or internal mode? if so ..
2a. if there are selected control points, delete them
2b. if not, attempt to delete MIDI notes
2c. done
3. continue with delete operation as before
Robin Gareus
Paul Davis
Ben Loftis
Alexandre Prokoudine