[gmpi] Re: Topic 6: Time representation

  • From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Thu, 1 May 2003 10:51:19 -0700

Great summary, Ron.

...The other issue discussed was how
musical time information gets passed into the plugin.  I'll try to
synthesize a few possible solutions to this point, for the sake of picking
up the discussion again.

First, lets assume we'll define a data type for musical time.  I'll call it
MUSTIME.  TBD is whether this time uses bars/beats/ticks, floats, or other.

Proposal 1:  A plugin's "process" routine is also provided with a MUSTIME
value that provides the current musical stream time for the frame.  MUSTIME
is designed (cleverly<g>) to encode tempo information, so some "MUSTIMEs per
ABSTIME" (in this frame) can be computed.  Tempo and meter changes are
delivered to the plugin "just-in-time", as separate events.

Proposal 2:  The host provides time conversion routines, to go from ABSTIME
to MUSTIME.  Implicit in this conversion is the tempo.  The host also
provides access to tempo and meter information, if it exists.

Proposal 3:  Events that are delivered to the plugin's "process" routine
have unique IDs.  The host provides methods to cough up a MUSTIME (and/or
ABSTIME?) timestamp for an event, given its ID.

These probably aren't wholly mutually exclusive. To rephrase the above differently, with some other side issues from yesterday re-added:

A - Should the host automatically furnish process() with a MUSTIME, or should it be up to any plugs that care about MUSTIME to obtain it themselves (i.e. by converting the timeslice's start-ABSTIME)?

This is, I guess, another question of which side, audio DSP vs. musical, we ought to optimize for. It also gets into the off-topic question of how a timeslice is presented to the plug-in, i.e. if process() takes some gmpiTimelice struct, then it's not too painful to put the MUSTIME in there together with the ABSTIME, ptrs to input audio & event buffers, maybe a serial ID for the timelice (like TCP/IP packets), etc.

B - Should the plug have access to ABSTIME <--> MUSTIME conversion services? If so, where should they be located (utility pkg vs. host service)?

C - Should the plug should have access to current meter & tempo state, i.e. at the start of a timeslice?

D - Should the plug be able to query the host for meter & tempo state at any given ABSTIME or sample index?

E - Should musical time context changes (tempo & meter) be events? If so, what kind of control over the generation & receipt of these events should the plug have?

F - Should the plug be able to query the host for musically interesting times (bars, beats, 'ticks', etc.) falling in any given timeslice (e.g. the one about to be processed)?

G - Should musically interesting times be events? If so, what kind of control over the generation & receipt of these events should the plug have?

H - Should it be possible for there to be more than one musical timebase at a time in the graph? If so, how are musical timebase sources created? How do plugs discover and subscribe to a musical timebase of interest? Can a plug subscribe to more than one musical timebase?

I - Should events be limited to a strict struct-style design, where all (or most) relevant info is delivered to the plug in the event itself, or should we also allow a query mechanism for accessing less-frequently-needed (incl. host-specific) data associated with the event?

J - And the ever-popular: What is the best appropriate data type for the representation of musical time position at the plug-in API level?

-- Chris


P.S. FWIW, I think --

Yes on:
B (w/services provided by host),
C,
D,
E (w/independent subscribe of tempo & meter),
F ()
G (plug requests any MUSTIME interval it wants, & maybe an offset),
I (put just the core data into the event & allow extensible event query mechanism)

No on:
A (ABSTIME is enough; MUSITIME would be redundant to B, F, G),
H (too complicated; let hosts that need this create multiple GMPI frameworks with 1 tempo each) (unless someone has an easy way to handle it).


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

  1. Home
  2. gmpi
  3. Archive
  4. 05-2003