> 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
