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