In theory different UIs can show different meter-types, so it
can make sense to maintain the type in different places.
MeterType is a bit-set and PeakMeter implementation provides for this.
However, this is not being used, and the current implementation
was rather fragmented, cross-connected signals to keep types in sync,
allowed inconsistent meter-types in GUI and backend.
MeterType is now kept by meter itself, however it is still
saved/restored as part of the Route state.
N.B. This change breaks the API, various methods have been renamed
for consistency.
Instead of uniformly demote configurations with a non-matching audio
input count (using a penalty offset of 1000), also grade the
impreciseness of the configuration so that those with the nearest input
count are preferred. As for outputs, give a slightly higher handicap to
configuration with too many inputs with regard to the actual audio
inputs that can be fed to the plugin.
POLICY CHANGE: when only imprecise configurations are found the actually
selected one can be different (better) than before this commit.
Just make the code responsible for possible_in > 0 also handle
possible_in == 0 since it nearly does the same thing.
The only difference is that the possible_in == 0 case, by using
FOUNDCFG(), acted as if possible_in was audio_in. The consolidated code
uses FOUNDCFG_IMPRECISE which will add some penalty to the
configurations where desired_in == possible_in != audio_in.
There is thus a small POLICY CHANGE, but the selected configuration will
stay the same unless a better matching configuration is available.
Still no policy change, since when a configuration is chosen that would
have belonged to the second pass, then its penalty will be increased by
1000 and it will be selected only as last recourse.
Merge the cases in == -1 and in == -2 since those are both wildcards,
almost symmetric in the AU spec, and handled completely symmetrically by
the code here considering it accepts invalid or unspecified demands.
Also merge the cases in > 0 and in < -2 since they are handled exactly
the same as far as outputs are concerned.
No policy change
Instead of doing an initial loop for detection of exact matches, then
letting the following loop set \audio_out yet ignore its value, merge
the two loops but give exact matches a negative penalty so that the
\audio_out value they set won't change afterwards.
No policy change.
The reverb and chorus states in the fluidsynth object need to be initialized to
0 (false) in accordance with the initial state of a-fluidsynth's
v_port[...]. Otherwise they are not updated in the first run() and remain to
fluidsynth's default state 1 (true) even though the plugin's state requires 0.
The backend will replace the information in the last bracket (IO)
of the name with (In/Out) when creating pretty port-names from the
device-name. -- see replace_name_io().
This fixes an issue with device-name number suffixes in brackets.
Add support for smoothing, ignore message when controllers are
not in sync to avoid discontinuous jumps.
This is mainly useful for Mackie-like devices that use pitch-bend
messages for faders.
see also https://discourse.ardour.org/t/feature-lazy-sliders/100961
The engine setup identifies devices by name (device list is a map<>
with the device-name as key). To support multiple devices with the
same name, the name needs to be unique.
So far this is achieved by simply adding a number suffix starting with
the 2nd device (this allows to re-use configurations).
Ideally we'd use UUIDs or unique device IDs to handle this, and also
somehow clarify which device is which...
Assume the following connections
Audio -> Bus1 --aux-send--> Bus2
Prior to this commit, Audio -> Bus2 was marked as "direct feed",
even though the connection was only indirect via an aux-send.
This caused issues with implicit solo and could lead to stuck solo.
"last_controllable_value" is using midi value range (0..127).
It is used to compare received midi-value with the actual controllable
for non-motorized surfaces, and this change allows the first
event to already be in_sync.
Previously the first MIDI-event was usually ignored (because
last_controllable_value was out of bounds or didn't match the 0..127
range.
The singleton ActionModel provides a Gtk::Treestore of all actions known to
ardour.
To be used for example by surface control editors to implement action bindings.
Since we (since ddfc37e4) set the UserDown flag for the User button actions, we
need to set it also when we lookup actions when saving the state.
Furthermore, we need also look for the UserDown flag, when we set the state
of the configuration combos for the User button.
The GUI should be notified about the tearing down of the control
surfaces *before* the protocols are actually destroyed.
On ProtocolStatusChange ControlSurfacesOptions::selection_changed() might try
to access protocol->has_editor() of a protocol that happens to be selected in
the preferences GUI. I this protocol already has been destroyed, a crash will
occur.
This forward ports Mixbus' 4eca3dea47 without additional code to correct
for old (Ardour2) URIs.
A2, used path2uri() which accumulated and left duplicate slashes in place,
eg. "file:////". Mixbus3 auto-corrected this on load in
AudioLibrary::search_members_and().
However sfdb libraries are not shared between major versions, so this
code does no need to be forward ported.
This fixes an crashing issue with ArdourUI.SelectionList a bug
introduced in 6dc3bdf252 and 35dcd46d7d.
Since removal of the special cases in 35dcd46d7d, when using
a C-pointer in a std::list<>,
std::list<class*>::push_back(TypeListValue)
TypeListValues<>'s Head was expanded to "class*& const"
implied by void ::push_back(const T& value);
This resulted in lifetime issues with a classes that derive
from sigc::trackable (e.g. Ardour's Selection).
The reference leaves scope and isn't duplicated when it is pushed back
to the std::list<>.
The script scripts/select_every_2nd_region.lua crashed because entries
in the SelectionList were no longer valid.
Previously (before 6dc3bdf252) TypeListValues explicitly
copy-constructed the value to work around the lifetime issue.
This new solution bypasses the issue by directly using the c-pointer
without dereferencing it.
This is to be used sparingly because the pattern is dynamically
created every time. Mainly for the benefit of some Mixbus
widgets -- compared to ArdourButton::convex_pattern
When discovering LV2 plugins, verify if a plugin's required features
and required options can be be satisfied.
This replaces a previous blacklist with a whitelist of supported
features/options.
