Instead of setting \imprecise at the end of the loop if a configuration
was found (which clobbered valuable information, see dae2406187), set it
each time a new configuration is chosen.
In the second loop that tries harder, resetting \imprecise also avoids a
previous "imprecise->set(AUDIO, 0)" to last even if another
configuration is chosen later.
Last but not least, it will enable correctly setting the midi input
count hoped for by the configuration.
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.
That code modifies \imprecise if it is not NULL, but
- if a configuration is found, \imprecise will be set to in, clobbering
the tentative changes done here;
- if a configuration is not found, a last-resort loop will be run that
will set the same member of \imprecise, also clobbering our changes.
Remove it since it does nothing that is looked at before being
forgotten. A way to get the intended outcome will be introduced later.
...to later enable that condition truthiness to depend on the
loop iteration. The goal here is to prepare for the upcoming rewrite,
without introducing any policy change for now.
There is no behavior change because if all loop iterations are skipped,
then \found will be false, and with \imprecise being null the last
attempt will be skipped and we will return false.
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.
Since can_replicate is true at loop start, and in the loop body there is
a break; after every can_replicate=false, there's no point to test its
value in the loop condition.
There is no code that read the set value in between the removed line and
its exact counterpart below. There is no similar duplicate in the
AudioUnit code due to the way AudioUnit handles midi.
The original LV2 state extension required that run() is suspended during
restore(). Ardour violates this rule, which can lead to crashes and
other issues.
The state extension has been updated to allow restoring state in a
thread-safe way by using the worker to enqueue state changes. This
commit supports that new specification, i.e. supports dropout-free state
restoration properly.
However, the bug with old plugins that do not use this facility is still
not fixed.
In some circumstances UI::flush_pending never returns, and all UI
interactive ends up being driven by
while (gtk_events_pending()) { gtk_main_iteration(); }
This has various implications depending on the caller and usually results
in a crash at session-close or exit.
