Subject: Re: [linux-audio-dev] PTAF link and comments
From: Tim Hockin (thockin@hockin.org)
Date: Wed Feb 05 2003 - 02:58:48 EET
> 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
This archive was generated by hypermail 2b28 : Wed Feb 05 2003 - 03:00:07 EET