At present, TempoTwist is Primary-drag on the tempo ruler, and TempoCurve is Primary-drag on the meter
ruler. Not sure that this is quite what we want here, but it makes more sense than the prior
design, in which TempoTwist was available from non-tempo-related rulers
This avoids breaking bindings, and since the action name is generally not a part of the GUI,
really doesn't hurt anything in terms of understandability
An attempt to satisfy #8848.
Add a new action, "fork-regions-from-unselected", which unlinks all
selected MIDI regions from any unselected regions, but maintains links
within the selection, and add the new action to the region MIDI context
menu as "Unlink from unselected". Rename the existing "fork-region" action
to "fork-selected-regions", and amend the existing "Unlink from other
copies" menu item to "Unlink all selected regions" to (try to) clarify the
difference.
Attach the <Tertiary>U default key-binding to the new action: I personally
think it's generally slightly more useful (otherwise I wouldn't have
implemented it), though I'm not that fussed.
In the case that there's only one MIDI region selected, or that none of
the selected regions are mutually linked, both actions will have exactly
the same result. Ideally, we'd only show a single menu item in this case,
but that would require (a) implementing a function to check whether the
selection contains any linked regions, and (b) making the region MIDI
context sub-menu dynamically generated, so that it can change based on the
result of that function, neither of which I've tried to do yet.
The fix here is really just dropping the use of _offset when computing the session position
of a control point. This was just an arithmetical error.
However, session_sample_position() was redundant and just caused more work, so this
method was removed, and only ::session_position() is now used.
In addition, several closely related places now use C++11 (or later) "auto"
syntax for iterating over containers, for cleaner looking code
In case a user manually renames a session-folder and snapshot
it should still be impossible to delete the last snapshot
even if it is not named after the session-dir.
In theory this is impossible (one cannot delete the current snapshot)
Previously this setting was ignored. It is relevant when loading a demo
session, where initially there is no user Config instant.xml.
ARDOUR_UI::setup_windows is called directly after the engine starts, but
before the session is set.
Region actions are generally set insensitive whilst recording, so
special-case the "add-region-cue-marker" action by explicitly enabling it
when starting to roll in record. Additionally, the action becomes disabled
again after it's been executed, so re-enable it after queuing the cue when
recording.
This allows new user to select the soundcard and I/O settings
when loading demo sessions at first run, or when tricking Ardour
to open an existing session (try to create an existing session,
user may choose to load it instead).
Normally a user can only create a new session after first running
Ardour, and creating new sessions always shows the dialog (to
set the samplerate).
When loading the very first session is canceled (e.g.
sample-rate mismatch -> Do not load session) or fails otherwise,
execution returns to the startupFSM.
Loading another session after that then takes the same path again:
StartupFSM::dialog_response_handler() -> StartupFSM::engine_running()
-> ARDOUR_UI::attach_to_engine()
The call needs to be idempotent, otherwise setup_windows(),
create_editor() etc are called a second time and Ardour crashes.
Found via `codespell -q 3 -S *.po,./.git,./share/patchfiles,./libs,./msvc_extra_headers,./share/web_surfaces,*.patch -L ba,buss,busses,discreet,doubleclick,hsi,ontop,ro,scrollin,seh,siz,sord,sur,te,trough,ue`
Previously no unmap events were delivered (due to a bug in
Gtk EventBox), `lower_box_map` was called only once.
Furthermore when cross-compiling (ARM binary on Intel),
COCOA_LIVE_RESIZING was not detected.
see also df21698ea7
Rosetta bridge plugins have an initial size of 0x0 pixel.
Ardour's AU window size is set relative to the previous size. So the
window grows by the actual real initial size of the AU View.
However the window is already allocated and has a non-zero width given
by the plugin's toolbar.
This lead to oversize windows.
* Fix demo-session glob (missing "*" + session_archive_suffix)
* Copy demo-session also when copying settings from older version
* Also add demo-session to recent-list if it was previously unpacked
for new major versions.
This should fix a long-standing issue with interleaved display
of clients since jack_get_ports() does not return a well defined order.
(Internal backends based on Ardour::PortEngine keep ports sorted)
In case of MIDI CC/Bend/Pressure etc events, the underlying
data is provided by a MidiTrack (is-a Automatable) and not
an automation-control.
When directly calling AutomationControl::set_automation_state,
the AC disables automation-watch using shared_from_this().
With the Evoral::Control used for MidiTrack event-lists this
results in a tr1::bad_weak_ptr.
Locations::ripple() skips these markers when the ripple action is committed.
...but the editor moves the marker-items as a visual aid, before actually
committing the changes to Locations()
...so the editor needs the same logic, to avoid visually inconsistent behavior
In case of auto-scroll it is apparently possible that the
move_threshold_passed, but ::motion() is not called.
There already is an explicit _starting_point_passed variable
that is set when first_move occurred. So far it was just unused.
when dragging their location
* it should be possible to launch an arbitrary (non-quantized) sound
'anytime' on the timeline
* this was already possible anyway, by switching the Grid to None
When no movement has occurred, TrimDrag::motion was never called
and `begin_reversible_command()` was not called. There is nothing
to undo. This fixes
`commit_reversible_command(Command*): Assertion `_current_trans' failed`
This also fixes Menu > Edit Delete "delete MIDI" operation.
Pressing backspace/delete calls "Delete Selection" which is
unrelated to MRV::cut_copy_clear.
Gtk::manage only destroys managed widgets when the parent container
is destroyed. In Ardour's case this is not the case since
Gtkmm2ext::container_clear() is used to unpack/repack widgets
as required.
The Monitor Model usually depends on the studio setup (hardware
mixing desk), but also to some extent on the audio interface (zero-
latency monitoring). Since a user may also use different interfaces
(e.g. with a laptop), it makes sense to expose the monitor model
preference in the engine-dialog.
NB. It is not part of the engine-state (!), but still a preference.
* Remove Monitor Model Option
* Remove Monitor Section Option
These days those can be toggled after setup, even while the
session is loaded and engine is running. There is no need to bother
a user very early on with this question about Monitoring.
This has no been useful since years. Both Ardour and JACK
backends always use all available ports and the setting was
only useful to "hide" excess ports.
A fully transparent waveform (with only a semi-transparent outline)
looks very odd with all themes.
Perhaps this was a typo and the initially intended rendering was
supposed to be 31% transparent, however this is not distinguishable
from non-opaque regions (27% transparency).
It connects to the ParameterChanged (sigc++) signal, and to ensure automated
disconnection on object death, sigc::trackable is required in the
inheritance tree
It connects to the ParameterChanged (sigc++) signal, and to ensure automated
disconnection on object death, sigc::trackable is required in the
inheritance tree
The track-header (gtk) is packed with 1px box spacing. This
is added at the top of each box (best seen by looking at the
group-tab vs track-header alignment in the editor).
However the actual track separator line on the canvas is at the
bottom of each track, aligning with the top of the next track
or automation-lane.
The first track however lacks a separator at the top, which
needs to be provided by the ruler. Once the canvas is scrolled
this ruler/canvas separator overlaps with the bottom separator of
each TAV.
Using ruler Rectangle::set_outline had various issues.
The outline extends outside the rectangle. It bled into the
video-timeline instead of the canvas' top y-axis pixel.
Also the separator was above the video-timeline, not above the
canvas. Hence a dedicated separator Line is preferable.
It also provides a consistent separator if no rulers are visible.
Before nutempo, ::find_next_region_boundary() used to return -1
when no boundary was found (now timepos_t::max is returned).
timepos_t::increment() returns the incremented value, not increments
the variable itself.
When a tempo map change originates from a drag, we know the required redraws have
already been done. Use a new bool member, ignore_map_change, to tell the Editor
to ignore the map change signal. For all other map changes, do the full reset.
We now simply move markers during drags, and do not seek to create/delete markers.
When the map is changed, we rebuild the markers from scratch. This might need optimization to avoid doing
when the editor itself changed the map.
Previously it was possible that the tempo-curve display was rendered
above a tempo-marker (e.g. create a marker in the between of existing
markers). With the tempo-curve in front, markers on the right
became inaccessible.
