8 Feb
2003
8 Feb
'03
1:34 a.m.
On Saturday 08 February 2003 05.38, Tim Hockin wrote:
I don't think it is such a pain. I'd rather penalize the wrapping
systems than the native systems.
Yeah, that's exactly what I'm thinking...
how about we encode it as setting all the low order bits of the
buffer pointer to 0 up to the alignment. The first 1-bit dictates
the alignment.
Yeah. :-) You have to check each buffer upon connection, and
obviously, you return a suitable error code if you don't like what
you see.
[...]
no, it restricts users in ways EXACTLY intended by the authors.
Unless the author just intended to hint a useful range for a control
that doesn't have obvious limits. There's no way to do that if ranges
are hard.
[...]
If we want to interface XAP/PTAF to some other language than that
which the API is defined in, we need wrappers. Period.
Yeah. It's just that wrapping timestamps get nasty if they're expanded
to 64 bits... OTOH, timestamp operations are already wrapped in
macros and inlines in Audiality, to prevent me from screwing up the
wrapping arithmetics all the time. ;-)
Functions are handy when the calling conventions
of both parts are compatible. If the language you use
doesn't support this convention natively, all functions
have to be wrapped, which is a real pain.
Really? We can add a host property indicating the current
alignment so the plug-in can check it before continuing.
Very good idea. There *are* platforms where a plugin could crash
the host if they ignore this. Natural values would be needed only for parameter
connection
between plug-ins, if user chooses to connect natural values.
There will be conversion work to do *somewhere* no matter what.
However, I don't like the idea of making all controls have hard
ranges. It restricts the users in ways not necessarily intended
by plugin authors, since there's no way to set controls to values The only way to guarantee real portability through
platforms
and programming languages is to describe the API at the byte
level. This include calling convention. IMHO We can assume
that every target system has a stack, and can pass parameters
on it.
Good point. I think we can count on standard C calling
conventions to work and be supported by all languages on every
platform. No big deal
Of course, a language that cannot interface with the event struct
would be a problem. Requirements: Pointers, 32 bit integers, 32
bit floats and 64 bit floats. (We *could* make all integers 64
bit on 64 bit CPUs, but it seems insane and pointless to me. 64
bit machines don't have infinite memory bandwidth...) For most
languages you CAN'T change calling conventions.
Well, at least on Win32, Pascal compilers tend to use different
calling conventions from C compilers. Both generally support both
conventions, though, so you "just" have to tell them what to use when
you're mixing them.
Specifying this
stuff in an API is insane.
Except on platforms that have multiple commonly used calling
conventions. (Like Win32.) If you say "use standard C calling
conventions", you're fine, but if you say nothing, you're asking for
trouble.
//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://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---