4 Feb
2003
4 Feb
'03
9:08 p.m.
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.) 2) layout -
plugin provides XML or something suggesting it's UI,
host draws it
Basically like 1), but with some extra info, right? > 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. 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. 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. 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