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