Subject: Re: [linux-audio-dev] PTAF link and comments
From: Tim Hockin (thockin@hockin.org)
Date: Sat Feb 08 2003 - 06:13:05 EET
> > 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?
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?
> Anyway I would like to minimize the number of functions.
> Functions are handy when the calling conventions
> of both parts are compatible. If the language you use
> doesn't support this convention natively, all functions
> have to be wrapped, which is a real pain.
If you have to wrap into different languages, you have to wrap enums, too.
There is no way to reduce the total number of things wrapped.
> More, there are still issues with existing plug-ins, reporting
> wrongly if they support some opcode or not (talk to this issue
> to Plogue people :).
Bugs are bugs, whether they are a NULL pointer or a false-positive.
> > How about defining buffer alignment as "what works good for whatever
> > extensions that are available on this hardware"...?
>
> Good, but it requires the host to be updated when new hardware
> is released. We can add a host property indicating the current
> alignment so the plug-in can check it before continuing.
I've thought more about it, and the ONLY place I can see buffer alignment
coming into the API is that a plugin may request a minimum alignment, and
that REALLY seems almost useless.
It should perhaps be an option for the user to set in the host, but not part
of the plugin API.
The plugin can detect the alignment of a buffer by examining the buffer
pointer. NO further mention of it is even needed.
> > you'll get a lot of arguments about that on this list - linux people tend
> > to have a 486 or pentium stashed somewhere. :)
>
> Professional musicians and studios have recent hardware, at
By necessity, not choice. Fatter OS and software requirements drive that.
I don't want to make that part of the XAP requirements, if possible.
Sometimes we spend too much time prematurely optimizing here. I try to
catch that, when I can, though I can be guilty of it, too.
> > Right, but MIDI is integers, and the range defines the resolution.
> > With floats, why have 2.0 if you can have 1.0...?
>
> To make 1.0 the middle, default position.
>
> > ick - if there is a balanced (or even unbalanced) spectrum of values, center
> > it at 0, please :)
>
> No, it makes sense for true bipolar data, but here 0 or close
> to 0 values have their meaning for parameters like velocity.
> It's not exactly like the volume.
ok, so make it 0 to 1.0 with 0.5 the middle - 0-2 is just ick... ;)
> > 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 :)
Assume the spec dictates stack-based arguments for functions. Now assume I
have a system (it IS happening) where the ABI dictates that up to 128
arguments are stored in registers for functions.
If I want to build a XAP host and plugins on this platform I need to
specifically add code to them to violate the platform native conventions.
The only thing that needs to be byte-level specified is fields whose width
matters (integers, flags, etc) and communication protocols. I sure as hell
am not dictating that a pointer is 4 or 8 bytes, or that function calls must
be NEAR jumps on x86 or any other such thing.
Until we have fully-cross platform plugins, we don't need this. At all.
> > I don't like having to call normalize functions for every
> > translation, though. Can the translation overhead be minimized?
>
> It's not a big overhead if done efficiently. VST works this
> way for years, and people don't complain about this side at
> all. Host just needs to store and pass normalized parameter,
> so overhead is not here. It makes even things way simpler
> because data is alawys [0;1]/float, which wouldn't be the
> case with natural or multi-type parameter handling.
I'm still on the fence about this.
(sorry for the latentcy - real work this week :)
Tim
This archive was generated by hypermail 2b28 : Sat Feb 08 2003 - 06:15:27 EET