On Saturday 08 February 2003 06.19, Tim Hockin wrote:
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.
Yes! Good point.
Doesn't that violate some rule we tried
to establish about order not mattering?
It does. *heh* The rule was about controls that may "refuse to accept"
certain values depending on the values of other controls. The
consensus was that control inputs are *inputs*, period. They can't
change spontaneously, so plugins will have to deal with it internally
- and consider *only* the values at any time; not order of changes.
Well, I guess it's ok to just hint them as "write us first!", so hosts
know how to load presets. In fact, it's more like "write us before
making any connections!" - because if you don't, first the plugins
won't fit in the net description, and then any connections you manage
to make despite that will be broken.
Are there other repurcussions?
This isn't enough? ;-)
> > 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.
Yeah, that should do. Users of other languages, or wrapper authors,
will have to know whether or not they have to do anything special to
call C functions.
Don't burden DSP programmers with things like ABI.
Right.
//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 ---