Constructing a playlist from another playlist plus an offset used the wrong
RegionFactory::create method. By failing to pass in the offset to the region
constructor, the newly created region gets its envelope (and possibly other
automation data) from the start of the existing region, not its own start.
* 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.
There was a logic error previously which failed to consider follow actions (and follow count).
Now we find a relevant cue, and use follow actions and follow counts as we move forward
in time
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)
This fixes an issue with LV2 plugin that unconditionally
initialize LV2 Atom ports even if they are not connected.
eg. JUCE7 produces LV2s at the time of writing.
The actual goal here is to use direct InterpolationStyle serialization
in MidiSource (identical to AutomationList). enum_2_string()
does not work for Evoral types.
As side-effect virtual base-classes have been changed to pass
Parameters as const references
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.
This fixes an issue when creating tracks or busses with a colon
in the name. Renaming those tracks later IO::set_name()
crashed in current_name.replace(std::string::npos,..).
`IO::build_legal_port_name` uses ";" instead of ":" while
`IO::set_name` replaced it with a "-".
Initially the IO name included the colon, so ports created
use a semicolon. But after renaming the IO, ::set_name() applies
the replacement and the IO's name is changed to include the "-".
This leads to a conflict with ports that already have the semicolon
in the port-name.
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`
Loop Location start="a1665678660" end="b145920"
Loop-end (at 122BPM) is a2109859636
at 48kHz this is sample 1794098.32
Now play the loop and play sample 1794098 = a2109859248
Range::squish start: a1665678660 end: a2109859636 squish: a2109859248
squish() does nothing, since there are still 388 superclock-ticks
until the end of the loop.
However, DiskReader::get_midi_playback convertes the value back
to samples(), this leads to effective_start == loop_end;
resulting in an endless loop.
Thanks to MikeLupe to provide a session to reproduce this issue.
So far group-override "inverts" group behavior. Disabled groups
(or group settings) are enabled and vice-versa.
When the setting is disabled, groups can only ever be disabled
(Controllable::NoGroup) and group-override will not enable them
(Controllable::InverseGroup).
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
This ensures that the user will see a "POOL OUT OF MEMORY" message.
In rare case dumping the pool can segfault when printing the Event,
The pool is zero initialized and only ever contains events, so
in theory it is safe to print them..
When exporting many ranges, locate and restarting transport for
every ranged a SessionEvent::TransportStateChange event is queued.
Since freewheel export does not process events. Those events
can accumulate:
https://discourse.ardour.org/t/pipewire-jack-export-freeze/107383/18?u=x42
During export those requests can be safely ignored because the only
purpose is to emit a TransportStateChange() signal when the playhead
passes a given location and notify the UI.
