[gmpi] Re: Topic 6: Time representation
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 13 May 2003 15:32:02 +0200
On Tuesday 13 May 2003 14.08, kjbeak wrote:
> Its worth remembering that not all Languages have Macros, so if we
> want to be language agnostic which i think was one one of
> objectives, then relying on Macros is going to cause prolems for
> other languages. Delphi coders will have to use a function call or
> hard code it. C# and Java dont have macros, neither do most modern
> language i have read about,
Note that by "macro" I actually meant both actual C preprocessor style
macros as well as inline functions; ie anything that one way or
another generates inline code rather than function calls.
If you want to wrap the API with a languae that supports neither,
you'll just have to use normal functions. Same thing that you'd get
if you compile a C plugin with the normal C headers on a compiler
without "inline" or equivalent directive.
This is pretty much irrelevant to interpreted languages, because
you'll have to interpret the code that does the work no matter how
it's arranged. It's the "acros become plain functions" deal again.
For interpreted and VM based solutions where you hack C or C++ modules
to hook stuff up, it's no problem. The macros/inlines will do what
you expect when you compile the binding modules.
Finally, I don't think it's possible to design an API that is
compatible with every programming language on earth on the binary
level. Some languages will need glue code written in some other
language no matter what. Many interpreters *always* need that for
anything that's not built into the language.
> steves sugestion of 32.32 fixed point is a good idea imo,
>
> if we realy must have sub-sample acuracy.
I agree.
As to "do we need sub-sample accurate timestamps", I'm running out of
ideas, and I can't think of solid motivations for it. I don't think
there are any; at lesat not solid enough to motivate any extra
complexity or overhead.
(Speaking of complexity; consider ramp events in conjunction with
sub-sample accurate timestamps. It turns "trivial" into "really
rather hard to get right".)
I believe it could become a marketting argument, but I doubt it'll be
one that has everyone upgrade their systems. I can't think of any
serious way to demo any real advantages. After all, you can just use
a modular synth plugin with it's own internal unit plugin API for
BLIT and granular experiments. If you want sub-sample accurate
positioning for HDR clips or notes, you can add a voice control that
sets the fractional offset, just like you control volume, pan etc.
To me, this sounds like "no sub-sample accurate timestamps, at least
not until someone proves us all wrong, some time in a distant
future."
So, unless someone jumps out from nowhere and attacks my arguments
with a huge chain saw, my vote is 32 bit integer audio sample counts.
Might as well be signed, although in my experience, it doesn't matter
as long as the common operations are handled by wrapping safe macros
or inlines. In fact, the actual value of a timestamp becomes pretty
much irrelevant as soon as you allow wrapping, so why should anyone
care whether it's signed or unsigned?
//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:
