The idea is to run a plugin outside the process graph, and provide
its I/O as port (much like an external JACK app).
The intended use-case is NDI (provide additional I/O), but it could
also be useful for other cases.
This allows to pass any GraphChain to the Graph to process.
It removes the need to use a mutex to swap two dedicated
chains (setup-chain <> active-chain, pending-chain).
Also various special cases pertaining to graph interaction
while auditioning and route-deletion can be removed.
This also unconditionally creates a graph-thread for GraphChains
to be processed, even if the main callback uses a special-cased
sorted RouteList if there is only one process thread.
The process-graph should only be concerned with GraphNodes,
which may or may not be Routes.
This also removes intrinsic connection information from
the graph-node. Connection information is to be kept separate
from the nodes.
When the graph is re-calculated in the background, old information
has to be retained until the new graph becomes active.
Previously *new* information was already stored in the nodes
while the graph is sorted, even though the new graph was not
active.
In all years of using these assert()s never triggered. Besides
there are valid_port() tests in other strategic locations that
are not periodically hit in realtime context.
The set uses a custom sort-by-name comparator.
Previously it was possible to have an inconsistent set iterator.
std::set::find() did not find a given port while std::find() did.
This fixes using std::set::find() on the PortIndex set.
Temporal::most_recent_engine_sample_rate is used in performance-critical code so shouldn't be accessed via a 'get()' function. But (via the TEMPORAL_SAMPLE_RATE #define) it does get accessed outside of libtemporal and therefore needs to get exported.
We were using a given tempo or meter point as part of the metric used when
recomputing its position. In fact, the metric should be only use the
tempo/meter immediately preceding the given point.
This splits apart the actual signal handler from the work that needs to be done
to update the GUI in response to a tempo map change. This allows us to do the
visual update when we are manipulating the thread-local write copy of the map
during e.g. a drag operation.
It is more useful to get the actual TempoPoint than just the Tempo
that we discover.
Aside: it would be awesome to understand how to use boost::intrusive to get the
next tempo point directly from the tempo hook.
On M1, the cross-thread channel sets G_IO_PRI in addition to G_IO_IN
this breaks various assumptions in receivers, which test for ~G_IO_IN
as error condition.
John Emmas
Robin Gareus
itmuckel
Caleb Potter
Paul Davis