[gmpi] Re: Time Summary (was *Ping*)
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sat, 17 May 2003 11:53:39 -0700 (PDT)
> Imagine you have relatively large buffers (30 ms or more). Realtime events
> can happen while a timeslice is being processed. If the buffer is even
> larger, the user could reasonably click new events into the sequence while
> the event's (scheduled) timeslice is running. In this case, can you actually
Then that event is too late, and missed the train. In order to be enacted
at the right time, it must arrive to the host BEFORE the timeslice. Events
are never delivered for the active timeslice for a plug. Once process() is
called for a plugin, no more events can arrive for that timeslice.
> The only way to do this without this concept is for the proxy to add latency
> to it's own processing and to delay the entire local graph. This is the
> opposite of what we are striving for here.
This makes latency across all plugins be consistent, which is a plus, IMHO.
> Another complaint is that looping on the timeline can cause events scheduled
> in the future to be invalid. I disagree in the context that I am talking
> about -- It is exactly the same as the long buffer case where you have a
> loop-point in the sequenced transport and then the timeslice spans both the
> end of the sequence loop and the beginning of the next loop. The host needs
> to recognize that the loop is there when it is scheduling events in. This is
Not all loops and jumps are sequenced. You might look at the MIDI events
for 4 bars from now, but two bars from now I jump to the start of the track
again (manually). Now what? you're going to play wrong data.
> But my point is you don't know what the devices are, and what the events
> are. Let the plug-in tell you; it knows how long it takes for it to
> transport events.
We all agree, wxcept that we don't want to decouple audio latency, I think.
> > 500 ms latency. Latency between when a realtime event occurs, and when the
> > change is effected in the output.
>
> For a realtime update, the minimum latency is the transport latency. But for
> scheduled events, the events can happen exactly when they are supposed to,
> as long as they are sent early enough to arrive before there timestamp (same
> as MIDI timestamping).
If you don't decouple audio and control latencies, they DO happen exactly
when they are supposed to.
> I don't see why you are saying "Ughh". This is what you guys are proposing
> for GMPI with a local graph. Realtime events get quantized to the timeslice,
No one ever said that. Realtime events are handled as best they can be, to
whatever resolution the system can get. Vincent wants to quantize them.
David has better hardware which does MIDI timestamping.
> Perhaps I am being cavalier, but it seems like this should not be a problem
> for the host to do this on a per-plug basis. If the host does not want to
> deal with it, it ignores the transport latency, and you go back to what Paul
> is advocating GMPI should be. But if the API does not exist, it cannot
> possibly be implemented.
It seems to me that with this API there is a lot of opportunity for
wrongness. Any realtime event that happens during your transport-latency
window is DEAD WRONG.
So to eliminate wrongness, you couple audio and transport latency. Realtime
host's need this.
For non-realtime hosts, latency doesn't really matter, so there is no issue.
> 2) It enables plugs that do things before the event (in response to an
> event). The most obvious example is a sampler with a hitpoint in the
> samples. This allows a sequencer to use events to sequence audio. Current
> audio editors (like PT) support hitpoints in regions, so you can spot
> regions in such a way that the audio starts before the spot event. You
> can't do that without fussing around with a normal sampler.
Can you explain a hitpoint more?
> But #1 is the primary case. Advanced MIDI implementations already support
> this. I don't see why the GMPI metadata system should not.
So how do these systems deal with realtime changes during that latency
window?
Tim
----------------------------------------------------------------------
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:
