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