Subject: Re: [linux-audio-dev] PTAF link and comments
From: David Olofson (david@olofson.net)
Date: Sat Feb 08 2003 - 07:07:11 EET
On Saturday 08 February 2003 05.13, Tim Hockin wrote:
> > > I'm questioning whether
> > > having a simpler query based system may be easier. I don't
> > > like the idea that you have to instantiate to query, though.
> >
> > Many plug-in standards require instanciation before fetching
> > properties. PTAF must be able to make good wrappers for existing
> > plug-ins, industry requires it.
>
> Yeah. Here is an open question: Should the wrapped plugin be a
> control at all?
What else? A custom interface that we'll need to handle specially all
the way up to the GUI level...? The interface itself isn't all that
special, I think.
> David mentioned once the difference between 'Controls' and
> 'Parameters'. I don't like having different control types that due
> basically the same thing.
>
> 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?
I don't know if that's useful. If it's not a control, what is it? As
soon as we start making exceptions for this kind of stuff, we start
building specific applications into the API.
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.
The "difference" is only relevant when it actually *happens*. I think
it makes more sense if the plugin just tells the host about it. The
host is responsible for rereading the metadata, checking all
connections etc, before starting the next block cycle. (If it's done
later than that, there's a big chance someone sends events to Queues
that no longer exist and other nasty things. Better do it right after
the plugin returns.)
[...]
> > > 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 :)
> >
> > 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.
>
> This is baloney, IMHO. If you want to make plugins that are binary
> compatible ACROSS PLATFORMS, then this matters. Within a platform,
> ABI does not change (or, it shouldn't - don't use C++ as an example
> :)
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.)
//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 ---
This archive was generated by hypermail 2b28 : Sat Feb 08 2003 - 07:05:05 EET