[gmpi] Re: Reqs 3.9. Time - opening arguments.1
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 4 Feb 2004 15:07:08 -0800
On Wed, Feb 04, 2004 at 01:40:26PM -0800, Chris Grigg wrote:
> >Not necessarily true. If you think of music time more as a metronome, it
> >keeps going.
>
> Tempo change, time signature change...?
it speeds up or slows down. but the beats keep going. Should a beat-synced
effect stop working just because the transport is stopped?
> >Transport time relates to the position within a piece of known
> >length.
>
> Length of a piece is not necessarily knowable.
Yeah, I thought about that - how do we represent transport time? Or maybe
we don't?
> >If we allow syncing to music time - such as a delay every beat,
> >then we need to consider that music time continues while transport stops OR
> >we need to force tempo-synced effects to convert their tempo-sync into the
> >master clock or real time.
>
> Freewheeling some clock from its last known rates to achieve this
> kind of special case effect is not necessarily the same as knowing
> the true musical position.
Position is irrelevant to the passing of time. You (may) need to know how
long a beat is and when the next one starts regardless of your current
position. Tempo-synced effects must still work with the transport off.
> 1. I think musical position from the start of playback is a useful
> thing to be able to get, and is not a simple/direct conversion from
> sample clock, so I think we need both;
I agree this is non-obvious
> 2. It remains to be seen whether the source of musical timing (out of
> band to note events etc.) should send interested plugs regular
> musical position update events (analogous to the MIDI Timing Clock
> message and/or MIDI Bar Marker & Time Signature messages), but this
> would be one way to clock the kind of thing you have in mind. (The
> alternative would be to rely -only- on a high-res fractional musical
> position stapled to the start of the current timeslice -- may be OK,
> but extracting beats gets messy.)
right - my thoughts exactly.
> 3. How bad would it be to say that musical clocking goes away when
> you press stop? (I'm asking, not trying to be snide.) Changing time
> signature and tempo while stopped is kind of an odd concept, as the
> conductor's baton is no longer moving...
I think it's bad. I think it would show a lack of vision to allow that. I
sometimes use my host as an effects rack and play stuff live through it. I
expect beat-synced effects to work. If I speed up the tempo, I STILL expect
them to work.
This is what I originally dubbed as metronome time. The beat number may not
be siginificant, but the existance of a beat IS.
> Again I ask what the definition of 'transport controller' is. Is it
> just a tempo/time-signature master, or just a play/start/stop/locate
> master, or is it both? If it's just a thing that's iterating (say,
> looping) across its own chunk of score/notation/sequencer track, then
> there's no reason to limit the number of them. Imagine a bunch of
I'm starting to get a better picture of what I mean. :) The transport
controller manages transport start/stop/pause, playback location, and maybe
shuttle speed. Most plugins won't care about transport state (except maybe
shuttle speed...). So I don't see any reason to disallow it anymore..
> >I'm sorry I'm being dense on this - can you explain how UTC solves this? I
> >understand about having a neutral high resolution clock, but based on my
> >understanding of UTC (as we have defined it), how does it solve this?
>
> Second that. I'd especially like an explanation of how UTC relates
> to sync across different boxes, word clock across different boxes,
> house sync, and how disagreements among all of the above should be
> resolved. In short: I'm a plug, hey here's an event that has to
> happen at a specific time, but the event has multiple time fields, so
> how do I decide when to use the UTC field vs. when do I use the
> sample frame index field?
----------------------------------------------------------------------
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:
