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.
* callbacks are unregistered during session-deletion, skip saving them
during session destruction.
* prevent duplicate state restore, re-load script with the session, not
window instance.
Honor the sesssion's sample-rate when showing the dialog with the engine
stopped. This can happen when then engine dies or hide/show the dialog
after manually stopping the engine.
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
Previously EditorAction and ExitorHook scripts were saved with
instant.xml. The were saved with each session and in the config
dir (for new sessions). This allowed inconsistent UI setups, especially
when loading old sessions that had no or different scripts.
Now Editor scripts (actions and hooks) are saved in a dedicated file,
session-independently. This goes along with ui_config in general
e.g. action-table-columns
The scripts are not saved with ui_config file for two reasons:
ui_config settings related to built-in ui_config_vars.h,
and in the future there may be further indirection like "ui-rc-file".
Note: previously loaded editor scripts are lost with this change.
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)
