[linux-audio-dev] PTAF link and comments

[Tim Hockin]

> What I'm saying is basically that it's not a goal in itself to create 
> our own "standard" here. If we can get along with the GMPI group and 
> something useful gets out of it, things will be better for everyone. 
> What this would mean to XAP as such is uncertain, of course - but I 
> think we will have *very* little influence on what will become The 
> Audio Plugin API, unless we participate in the GMPI effort.

True enough, though if we finish first, we have a grounds to push XAP as a
good starting point :)

> > 1) none - host can autogenerate from hints
> 
> This part is mostly done, right? (Well, we don't have a real host yet, 
> so we obviously don't have an implementation.)

yep

> > 2) layout - plugin provides XML or something suggesting it's UI,
> > host draws it
> 
> Basically like 1), but with some extra info, right?

yep - an XML schema even exists.

> > 3) graphics+layout - plugin provides XML or something as well as
> > graphics - host is responsible for animating according to plugin
> > spec

> Well, unless we can just whip something almost that good up in no 
> time, from existing, highly portable and suitably licensed stuff. 
> Maybe if libvstgui is released under the LGPL, and we hack a binding 
> for some nice and easy to learn language...?

That's more or less what I was thinking - not too fancy, just something to
blit simple bitmaps - a background + a 16-state knob overlay.

> > 4) total - plugin provides binary UI code (possibly bytecode
> > or lib calls)
> 
> Byte code? Pretty close to what I suggested for 3. And the same 
> issues, of course. The native code version is probably simpler, but 
> obviously, not nearly as flexible.

libVSTGui was what I was trying to say without saying it :)

> And I still agree. There won't be as many hosts as plugins, and we can 
> hack a simplified host SDK, if people think our requirements on the 

Agreed again

> Right, but that solves only part of the problem. You have to be able 
> to deal with "weird characters" in plain strings as well, including 
> paths and file names.

ok, I'll buy that

> That is, if anyone's in doubt, I'm back at my old position; we should 
> at least have an adding version.

I'm there, too

> > I'm leaning more towards the idea that if a plugin can do in-place
> > processing, it may be asked to, but it should have the ability to
> > specifiy for itself.
> 
> Yeah. Just a hint that can be ignored, if "in-place broken" is 
> assumed.

yes - in-place-safe is a hint.  Assume broken by default.

> If you think of it this way: SET gets an extra argument 'duration' 
> that you would "normally" set to 0. *If* you use another value, the 
> event effectively becomes a RAMP event.
> 
> Or as I've previously expressed it; define RAMP with a zero duration 
> to be a SET operation. Slight special case, but if you actually try 
> 
> Now, whether we should call that single event RAMP or SET is open. I 
> would suggest CONTROL instead, as that's less specific and thus, less 
> missleading. Besides, it has the advantage of appearing to be related 
> to controls - which is very true. :-)

Good enough for me.

> > I rather like normalized values.  I've been contemplating this
> > problem, myself.  I don't like having to call normalize functions
> > for every translation, though.  Can the translation overhead be
> > minimized?
> 
> Consider this:
> 
> 	* Controls that are meant to be connected generally
> 	  have the same units and the same ranges.

What about generic controller plugins?  A generic envelope controller or
LFO.  Normalized values just work (assuming we can define normalized - it's
not easy :)  Or we can just say that things like that output normalized
data, and have to be passed through some sort of scalar.

> > I actually have this in my own notes for XAP - an optional way for
> > the plugin to save 'extra stuff' with a preset or document.
> 
> How about combining a few "old" features here:
> 
> 	* An output must initialize the connected input
> 	  as soon as audio processing continues.

> Now, give one or more row data control outputs a suitable type hint, 
> such as "INSTANCE_STATE", so hosts can just connect them, call 
> process() for 0 frames and store the data somewhere. No extra calls 

hmm, so to save a preset you'd have to connect the INTERNAL_CRAP control to
something and process(0)?  I don't know.  Just saying 
plug->save_extra_state(raw_data *r); seems cleaner, to me.  I am also
contemplating saying that controls need to be readable, just because it irks
me that they're not.

Tim