i18n must be included last, after all template specialization.
Otherwise the following happens:
In file included from ../libs/pbd/pbd/i18n.h:22:
../libs/pbd/pbd/compose.h:122:6: error: call to function 'operator<<' that is neither visible in the template definition nor found by argument-dependent lookup
This fixes an issue with Renoise Redux. The plugin reports the following:
Reported Channel Capabilities (explicit):
[2, 2] [1, 2] [0, 2]
When it is added to an Arodur MIDI track, the 0 in, 2 output variant is
chosen, since Ardour MIDI tracks don't have audio by default.
However the render callback was set uncondionally for all busses. This
lead to issues with this specific plugin.
This fixes issues on MacOS (and Windows) unit-tests. The
unit-test run readless without proper UI thread. Discovering new
AU or VST can stall the app indefinitely or cause crashes.
NB. LADSPA, LV2 (and Lua) plugins are scanned regardless. Also
VST and AU cache files are read. The unit-test however only lists
LADSPA plugins.
This fixes a circular shared_ptr<> reference that prevents
plugin destruction.
LuaProc may hold references to Route that contains the plugin
or the PluginInsert of the LuaPlugin. These are only dropped
when the interpreter collects garbage.
Previously this happened in the d'tor or LuaProc, but while the
Plugin has a reference to the Insert, the Insert is not deleted
and the d'tor is never called.
This is useful in cases where an object owns child objects
which in turn hold a reference to the parent.
In this case PluginInsert has-a Plugin, which may have a reference
to the insert or the Route.
This follows 5a41ca8fdf and df1e6fda2d.
Even though this kind of precision is rarely needed, rounding
to a single digit is inconsistent with various places that display
more than one digit, or allow more accurate control.
On GLIBC systems pbd_stack_size() adds __pthread_get_minstack,
this is no available on mac systems, causing issues with some
libraries used by plugins.
In some rare cases the butler may be busy for a long time
(e.g. seek in a large session may still be active when
export is started).
8 second timeout seems reasonable to prevent the app from hanging
without desktops showing a "unresponsive" popup in case the
timeout is reached for some reason (e.g the engine dies, and
no TFSM transition can happen).
At present only audio data from disk readers is declicked. MIDI tracks with audio output should
likely also be declicked, at which time Session::need_declick_before_locate() will require
amending
previously this subscription was handle done in
Route::add_routes() -> add_routes_inner() for MIDI tracks only.
Since f6c0b02d9f this was only done when adding
tracks, after any instruments were loaded (and fanned out).
This consolidates instrument creation for midi tracks & routes.
If an instrument is added, output auto-connect is postponed until
after the instrument plugin is added. Also when a multi-channel
instrument is fanned-out, the track outputs are not auto-connected.
This also subscribes MIDI-Busses to auto-connect when an instrument
is loaded or replaced at a later time.
Since fan-out happens (interactively) in the GUI thread,
we need to keep track of this, in order to prevent later
auto-connection of the track to the master-bus.
..forth and back..
1882c1ba7edabd5715e9fac8d84786
This needs a [much] better solution:
e.g. Wait until instrument is instantiated (ports are created),
then auto-connect, and finally fan-out
(or alternatively skip auto-connect for fanned-out tracks).
Currently both auto-connect as well as fan-out and port-creation
take place asynchronously.
Also MIDI track subscribe to &Session::midi_output_change_handler,
(MIDI busses don't).
