Set the AEffect* plugin pointer before calling effOpen.
effOpen may call back into the host (masterCallback) and invoke
actions which depend on _plugin (eg. to call back into the plugin again)
This mechanism re-uses internal abstraction (plugin-enable).
Other plugin-specs designate a control-port, for VST we 'emulate'
a control-port.
There is still debug-output to stderr, here while testing.
- a tempo marker may now be set to always continue (clamped)
this means that the end tempo of the previous section will
track the start tempo during tempo ops.
it mimics the behaviour in 5.8, with the gui indicating
the curves to be changed.
- GMPC does not use it directly
- when GMPC was enabled Stateful::loading_state_version was set to 1000
(the protocol is at 1.0.0)
- it messes up session-loading, particularly various plugin states and
templates (e.g Processor::set_state_2X was used)
Work around logic-flow in EngineDialog which should already have
done that, but may no longer heed this special-case if sample-rate
dropdown is refreshed to only devices supported ones.
Hotfix work around:
1) Launch without existing user-config and no system_config
2) Load or create session. save/quit.
3) re-load session. save. user-config file is corrupted in <Extra>
This should really be split in separate semantics for key and button events.
Fixes a subtle but nasty bug in the EngineDialog where the change of the default focus
widget from a Gtk::Button (acts on press) to an ArdourButton (acts on release) caused
events occuring after a dialog has grabbed focus to trigger button clicks
When a monitor-section is added, the auditioner automatically connects to
its input. However on session-reload, the connection is explicit
(by saved port-name) and Auditioner::needs_monitor() was not set.
Session::process_audition() didn't run the monitor-route. Silence.
Stop event propagation. Otherwise, on release the event is passed
up and handled by the TAV which scrolls the editor viewpoint
and the button is no longer under the mouse.
The audioMasterAutomate callback from plugin to host does include
the parameter-value.
Previously there was a redundant call
Plugin::parameter_changed_externally() -> get_parameter
-> VSTPlugin::get_parameter() back into the plugin to query the value.
calling back into the plugin from the callback, may explain
oddities and/or crashes with some VSTs.
