[gmpi] Re: Time Summary (was *Ping*)
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sat, 17 May 2003 14:13:14 -0700 (PDT)
> > I think the point is that anything that is stored in the sequencer can be
> > delivered timestamped for the future before it's timeslice. Anything that
> > is realtime (user inputs, UI, MIDI, outputs from an upstream processor, etc)
> > would have to be latent.
>
> Ok. I understand this. But this is true with the counter proposal as well.
> If the event happens *now*, it can only be processed after *now*. The only
> way to improve that is to lower the latency between *now* and the next
Lowering latency is the goal of all DAW software that handles async or
realtime input, isn't it?
> is going to happen on the local graph, and so can provide all the queued up
> events for the next timeslice. If the plug-in proxies for a remote graph,
The upstream processor is where your case gets hairy, as noted by others.
when the host calls process() for a plugin, it knows all the events that are
to be delivered in that timeslice. It only knows this for sure IMMEDIATELY
before it calls process(). The plugindirectly upstream from you might be a
sequencer plugin, or an arpeggiator, or something that generates events for
you.
If you need more than 1 timeslice of events, you need to inform ALL your
upstream plugins, and they need to inform all their upstream plugins.
Otherwise my nifty step-sequencer plugin doesn't know about your
requirements for N slices. YOu're assuming the HOST is the primary source
of sequenced information, and I'd rather assume everything is a plugin.
We might find it useful to provide a plugin->sequencer API whereby the
plugin can ask it's own sequencer about the future. But who says you can
only have one sequencer?
Hosts MAY provide one global sequencer. Or they may provide plugins which
adhere to the GMPI sequencer API and have step-sequencers and piano-roll
sequencers, and god knows what else.
Tim
> the host does not know how far into the future to queue events. It is that
> simple. Either you are realtime or you are not. It is like being pregnant --
> you can't be a little pregnant, and you can't just be a little non-realtime
> -- if you provide any lookahead with timestamps you are already breaking the
> symmetry between stored stuff and real-time stuff. I think this is a good
> thing since it enables things that could not be done otherwise.
>
> 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
>
----------------------------------------------------------------------
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:
