[gmpi] Re: Reqs 3.9. Time - opening arguments.1
- From: "Jeff McClintock" <jeffmcc@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Thu, 12 Feb 2004 11:07:51 +1300
> So if your plugin cares about tempo, you will be notified of a tempo
change
> BEFORE you send any events. When you see a tempo change, you know to not
> send events that would be out of range.
Agree.
Just to illustrate, SynthEdit sends timing using events. Packaged MIDI
clocks in fact. This dosn't present any complication.
The 'sender' has to sample-timestamp each event, so it's obvious which
events occur in that 'block'.
A side note: Events sent between plugins go via the host. The host can que
events that are out-of-range. This saves the plugins any complication.
Best Regards,
Jeff
----- Original Message -----
From: "Tim Hockin" <thockin@xxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Thursday, February 12, 2004 10:19 AM
Subject: [gmpi] Re: Reqs 3.9. Time - opening arguments.1
> On Wed, Feb 11, 2004 at 12:16:44PM -0500, Ron Kuper wrote:
> > >>>
> > Personally, I would prefer to see tempo specified as a list of
> > timestamped "tempo events" for that buffer (the way MIDI events are in
> > dealt with in VST). The plugin can then perform sample accurate event
> > handling for that buffer.
> > <<<
> >
> > I don't think tempos can be events. Here's why I believe this, please
> > explain why I'm off base about this.
>
> It's a real issue in concept, but I think it can be constrained..
>
> > Let's say for arguments sake our audio frame size is equal to 1 beat =
> > 960 ticks (assuming MIDI parlance for a second) at whatever the current
> > tempo is. Every set of events that are passed in live within the next
> > beat, and can be safely rendered in the next beat-sized frame.
> >
> > Now I allow a tempo event to come in. This event slows the tempo down,
> > so that one audio frame is now equal in duration to 1/2 a beat or 480
> > ticks.
> >
> > If the host is feeding these events to the plugin, the host now needs to
> > be careful about what events get sent after the tempo change, to ensure
> > that we don't send more events than fit in a single frame.
>
> Right, the host needs to be aware of tempo changes, as does anything which
> uses musical timing internally. If you think of the host's
> sequencer/automation engine as plugins (whether they are or not..) and
> tempo-masters as plugins, then it's a matter of dependencies.
>
> The sequencer plugins depend on the tempo plugin. In a graph, that means
> the tempo plugin must be processed BEFORE anything that cares about tempo.
>
> > If a plugin is sending these events to other plugins, how do the other
> > events in the other plugins "know" that they are now out of range for
> > the audio frame?
>
> So if your plugin cares about tempo, you will be notified of a tempo
change
> BEFORE you send any events. When you see a tempo change, you know to not
> send events that would be out of range.
>
> If your plugin does not care about tempo, but sends events, then it must
be
> presumed to want sample-based timing and not musical-based timing.
>
> Does that answer that?
>
> ----------------------------------------------------------------------
> 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:
