This prevents a memory leak: The session is closed.
The session-butler drops memory pool trash. The Engine keeps running.
Once the AudioEngine is taken down (sample-rate switch, or at exit),
the backend process-thread is terminated but there is no trash-can anymore.
If there are unprocessed SessionEvents, this calls
free_per_thread_pool() -> cp->parent()->add_to_trash (cp).
"parent()" in this case the trash-can the butler emptied.
When adding a processor, the processor may add ports leading to
a call to jack_port_register(). while Ardour holds a WritertLock on the
processor-list (this commit removes this WriterLock).
with jack2 that results in a graph-reorder callback (WHY?)
jack2 issues that graph-reorder in a separate thread BUT
port-registration does not return until the graph-reorder is complete.
On Ardour's side, graph_reordered() calls Session::resort_routes ()
which eventually checks Route::direct_feeds_according_to_reality()
which needs a ReadLock on the processor-list to check I/O.
Since jack_port_register() does not return, this constitutes a deadlock.
THE ACTUAL PROBLEM IS JACK2's THREAD DESIGN!
Why does jack_port_register() trigger a graph-order in jack2?
No connections are made.
..and why does it block jack_port_register() from returning if
that graph-order callback is in a different thread?
http://pastebin.com/DZANXJLz
Allow to re-use Midi buffers for GUI communication. Honor
resize-port extension for all Atom Sequence buffers.
(following example of http://lv2plug.in/book/#_sampler)
Tested on Apple Multiban Comp, Apple Dynamics Proc, AU Sampler, Zebra2 and Zebralette.
Still have a 1-2 pixel white border at lower and right edge after window is dragged larger.
Also, debug output.
debatable, since most of them are not "help/tool info" but rather
"current value display".
Then again tooltip is tooltip and can be annoying or not wanted.
ARDOUR_UI::load_session()'s loading_message() shows the splash in
all cases. But only the initial ARDOUR_UI::starting() does destroy it.
In some cases we got away because the Engine Dialog pops back the
splash and the dialog is never destroyed (only hidden).
It's not until ~Dialog that the splash is displayed again (if it exists).
