This fixes issues with analysis and archiving that rely on a readable
to return 0.
Note however that createSilent() uses max_samplecnt (INT64_MAX) by
default. This relies on a region setting the length of its missing
source.
These processors don't have a UI, so their load stats are not easily
visible. The stats can still be queried via Lua API or DSP-load
overview window, so we retain this for debug builds.
Use AU's preset->presetNumber as identifier since std::map are sorted
this also indirectly sorts presets by preset-number. (user presets
start with a '/' and are listed first, sorted by name).
Since Presets are now identified by URI on session load (53a0199a0)
and AU user-presets can added/be removed (since ae4604a24b), simple
sequential numbering is no longer an option.
This is a step in the right direction: first load the preset and
only if preset-loading was successful mark it as loaded.
This still does not properly unset "parameter_changed_since_last_preset".
AU signals "kAudioUnitEvent_ParameterValueChange" later in the event-loop.
* PortEngine::available() implementation
* AudioEngine::connected() wrapper
Eventually we may re-introduce PortEngine::available along
with a libardour internal port-engine.
Adding/removing the Monitor section changes port-connections,
a port-engine is needed to establish connections.
Ideally we'd allow this and queue for connection changes. This
will however require deep changes.
Also toggling the monitor-section on/off/on w/o engine can later
result in failure to register ports. Due to lack of engine-signals
not all shared_ptr<> port references are dropped.
Previously Port::PortDrop was never handled.
The signal was disconnected directly when the connection
is re-used by Port::PortSignalDrop.
Ports::drop() was not called when the engine was stopped
or disconnected, and port-handles were not invalidated.
This lead to crashes whenever a port-related operation was performed
while the engine was stopped. e.g. adding/removing tracks or plugins
(latency recompute, notify port-engine) and various other operations.
This fixes an error while loading shared libraries: libardour.so
R_PPC64_ADDR32 reloc at 0x... for symbol `' out of range
Treating a local as an immediate value in asm code makes the library
non-relocatable.
This saves some memory (gmsynth loads a 30MB soundfont), and also
re-initializes the synth every time to gm defaults in case some
.mid changes patches or parameters.
This adds an experimental pipe to ffmpeg to encode mp3. Currently
quality is hardcoded and various aspects remain to be implemented.
However, it is sufficient for initial testing.
This will incorrectly list some vocders or reaktor and the likes of
plugins with audio + midi input as Instruments IFF they also announce
effFlagsIsSynth flag.
NB. this is a first step only. we still need to override PluginInfo
While gnu-gcc had `std::map:at const` as non-standard extension
it is n/a for older gcc on OSX.
Surprisingly this const& p() const; performs a tad better as well, likely
due to different exception handling.
Perhaps it is also worth investigating boost::flat_map<> as replacement
for std::map<>, here. Our common case is just a single entry, so using
a std::vector emulated mapping might help.
Another micro-optmization shaving off some ten microseconds for every
plugin. Also copying maps isn't RT-safe.
This may however cause issue if const map references can change
while a plugin is running.
For plugins with 10000 Control Inputs, dynamic_pointer_cast<> overhead
is significant, here ~2msec (~0.2usec per cast, optimized build, i7-5600U,
2.60GHz)
When a route with a sidechain is created from a template or by route
duplication the number of ports of the sidechain are set according to the
XMLNode defining the sidechain. Then the names are set according to the name of
the newly created route.
Thus all the pin connections defined in the template are replicated in the
newly created route.
When a PluginInsert is created it does not have an owner right away. That's why
a we need to set the sidechains name once the owner is known, in order to
include owner's name into the name.
Furthermore we need to follow renames of the owner.
Some plugins return 0 from effGetVstVersion and are hence not detected
as instruments. e.g. VeeSeeVSTRack (VCV). This may also explain why MIDI
port of some other VSTs are not exposed.
Most VST2.4 return 2400, so checking [effGetVstVersion] >=2 (and not 2000)
was incorrect to begin with.
VCVRack VST currently exposes 9999 automatable-control parmaters.
This slows down various GUI dropdown lists and dialogs.
(even worse: those parameters are not mapped to anything by default).
This change allows to limit automatable parameters to a reasonable number,
without loosing state of already automated parameters in existing sessions.
This is required by 7d8b93ad for showing error when actively recording.
It also prevents other UIs (OSC, Lua,..) to change re-configuring
sidechain ports/plugins while recording.
A "fall through" comment is most portable way to indicate
"no break, fallthru" cases.
* __attribute__ ((fallthrough)) // is not portable
* [[fallthrough]]; // is C++17
lili93's session (#ardour) triggered this w/jackd 512fpp:
Drag/Drop copy a latent plugin from one track to another while rolling.
The GUI-thread as well as the auto-connect thread concurrently call
jack_recompute_total_latencies(). The auto-connect thread holds
a process lock while doing so. The GUI does not use any mutexes.
This randomly deadlocks in libjack.
backtrace: https://pastebin.com/6m3KGhWS
This is more of a workaround than a fix. Simply by forcing the
URI to be sortable (VST-user presets are sorted at the end).
This eventually needs a deeper cleanup and API consolidation
PluginInfo::get_presets(bool) returns an ordered std::vector.
However this API is only used in a few cases where the plugin is
not instantiated. PluginInfo::get_presets(bool).
The problem is Plugin::get_presets(). The method returns
information that was previously cached by Plugin::find_presets() in
std::map<URI, ...>
Ardour's VST MIDI buffer API does not yet implement offsets and limits.
When a cycle is split, the same midi-buffer is used for all sub-divisions
leading to duplicate, offset, events.
zita-resampler was modified from the original:
* a dedicated mono variable-resampler version was added
* full-cycle no-resampling was optimized into a delayline
This commit does not remove this concept from the libs/ardour/engine_state_controller code,
which is used exclusively by Waves Track Live (to the extent that this can be said to
be "used").
This allows to special-cases session-specific control-surface state.
e.g. midi-learn.
Only restore midi-learned, session-specific, bindings when loading a
session with generic-midi enabled.
Also dis/re-enable generic-midi resets midi-learned, but no other
session-independent settings.
This also handles the edge case:
1) load global config, generic-midi = ON, w/ bindings.
state is remembered as cpi->state
2) load session-condig, generic-midi = OFF, cpi->state is retained
3) user enables the surface, cpi->state from (1) is applied.
-> invalid bindings applied -> fail
Keep latest surface configuration, regardless if surface is active
or being deactivated. Current state after de-activation is retained.
Currently state loaded from a session overrides global state from
global preferences, if the surface is marked active in the session.
This is to allow midi-learn.
generic-midi and session-specific midi-learn will require additional
work.
Midi meters are using linear 0..1 range, (not decibels, no log-scale
falloff).
If a track is deactivated, run() is never called. the queued reset never
executed and the meter remained at the initialization default -inf
(visually it looked like a pegged meter).
Rationale: This change is trivial, but Ardour's behavior of refusing to move right one channel unless a full bank remains has been there for a long time, and there are probably good reasons for it. This design was likely conceived when all MCP-compatible devices had banks of 8 faders anyway. However, with the advent of affordable single-strip devices like the X-Touch ONE it becomes a real issue.
Single-strip devices can only access the first channel in the current bank, so relaxing this restriction is the easiest way to enable such devices to access all strips, while still maintaining the usual bank size of 8. Note that maintaining a bank size of 8 is beneficial even with single-strip devices for several reasons:
- It allows use of the bank switch buttons to flip through a large number of strips more quickly.
- It maintains compatibility with existing device descriptions. E.g., the X-Touch ONE can be used with the existing X-Touch device description without any ado.
- Most importantly, it maintains compatibility with other MCP-compatible controllers which do have 8 strips and may be connected to Ardour at the same time. E.g., one might want to use an X-Touch Mini, or even a full-size X-Touch along with the X-Touch ONE in some use cases. Changing the bank size to 1 affects all connected MCP devices, so you'd rather keep the bank size to 8 in such scenarios. (Ardour should preferably have separate bank size settings for each connected MCP device, but that isn't possible right now since only one MCP device description can be active at the same time.)
Without this, the visibility tracker will report that the window is not visible at startup, and
this overrides the XML _visible property which denotes that the window should be made visible
