audioMasterWantMidi needs plugin _info, but _info is currently only
available after instantiating the plugin in LXVSTPluginInfo::load().
vstfx_instantiate() -> effOpen -> [plugin] -> vst_callback(..,opcode=6,..) -> crash
Not doing this leaves the sources in the session list and then the session fails to open on next load
because the files are not there.
Arguably we should not announce the new files until they are complete, but this is a simpler fix for now.
Serialization of Session::save_state() will already protect against most of this, but there is really no
good reason why Evoral::SMF's API should require single-threaded/explicit serialization.
The PortMidi queue just holds a pointer to the midi events.
The same Midi events are free()d during WavesMidiBuffer::clear()
which is called at cycle start for every buffer and in the dtor
of the WavesMidiBuffer.
This follows the letter sent from Waves Audio Ltd. to Paul Davis dated February 20th 2014 agreeing to release this code
under the GNU Public License, version 2, with copyright owned by Waves Audio Ltd
all backends export a symbol declared as "extern "C" ARDOURBACKEND_API ARDOUR::AudioBackendInfo* descriptor ()".
dlopen'ing the backend apparently pushes the symbol "descriptor" into the single flat global namespace that we use
to be like other unix-like systems. this means that if a backend calls its OWN function named "descriptor", it
is indeterminate which one it will be, since the symbol will refer to the function first loaded by the runtime
linker. If the backend is not the first one discovered, this call to its own "descriptor" function will invoke
the function defined by another backend, even though these are supposed to have local scope only according
to our arguments to dlopen().
This fix doesn't try to fix the linker or namespace - it just makes sure that the WavesAudio backend doesn't
invoke its own descriptor() function, which it never really needed to do anyway.
