clear_events() must run in realtime context, which is likely to be asynchronous
with respect to the thread that calls it. So allow caller to pass in a functor
that will be executed (also in realtime context) after the clear is done.
Additionally, allow for a cross-thread callback to the event loop/thread which
initiated/allocated the clear event request so that it can flush its own pending
loop. This part probably isn't necessary but doesn't hurt and is a useful model.
The event would be placed back in the free list at the next event allocation
by the calling thread anyway.
Expanded API splits apart some CrossThreadPool functionality, and provides
access to current pool status information (available(), total(), used(), pending_size())
The region is the un-coalesced set of rectangles that were requested for redraw. The area
is the coalesced single rectangle. In the worst cases, the coalesced rectangle could span
the entire window even though just two pixels in opposite corners were to be redrawn.
There is a problem with the verbose cursor as it is dragged across MIDI tracks. TO BE
FIXED.
The infinite loop would happen if the 2 supplied paths were on different Windows drives - for example if one was on drive C:\ and the other on drive E:\
I don't think this new test will be detrimental to the other platforms but if it is, we could easily separate it out with a '#ifdef PLATFORM_WINDOWS' directive.
This gets us around a problem when converting a session from the old (Ardour2) format - where the Session Range (start) value was getting incorrectly set if we hadn't already set the end value.
at the time the graph gets around to takes down
client threads, the jack-backend’s jack_client has been reset.
But never mind: libjack does not care about it, anyway.
The window version will not activate bindings like <Mod4><Super>-space, whereas the former one works correctly. We already used
the former one just above, when handling "fakekeys".
Also add a utility function to show modifier state.
Don’t statically initiate the lv2 world, use explicit call after
scanning bundles.
lilv_world_load_specifications() and lilv_world_load_plugin_classes()
are only ever called after lilv_world_load_all(), so we postpone
the call to it.
