[linux-audio-dev] PTAF link and comments

[Tim Hockin]

> > 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