[gmpi] Re: Reqs 3.9. Time - opening arguments.1

  • From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 4 Feb 2004 17:03:16 -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?

Wouldn't have to, see below.



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

It just means representing position as a fraction of length doesn't work. 'S OK, there are other ways.



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

If all the plug cares about is tempo, and the plug has already received the tempo info (either via a tempo control or by watching the interval between incoming clocks and then freewheeling) in effect at the moment when Stop was pressed (and it knows where the last downbeat was), then the plug doesn't need to continue to receive any 'musical timeline' input in order to keep doing whatever it's already doing at that tempo. (This assumes that the audio timeslice processing continues after Stop is pressed, and the plug clocks its internal time off the sample pull itself.) It would only need continued music timeline input if it both didn't have a tempo control and couldn't be bothered to do its own tempo tracking. In which case, screw it. 8-) So no, I see no need to progress the musical time counter after a Stop event just to accommodate beat-sync effects. (And I love beat-sync effects, FWIW.)



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

That's just saying the plug acts as though the beat never stops, which it can do perfectly well on its own. So if your plug cares about this issue, it just assumes there's always a beat going, exposes a Tempo control, resyncs to the downbeat beat after a Start/Resume, and freewheels after a Stop. You're done.



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

Great Day in the Mornin'! An accord!


-- Chris G.

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