Re: [linux-audio-dev] PTAF link and comments

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] PTAF link and comments
From: David Olofson (david@olofson.net)
Date: Sat Feb 08 2003 - 07:54:22 EET


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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Feb 08 2003 - 07:55:54 EET