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

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 4 Feb 2004 21:17:20 -0800

On Wed, Feb 04, 2004 at 05:31:47PM -0800, Chris Grigg wrote:
> >> If you're thinking of a sample-based clock, why not say so?
> >
> >Because it may be sub-samples.  There has been talk of a host-defined
> >sub-sample factor.  If the requirements say sample clock, then we don;t
> >leave room for that.
> 
> I said sample-based, not sample counter.  As I meant it, sub-sample 
> clocks are still sample-based.

ok

> Fine, but try to concentrate on the expression of the design, not the 
> design itself... you still didn't define 'address.'  Since you want 
> to place events on sub-sample boundaries, the requirement form might 
> look like: "GMPI must allow sub-sample accurate event timing."

We all agreed that sub-samples are not necessary, but the spec or
implementation may opt to provide more than what we ask for. :)

> A plug could do both of these without needing musical time as one of 
> the event time fields in the event record, so these don't shed much 
> light for the spec-writers who follow.  For them, a more illustrative 
> case is: Does a plug-in need to know the musical time of a note 
> event, or is it enough to know the time just as the sample offset 
> into the current timeslice?  If not, why?

You're right - we need MORE examples and use cases.

> Just stating it isn't enough, you have to characterize it enough to 
> give spec writers a clear picture of what it needs to do, so they can 
> design it to achieve that.  So we have to finish detailing what we 
> need 'music time' for, i.e. what GMPI plugs will want to do with it. 
> Do plugs ever use music time to decide how far into the current 
> timeslice to execute the event?  Or is music time only context 
> metadata?  Or is music time not even delivered with an event, i.e. 
> plugs only get the music time for the start of the timeslice?  Also 
> the distinction between score time and conductor time seems to have 
> gone away in the last 24 hours, is that what we want?

OK - I need more think on this.

> >Defined above - the thing that manages musical time.  It can and should be
> >clarified to be the thing that manages msuical time and the variables that
> >affect it, such as tempo and meter.
> 
> Keep going...

No one has expressed any requirements on these (that I have seen).

> What is its output, i.e. does it generate event pulse 
> streams into the GMPI graph, or is it something plugs & the host 
> query the time from via API?

Does it matter right now?  My vision involves it all as controls and events,
but the requirements is not a place for my vision (much as I'd like :).
Whether you have to query for tempo or you get tempo as an event, has not
been required one way or another.   Do we want to require that tempo and
friends are timestamped events?

> What is its input, i.e. how are tempo
> and meter changes fed to it at the correct times?

I'm not clear on what kind of answer you want for this.

> Can it be a plug? 
> Can it be external to the GMPI graph?  Etc. etc.

We state later that a plugin must be allowed to act as a timeline
controller.  So it COULD be a plugin or part of the host.  Up to the host.

> >This combined with the rule that plugins only belong to one musical 
> >timeline
> >makes it easy.  Your plugin only has one musical timeline controller.  By
> >asking for a bit of music time info, you will always know you are asking
> >YOUR music time controller (via the host struct or something).
> 
> I think you already withdrew opposition on this, but just in case: 
> Are there any arguments against multiple timeline controllers other 
> than ease vs. complexity?

I withdrew opposition against the presence of multiple timeline and/or
transport controllers in a graph.  I still think it makes a lot of sense to
limit plugins to one music-time and one transport controller.  No futzing
with timeline IDs.

> >What makes up music time:  tempo, meter, ticks_per_beat.  If you limit a
> >plugin to having one view of all these things, then life is easier.
> 
> Think in terms other than a plug having a tempo input and this 
> becomes much more attractive.  For example, a synth accepting note 
> events from two different mini-sequencers running at different 
> (though perhaps sync'd) rates.  The receiving plug doesn't care about 
> tempo at all, just sample-counter-based event times so there's no 
> contention issue.

In which case it is not really being controlled...I see your point.  Needs
rewording at least, rethinking possibly.

> >If you read the WHOLE requirement, is it not clear?  Plugins must be able 
> >to
> >figure out when the time is exactly 1 beat from any other time, but they
> >must also be able to detect musical-time milestones, such as the start of a
> >new bar.
> 
> OK, that's better, thanks.  Though doesn't measuring, or scheduling, 
> anything 1 beat into the future violate the future-blindness rule? 
> Or is output look-ahead actually OK?

Well, a delay plugin DOES have a future.  It doesn't know what will happen
there, and it needs to be able to accept anything (including the future
being looped back into the past).  But I understood that any plugin (like a
delay) that wants to have a future needs to do so INTERNALLY.

> >The thing that manages transport time.  That's the only definition we CAN
> >give at this point.  Whatever is defined to be part of transport time by 
> >the
> >spec/implementation is m,anaged by a transport controller.
> 
> LOL... OK, then what does 'manage' mean as you imagine it?  (It's 
> getting kind of circular in here...)

The source of transport variables is the transport controller.  Better?

> > > Please define relationship between a timeline controller and a
> >> transport controller.
> >
> >Unclear, based on all sorts of pending issues
> 
> Fine, but I'm asking why you proposed them as different things -- 
> there seems to have been an idea there?

To stir things up and get all the ideas clearly defined.

> >I'm looking for input on UTC from the people who think it is
> >needed :)

UST, I meant.  Sorry.  I dunno how UTC got substituted into my vocabulary :)

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