[gmpi] Re: Topic 6: Time representation
- From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Thu, 8 May 2003 22:18:37 +0200
"chris" <kjbeak@xxxxxxxxxxx> said:
Yes but if only very few plugins want this information then it is non sens
to send it to all plugs. If 90% of plugs are happy with ABSTIME then it will
be far more econimcal to let the other 10% request the conversion from the
host.
I tend to agree with both this -and- Todor's idea that it could be up
to the plug to tell the host what time representation it prefers for
events. The primary goal is to optimize by avoiding unnecessary
conversions, either in the plug or in the host, and it seems to me
that making the host go through a select
(nextPlug->preferredTimeFormat) { case...case...case... } is not so
bad.
So the question is how many plugs are going to want somthing other than
ABSTIME?
Well, if our ABSTIME is not going to be integrally related to
samples, as (if I recall correctly) Mike proposes, I would think the
question might be better put: How many plugs are going to want
something other than a sample index, modulo the current timeslice?
Don't most plugs just step through an input sample buffer one sample
index at a time? Why fight that when we could support it?
So A) if we have to choose a default event time representation that's
always passed to the plug, why not make it a sample index? And B) if
we let the plug tell the host what one time representation it wants
to see, why not make sample index one of the available options (and
maybe the default one)?
I think I like B).
-- Chris
----------------------------------------------------------------------
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:
