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.
