Subject: Re: [linux-audio-dev] PTAF link and comments
From: David Olofson (david@olofson.net)
Date: Sat Feb 08 2003 - 07:27:20 EET
On Saturday 08 February 2003 05.38, Tim Hockin wrote:
> > > 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.
Yeah, that's exactly what I'm thinking...
> > > 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.
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.
[...]
> > > 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.
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.
[...]
> > > 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.
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. ;-)
> 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 ---
This archive was generated by hypermail 2b28 : Sat Feb 08 2003 - 07:24:58 EET