It would be nice to change get_audio_buffer() to not set
AudioBuffer::_written to false (all but one other user of this API also
only get read-only data), but that requires chaning the rationale of the
underlying ::set_data() API.
Rule #89: The *owner* of each automation-control is responsible to
evaluate automation of automated automation-controls (and emit Changed()
signals to notify the GUI and slaved controls).
This can happen during run(), when the Processor evaluates automation
(eg. PluginInsert does that), but needs to regardless, every cycle.
Emit Changed signal for GainControl
This follow the same concept as PluginInsert: The Changed signal
is called on demand when evaluating automation.
Note: MuteControl already implemented this,
This removes the special case of boolean_automation_run().
Likewise this removes special-cases for actually_set_value() during
automation playback.
Template files reside in
.config/ardour5/templates/$(template_name)/$(template_name).template
We run through .config/ardour5/templates/ and find there the names of the
directories the .template-files are located in. These directory names don't
have a .template extension. So we shouldn't try to chop the non existing
extension of, because then we only modify template names with a '.' in them.
_processors = new_list; may drop the last shared-ptr reference.
This may deadlock in ~IO() for I/O processors or plugins with sidechain
inputs. It's been mostly a non-issues since the GUI usually holds a last
shared-ptr reference for a processor to be deleted, but that is
not always the case.
AudioRegion::set_fade_in() freezes the original ControlList, then
assigns a new one and thaws that.
Frozen state needs to be retained during assignment.
Related: The overloaded assignment operator in AutomationList
performed duplicate signal emission and didn't freeze the list.
And it's actually mostly moot. interface_to_internal maps
any range to 0..1.
The GUI could just hardcode min/max 0, 1 and steps 1/30, 1/300.
Except for controls that have explicit range-steps & ctrl surfaces.
Ardour may have ignored log-scale for parameters 0..N and allowed
writing '0'. Force those values into the valid range on session load.
Also mark the list as "needs sorting" which removes potential duplicates.
This reverts commit e9ee454ced.
This needs more work to preserve non-customized panners in existing
sessions. "user-panner" is only set if a user explicitly selects a
panner.
The midi_input_handler for the AsyncMIDIPort is connected to the
main event-loop. Events may still be delivered after the surface was
destroyed.
That by itself is not harmful, unless a given message produces a reply:
The _output_port is already gone, FaderPort8::tx_midi crashes.
When triggering Session::undo() or Session::redo() from a
non-GUI-thread (e.g. from a surface protocol) Ardour crashes if setting a
CairoWidget dirty due to a ENSURE_GUI_THREAD assertion. (see #7371)
By triggering undo by BasicUI::access_action() rather than by Session::undo()
we ensure that the GUI thread will finally call Session::undo().
So more like a workaround ... but better than crashing :)
The vast majority of errors reported by users as
"Cannot configure audio/midi engine with session parameters"
have nothing to do with engine-parameters.
Fix potential crashes in case fluid-synth runs into an OOM error,
and address a const-cast compiler warning.
Switch to track github repo (instead of sf.net git)
The drawing itself should be unchanged but much of the rest of the
implementation has changed. The WaveViewThreads and WaveViewDrawingThread
classes were added and allow multiple drawing threads.
The Item::prepare_for_render interface is implemented by WaveView to enable
queuing draw requests for the drawing threads to process as soon as the state
change occurs during Editor::visual_changer, which often means the images will
be finished by the time they are needed in WaveView::render. This can
significantly reduce total render time and also flickering caused by images not
being ready for display.
If the drawing thread/s cannot finish the request by the time it is required in
WaveView::render then cancel it and draw the WaveViewImage in the GUI thread if
it is likely it can be completed in the current render pass/frame. This change
also helps reduce the flickering caused by images not being ready with threaded
rendering, but with several drawing threads, drawing in the GUI thread may not
often occur (unless explicitly requested).
Allow unfinished images to be returned from the cache in
WaveView::prepare_for_render so that new draw requests aren't queued for
duplicate images. This reduces the amount of drawing for instance in
compositions where there are many instances of the same sample/waveform
displayed on the canvas as only a single image should be drawn.
Use a random width within a certain range for
WaveView::optimal_image_width_samples so that image drawing is less likely to
occur at the same time (which will cause a spike in render/draw time and
increase the chance of flickering waveforms).
Move implementations of the private WaveView classes into wave_view_private.h
and wave_view_private.cc source files.
Incorporate a fix for limiting the waveview image size to the cairo image size
limit.
Should hopefully Resolve: #6478
Called when an item has requested a redraw and intersects with visible
canvas area.
Also add Canvas::prepare_for_render that will call Item::prepare_for_render for
items visible on the canvas.
This may need some small tweaks for MB channelstrip to set
print-format (like LV2 plugins would) for cases where the default
value_as_string() differs.
Do not use AutomationType to identify parameters, use complete
Evoral::Parameter and Automatable.
For "batch connections", a Slavables needs to implement an API to return
the relevant controls.
This is only a first step towards a more generic Master/Slave framework.
Let the plugin implementation of Plugin::add_state use a LocaleGuard if it is
necessary (VST/LV2). This puts the LocaleGuards where they are required but the
LocaleGuards in Session::set/get_state will mean these LocaleGuards are a noop.
They are still useful for documentation purposes and in case the code is called
from a non-Session context at some point.
ARDOUR::AutomationList is no longer using LocaleGuards as float <=> string
conversion is using PBD::to_string/string_to so the reason for adding these
guards as per comment no longer applies.
I think this was only to protect the float <=> string conversion in
Session::setup_click_state related to click gain which is now using
PBD::to_string/string_to and so no longer necessary.
There are no float <=> string conversions in MidiDiskstream state methods,
these guards must have been to protect conversions in Diskstream state methods
which are now using PBD::to_string/string_to via XMLNode so no longer need
guarding.
The float conversion in Diskstream::get_state is now done using
PBD::to_string/string_to via XMLNode::set_property API.
There was no explicit LocaleGuard protecting the string -> float conversion to
remove so it was probably protected by the caller.
Saving the new ControlList interpolation methods (enum) breaks loading
the session in older version. The session-format version will
need to be increased.
Until then:
* Fader automation + region gain envelope uses linear fades
* The automation-line visible in the GUI does not match the actual fade
(the y-axis is log/exp-scale, the fade is linear)
* Adding new points on the line is not using the correct initial value
* Custom changes of interpolation mode are not available
Neither of these issues is a regression.
The Control and ControlList uses the raw value (eg. coefficient for gain,
Hz for frequencies) and those Lists are stored in existing sessions.
In the vast majority of cases interpolating automation values using exp/log
scale for dB, freq makes more sense -- it's also what the fader does.
Adding additional interpolation methods is future proof (we might at allow
to even add different methods per automation point (to the next) like other
DAWs do.
Currently it's mainly used in preparation for consistent GUI automation-
lanes. Between 2 points there's always a visual straight line.
This explicit case should never have existed in the first place.
Plugins can always implicitly exceed the range and are expected to
cope with out-of-range values (e.g. meters when fed with a peaking signal
may return an out-of-bounds value)
This allows complete mathematical description of a given parameter
and parameter values.
Semantic type abstraction is reserved for Ardour::ParameterDescriptor.
Functions formerly in ardour/util.h and some more functions.
The main motivation is libevoral which can use libpbd but not libardour.
The eventual goal is to consolidate various different interpolation,
scaling and deflection methods.
Trim automation is planned via SlavableAC as normal AutomationMode.
Some of this code have a revival (a special "Trim+Preview" state
before merging Automation but that has to be more general than Pan & Gain.
Cloning a region retains the region-lock style.
Playlist partitioning set the region start-property only (audio-time).
If a MIDI region is locked to musical-time, Properties::start is ignored
and overwritten by Properties::start_beats.
