* replace signal-emission with direct calls to CoreSelecton
using BaseUI's session pointer
* remove unused leftmost strip API
* use CoreSelection for first-selected strip
* Accessing CoreSelection does not modify the session
(allow access from const callbacks)
* replace static calls in P2 surface
This removes indirection and dependency on the GUI for
managing strip selection.
For the time being (since bc78629788) vst3 plugin uses
the Control Protocol API for track selection and focus, and
hence users of libardour also need to use libardour_cp
AVX optimized routine applying gain for Linux was causing SIGSEGV.
It was root caused to premature optimization on frames < 8, and
this commit fixes this issue.
This allows to distinguish Processor::configure_io from the
Plugin API with the same name. Despite the identical name,
both functions serve different purposes.
Likewise the ::can_support_io_configuration() API is renamed.
The signature of that function call has already diverged.
The Plugin-API has to handle optional busses (e.g. side-chain)
and replication. The PluginInsert processor provides context.
This change is in preparation for AudioUnit and VST3 busses.
Currently a stereo-input (1 bus) cannot be distinguished from
mono + sidechain (2 busses).
Since the file-modification timestamp of the module-path is used
if the cache is up-to-date, the file must exist.
For macOS/X bundles the mandatory file as per VST3 spec is Info.plist
A call to VST3Plugin::has_editor() can create the view of
a plugin. If the GUI is never displayed, the view would
not have been released, which can lead to crashes when
unloading the plugin.
Both TimeType (8byte) and EventType (4byte) are written
in an un-aligned buffer (usually 3 byte MIDI messages).
This caused an Illegal Instruction for 32bit ARM builds
The cross-over point of an exponential fade occurs further towards
start of the fade. This increases consistency of cross-fades moving
the cross-over point to the center of the fade.
Also looped material is likely correlated in which a linear fade
is more appropriate.
This is only relevant when automating a plugin-bypass, due to
ActiveChanged the following could happen from the realtime thread:
#2 ARDOUR::Session::update_latency_compensation (false, false)
#3 PBD::Signal0<void, PBD::OptionalLastValue<void> >
#4 ARDOUR::AutomationControl::actually_set_value
#5 ARDOUR::PluginInsert::PluginControl::actually_set_value
#6 ARDOUR::PluginInsert::connect_and_run
#7 ARDOUR::PluginInsert::automate_and_run
In this specific case the update_latency_compensation()
is called with process-lock held but the caller lied:
called_from_backend=false
When a delayline update is needed, this can lead to a deadlock,
since the process-lock is acquired again.
Simply postponing the update is preferable since this also
postpones the change when actively recording.
PS. This may need special casing for freewheel export.
IO::latency iterates over the port-set retrieving the
private_latency_range of each port. The value can cached
since it can only change when connections or latency changes.
see also 40eefeddd6
This is to allow passing the EventType to the Buffer, using a
consistent {[Time], Type, size, data} API, that is equivalent
for all classes.
This is particularly useful for Lua scripts and plugin UIs
than can call `write_immediate_event()` while being ignorant
where the data is routed to (MIDI tracks, plugins, processors).
The motivation for this is to determine if a given event
originates from a user-controlled live input controller or
from playback from disk or a MIDI file.
This distinction is required for VST3 MIDI learn.
This is required. From the "RestartFlags" documentation:
> kLatencyChanged:
> Latency has changed The plug informs the host that its latency
> has changed, getLatencySamples should return the new latency after
> setActive (true) was called The host has to deactivate and reactivate
> the plug-in, then afterwards the host could ask for the current
> latency (getLatencySamples) see IAudioProcessor::getLatencySamples
This can happen during pre-roll when buffers are filled
to start audible playback at zero.
While the position argument is signed for all plugin-standards,
it seems that some do not support negative timestamps before
00:00:00:00. (e.g. https://github.com/falkTX/Carla/issues/1236)
Furthermore TempoMap::bbt_at_sample() returns 0 for all negative
timestamps, but it was possible tthat tempo-map transmission,
as well as beat-position returned negative values.
When the engine is restarted, ports are re-established,
and previously queued port-connections need to be cleared.
This caused a bug:
* when the engine is stopped all ports are disconnected.
_port_connection_queue contains all disconnections
* engine is stopped so _port_connection_queue is not processed
* engine-restart re-etablishes ports and appends those connections
to _port_connection_queue
* process-callback processes the list in **reverse** order
```
while (!_port_connection_queue.empty ()) {
_port_connection_queue.pop_back ();
}
```
* ARDOUR::PortManager::connect_callback() is first called
with connected() and the disconnected()
* All ports are assumed to not be connected
Port::_externally_connected == 0 for all ports
Result:
* vari-speed playback resampling does not work (only external
I/O is reampled), split cycles processing (looping) fails
since AudioPort::get_audio_buffer() does not apply the
_global_port_buffer_offset
Previously when locating process_can_proceed() was set to true,
and routes were not processed while transport states are cleared.
As a result live input was also not processed.
This is no longer needed because the DiskReader handles seeking
directly.
This fixes segfaults as well as corrupt listes when copy/pasting
due to invalid iterators.
::mark_dirty() must be called with WriterLock, and
::rt_safe_earliest_event_linear_unlocked() must not be called
while _events is being modified. The Sequence iterator
(only user of that function) does not ensure this. Only the
sequence read-lock is taken.
When recording audio, simply not writing to the ringbuffer
offsets the recording accordingly.
When recording MIDI, absolute timestamps are used, so the recording
has to be offset by the accumulated difference.
Previously this went unnoticed because tests using the Dummy
backend the accumulated offset never exceeded 1 cycle.
* amend previous commit, fix runtime_error implementation
* Do not copy-construct classes that have a PBD::scoped connection list.
Replace std::map::emplace[C+11], an store shared pointers the std::map.
* Update ArdourMixerStrip is-a ScopedConnectionList (not has-a)
Rename all {object}_n variables and arguments to {object}_id
Parts of code were using the former convention, now use the latter everywhere
Another step towards supporting visual position agnostic identifiers in the future
Use maps instead of vectors for holding strips and plugins
This allows to deal with "holes" after objects are removed
Also paves the way for a future improved way of identifying
individual strips and plugins
Apparently gcc-6.2 with -O3 and -mfpu=neon can use ARM instructions
that requires 64bit alignment (here vst1.64) with data that
is not 64bit aligned (g->strcache) https://i.imgur.com/vYktsUn.png
So we need to be able to build "arm_neon_functions.cc" with
-mfpu=neon, while not automatically using NEON for the rest
of the codebase, unless explicitly asked for.
the proper check using compiler flags would be
defined(__ARM_NEON) || defined(__aarch64__)
however explicit wscript defined "ARM_NEON_SUPPORT" is prefereable.
This commit adds ARM NEON optimized routines for the following procedures
below:
*_compute_peak
*_find_peaks
*_apply_gain_to_buffer
*_mix_buffers_with_gain
*_mix_buffers_no_gain
*_copy_vector
NEON optimized routines have a prefix of: arm_neon_
