[gmpi] Re: Time Summary (was *Ping*)

  • From: David Olofson <david@xxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Fri, 16 May 2003 17:51:52 +0200

On Friday 16 May 2003 17.14, B.J. Buchalter wrote:
[...events delivered early to compensate for latency...]
> Is it possible that we want to (or need to) allow a plug-in to
> define a "timestamp" lookahead time that causes the host to deliver
> events before the current timeslice in a well defined way? This is
> not to allow a host or a plug to queue up events forever into the
> future, but to allow the plug to get a "short" look into the future
> so that it can compensate for any internal delays between its event
> terminal and its process routine (which could be halfway around the
> world (or at least in another physical box).

Some plugin APIs allow plugins to report "internal latency" to the 
host. It would make a lot of sense to have that feature cover events 
as well.


> Or is this something that no one (besides me) is interested in?

*Everyone* who's ever tried running two or more chains of plugins in 
parallel, processing the same signal, is interested in this. It's a 
required feature, IMNSHO.


> On another note, I have a question for those folks who are against
> using a double to represent ABSTIME. It seems to me that a double
> has 48 bits of precision. This means that it can represent the
> integers from 0 to 2^47 with no rounding. If this is in samples,
> this corresponds to 46 years or so with no wraps at 96k. And
> current hardware can do most arithmetic operations on these
> quantities in one cycle.

Unfortunately, when you try to convert a floating point value into an 
integer to actually use it (ie sample index), we're no longer talking 
about a one cycle operation on some platforms. One should avoid 
int<->float conversions as far as possible, especially in the 
float->int direction.


> So, am I missing something about scaling
> precision and rounding?

Either way, why waste 16 bits of 64, as well as CPU cycles? I don't 
see anything truly useful that double timestamps can bring us.


> It seems to me that using a double for
> integer+ representation is very useful in this context (not that 64
> bit integer bothers me that much either, and in some ways is more
> transportable to most DSP architectures). I understand how floating
> point numbers have strange rounding and scaling precision
> behaviors, but I don't really see how this comes into play for this
> application with the precision in the double (float would
> definitely cause problems). BTW, this is not meant to start another
> war on this subject -- I'm just wondering if the anti-double folks
> can show me where I am missing the boat?

Well, if we compare double to int64 and ignore the FP issues, the only 
difference is that double can handle sub-sample accurate timestamps. 
I think we agree that we don't really need sub-sample accurate event 
timing (features that could use it can be implemented in other ways), 
and that we don't want the issues that come with sub-sample accurate 
timestamps. (More complicated ramp/curve event handling, "how do I 
round to sample indices?", most plugins ignoring sub-sample accuracy, 
making it pretty much useless etc...)

If we consider Mike Berry's multiple sample rate problem, I don't 
think double timestamps can solve that reliably. We're still talking 
about power-of-two based numbers, so if 1.0 <==> one sample, it's 
basically no better than fixed point. (And if "1.0 <==> one sample" 
is *not* hardcoded, we might as well go with int64 + host defined 
quanta, which means an ugly emulated division for every timestamp an 
32 bit machines.)


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---


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