[linux-audio-dev] PTAF link and comments

[Tim Hockin]

> > BUT (you knew that was coming): the wrapped plugin is kind of a
> > parameter, more than a control.  Changing the parameter can change
> > the ENTIRE metadata of the plugin.
> >
> > Maybe we should formalize that?
> 
> We could hint the Control as "will cause metadata changes!", but who 
> cares, really? Just for starters, if it's done that way, hosts have 
> to snoop any connections to such controls, or Really Bad Things will 
> happen.

Which is what I originally was thinking.  How do presets work for wrappers?
We need to make sure that these 'gestalting' controls always get loaded
first.  Doesn't that violate some rule we tried to establish about order not
mattering?

Are there other repurcussions?

> > > > The spec should not dictate ABI, either.  The ABI is an articat
> > > > of the platform.  If my platform uses 32 registers to pass C
> > > > function arguments, it is already binary imcompatible with your
> > > > PC :)
> 
> Well, all we really need is to pick the most widely supported calling 
> conventions for each platform. Is there *any* platform that has 
> relevant languages that do not support the native variant of C 
> calling conventions...? (At least, most compilers on Un*x and Win32 
> seem to support at least two or three variants.)

No, we need to go with whatever the native conventions are.  I think the
original poin in the spec was that C++ code would use PTAF as extern "C".
That is fine, you just need to put it in the header.  Don't burden DSP
programmers with things like ABI.

Tim