[gmpi] Re: Time Summary (was *Ping*)
- From: "B.J. Buchalter" <bj@xxxxxxxxxx>
- To: "gmpi@xxxxxxxxxxxxx" <gmpi@xxxxxxxxxxxxx>
- Date: Sat, 17 May 2003 17:41:38 -0400
>
> this is an excellent summary. however, i'm still not convinced. you've
> argued that there may be/are devices for which the delivery of the
> events is slow, and so attempting deliver events with at most one
> timeslice of latency is not viable. but i've tried to argue that such
> devices (and the connection, whatever it is) cannot possibly be
> working correctly if this is true: they will either be processing the
> right audio data at the right time with the wrong events, or they will
> be processing the wrong audio data at the right time, so to speak.
>
> well, you might say, if we could get the events there on time, it
> would work. true, but you cannot deliver the events to such a device
> in enough time unless every single event-generator in the graph
> (including each node) takes care to generate them sufficiently far
> ahead of time. this now means that all scheduling has to be shifted to
> match the event transport latency of the slowest link.
>
> i suppose its just the symmetrical opposite of shifting all audio
> processing by the processing latency of the "most latent" node.
>
> but its not ... event scheduling ahead of time requires the
> participation of every node. audio latency delays can be handled
> entirely by the host without any node knowing what is going on.
Ok. This is the best counterargument so far. Maybe I don't understand
something -- are event transformers/generators run in a complete graph pass
before the audio timeslice is processed? E.g., is the intention:
1) Queue up all events for the next timeslice
2) Call each plug's ProcessEvents method
3) Queue any events generated or changed by the ProcessEvents call that fall
in the current timeslice
4) Run the audio timeslice of the graph.
If this is the case, then I can see where my proposal could be a sticking
point, since there is no way for all the events to be processed without
shifting the event cycle for all the plugs by the most latent plug -- in
which case I agree that it would be better to couple the audio and control
latency and shift the whole graph.
If this is not the case (and I was under the impression that it is not the
case), then any events generated by the graph have the same constraints as
real-time events -- they have a minimum latency of one time-slice.
But imagine the following situation:
GMPI host running a graph with a synth A
GMPI aware hardware synth B
GMPI aware hardware synth C
The sequence has sends notes to all the devices via GMPI plug-ins. The
internal plug-in A is running graph timeslice synchronous. Plug-in B and C
are running as proxies to the external hardware, and are responsible for
syncing local timestamps to external timestamps. Everything is synced so
that events wiggle the DAC's at the same time. That being said, say we run
the local host with 500 uS timeslices, and the transport latency from the
GMPI plug to the external device is 1 ms. We now send notes to all synths at
once, with the output of the synths summed in an external mixer. We expect
all the notes to sound at once.
With my proposal, the note event is delivered to the internal synth at the
beginning of the timeslice that the note should sound in. The note event is
delivered to the other two plugs two timeslices before the note is going to
sound. All generators start generating at the same time and there is no
unneeded latency added to the internal graph to accomplish this. Now, if we
want to insert an event processor between the host and the plug, it will
need to get the events early as well. I guess that the host needs to sum the
transport latencies of all the plug-ins of the subgraph -- just like it
would do with audio latencies. I guess if the plug-in was an event generator
(like a mini sequencer) it would need to know that it's client had a
transport latency. But wouldn't that also be the case if the mini-sequencer
was driving an audio generator that had an internal audio latency? It seems
that this may actually be representative of a general issue than I thought
-- or is there a solution to that issue without control latencies for event
generators?
Best regards,
B.J. Buchalter
Metric Halo
M/S 601 - Building 8
Castle Point Campus
Castle Point, NY 12511-0601 USA
tel +1 845 831-8600
fax +1 603 250-2451
If you haven't heard ChannelStrip yet, you don't know what you're missing!
Check out SpectraFoo, ChannelStrip and Mobile I/O at http://www.mhlabs.com/
Download a 12 day demo from <http://www.mhlabs.com/demo/>
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
