* all API calls use session-time (allow region-lists)
* per-region transients are separated in
- Onset (Rhythm Rodent, Aubio)
- User-added
- internal/source (QM), used as fallback for next/prev (read-only)
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)
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.
xxxAudioBackend::connected_to() is called O(N^2) when building the graph.
Mitigate this by using an O(log(N)) lookup.
This duplicates the storage (both set and map and both are kept in sync.
Changing this to a boost:bidirectional might be nice, before updating
other backends.
