A Gtk::manage()d widget will be deleted when its parent container
is destroyed. Top-level context menus are not inside a container and
hence need to be manually deallocated.
The solution here is to use a shared Gtk::Menu pointer that is
centrally de/re-allocated.
This works because the GUI is single-threaded and at most one
context menu is visible at a time.
Leave the user in control while the slider is being dragged.
Previously there was a feedback loop:
User-drags slider -> value changes -> value is rounded
-> slider is updated with rounded value (while the user still drags)
Don't call ::set_value() if the actual value has not changed.
e.g. MIDI-CC or integer controls. Moving the Bar-controller was able to
create events even though the actual value remained unchanged.
This check has to be done UI-side, since the underlying API is also used
for state-restore and automation. e.g.
"old value" (user-set) may be default "0", "new value" may also be "0" but
libardour still needs to send an event (a synth's internal state may not
default to "0")
smallstep (resp. largestep) is intended to be the interface delta
corresponding to a desc.smallstep (resp. largestep) in internal scale,
and is computed by incrementing from desc.lower.
But ac->internal_to_interface(desc.lower) isn't necessarily zero. In
fact it currently is 0.5 / (M - m + 1) for integer parameters where M is
the maximum and m is the minimum possible value since it is the center
of the [0,1/(M-m+1)] interval.
Since the lower bound of the delta isn't always zero, don't ignore it
when computing the actual increment.
Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
Depend on Changed() signals alone, which are usually much less frequent
than rapid-timer events.
As side-effect we now need to make the widgets insensitive when
playing automation. Previously the user could not change the value because
the Timer periodically reset it.
This reverts commit b3722f7063.
In some cases ardour shows context-menu on right-mouse-button
release. In this case selecting a menu-entry should happen
with the left-mouse button (or any button?!)
Using ev->button is only correct if the menu is temporary and only
visible while the button is held, button release then activates the
menu-item.
This needs further work, in some cases allowing any button (0) to work
makes sense and overall consistency needs to be improved.
Different places use different strategies for context-menus which
don't always match the button used in the event-handler.
This is a hotfix (to make TAV context menus work again with left-click)
Stop event propagation. Otherwise, on release the event is passed
up and handled by the TAV which scrolls the editor viewpoint
and the button is no longer under the mouse.
controllable->set_value() from GUI context will eventually queue
a session-rt command. By the time the realtime command runs, the
controllable needs to be in "touch" mode.
The AutomationController "toggle" UI worked around this by directly using
the underlying API (ignoring slaved-controls and ignoring groups).
The RouteUI's GUI wasn't able to write mute-automation at all.
This commit is a compromise: press + hold (touch) + release button.
(it may need further special-casing for _desc.toggled in
AutomationControl::actually_set_value(), also undoing automation-writes
is currently not working correctly)
- adds quarter_notes_per_minute(), note_divisions_per_minute (double)
pulses_per_minute() and frames_per_quarter_note()
- this should be a no-op except for the use of tempo by
the vst callback which definitely uses quarter notes per minute.
- the XML node for TempoSection named 'beats-per-minute'
has been renamed.
This also removes Route::group_gain_control() and associated machinery.
Not yet tested with Mackie or other surfaces. More work to done to
start using the group capabilities, and also potentially to add
or derive more controls as RouteAutomationControls
- don't attempt to insert two points on toggle.
- remove forced touch->write mode change on toggle
- initial state still wrong, but works much better overall.
- don't keep setting/unsetting write pass when transport frame
remains the same (think larger jack buffer sizes)
- insert guards are now 64 frames after when.
- refactor previous approach.
Shoot for roughly 30 steps for all controls.
Always keep sensible step information in ParameterDescriptor and just convert
for the UI.
This is a little weird, but it's less weird than it was before, and works.
