[gmpi] Re: Topic 6: Time representation

  • From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 30 Apr 2003 12:35:24 -0700

On Wed, 30 Apr 2003, Chris Grigg wrote:

 I don't get the motivation for musical sync events.  Big unnecessary
 complication.  Could be completely avoided by a carefully designed
 time representation and event queuing model.

Can anyone explain, please?

Because musical time or time context can change midway through a process block, unless you wish to (much uglier imho) subdivide things at the host end so that only a single/linear musical time context applies to any given process block.

Regards,
        Angus.


Thanks for the clarification, Angus. No, I would definitely -not- create the timeslices based on musical time considerations. (Personally I prefer a synchronous graph where everything runs at the same sample rate and the whole graph processes one block at a time, all the same size.)

Of course that musical time information needs to get communicated, but I'm still not sold on the idea it needs to be done via events, or at least not solely. It seems like there are several possible types of musical time events, and I'm concerned it could get out of hand. I could see uses for all of the following, maybe there are more, and they all complicated when you look at the details:

- Musical events marking musically interesting times. Bar line, beat line, your favorite beat subdivision, all the way down, I suppose, to the mindur (pardon my ancient shorthand for 'minimum duration', i.e. smallest unit of musical time used in the system). I think of this as the 'sprocket hole' approach. This could make it easier to write things like step-sequencer plug-ins, or synchro-sonic parameter adjustments (or musically-derived modulation/LFO generators), or quantizers. But to be useful, the plug would have to be able to tell the host what musical rate it wanted to get the event at, and that would have to be on a per-plug-instance basis, not a system-wide basis, which would complicate the host.

- Tempo change events. I.e. at a certain sample index into the current timeslice, the tempo becomes X. This would allow for some of the tempo tracking stuff you've described. But instantaneous tempo changes are rarely used-- it's far more common for tempo to change via accelerandi or ritardi, so this would have to be oriented toward tempo slews -- again, we get a picture where tempo looks more like a continuously varying parameter, and less like time-stamped events. So we need to deal with rates and interpolations (maybe across curves).

- Marker events inserted in MIDI tracks.

- Maybe even Loop & branch events inserted in MIDI tracks.

So I would think that if we were to go this way -- and again, I'm not sold yet -- at a minimum, a plug would have to be able to subscribe to these event types independently, including more than one at a time.

Could be I'm wrong, but I get the feeling that giving the plug some host API calls for querying the musical times it's interested in might be a cleaner and less burdensome way to go.

-- C

----------------------------------------------------------------------
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: