[gmpi] Re: Topic 6: Time representation
- From: "Angus F. Hewlett" <amulet@xxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 2 May 2003 08:56:15 -0400 (EDT)
On Thu, 1 May 2003, Chris Grigg wrote:
> 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)?
(agree with your analysis, although if it's passed as part of the block
header, rather than as events, MUSTIME must be optional as some hosts have
no knowledge of it)
> B - Should the plug have access to ABSTIME <--> MUSTIME conversion
> services? If so, where should they be located (utility pkg vs. host
> service)?
Yes, in the utility package.
> C - Should the plug should have access to current meter & tempo
> state, i.e. at the start of a timeslice?
If we are to pass MUSTIMEs in the block header, again this is probably
harmless as long as it's optional...
> D - Should the plug be able to query the host for meter & tempo state
> at any given ABSTIME or sample index?
IMHO, no.
> 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?
Plug should always receive them but can choose to ignore them if they
don't mean anything to the plug. Most GMPI plugs will not need or want to
generate them, but there are certain classes (transport as plugin,
synchronization plugins, plugins that act as a musical time source in a
host that otherwise has none) where it might be useful... following the
graph model, such events will get passed downstream. This is an argument
against universal MUSTIME-in-block-header.
> 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)?
IMHO, no.
> G - Should musically interesting times be events? If so, what kind
> of control over the generation & receipt of these events should the
> plug have?
It would be a nice optimization to make things easier for certain classes
of plug, but "musically interesting" is one heck of a can of worms.
> 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?
A graph model could allow this, subscription is controlled by the host or
graph services. Plugins cannot discover and subscribe to sources by
themselves.
> 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?
Object-oriented, active events? Very interesting indeed, but OT for now I
think.
> 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?
int64.
Regards,
Angus.
----------------------------------------------------------------------
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:
