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?
I don't think it is such a pain. I'd rather penalize the wrapping systems
than the native systems.
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.
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.
:)
Yes, but given
my experience with customer support, unsafty
displeasure is one or two orders of magnitude above efficency
pleasure.
Very good point! If it *crashes*, who cares if it's slightly faster?
At least they won't have to wait as long for it to crash..
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
no, it restricts users in ways EXACTLY intended by the authors. But then, I
am the lone advocate of dumping (or mostly dumping) soft-ranges altogether :)
Yeah, that's the approach I have in mind. Chained
fixed size blocks or
something... It's not too much fun working with, but we *are* dealing
with real time here; not word processing. People wanting to write
real time software will simply have to accept that it's a different
world, since there's no way we can changes the laws of nature.
That will probably be just fine - raw blocks do need some special magic.
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...)
If we want to interface XAP/PTAF to some other language than that which the
API is defined in, we need wrappers. Period. For most languages you CAN'T
change calling conventions. Specifying this stuff in an API is insane.
Tim