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