On Saturday 08 February 2003 05.53, Tim Hockin wrote:
[ arguing get/set_extra_state()...]
Oh wait, there's one more difference. If we
just assume that this
is data that the plugin wants to store whenever you save a
project, we have major issue: A project will *change* in
non-obvious ways if you repeatedly play and save, without
explicitly editing anything. That sounds very scary to me...
urr, yeah. That is a good point. I'm willing to drop this one for
now. Let's go about our business and see if it ever is needed. at
which point we'll know a lot more about the problem.
My original thought was that we couls use it as a way to save time
when reloading a plugin. Stuff like wave-table data that is
calculated from a waveform once. We can always recalculate it, I
guess.
Yeah... Trying to bypass the normal "patch loading" process seems to
be a rather plugin specific performance hack. Seems hard to get
right.
As an example,
if you have a compressor that can adjust to how
you sing and handle a mike, just hook it up and sing some, to
"program" it. Then grab the state output data and save it in your
preset, as the "value" for the corresponding input. Whenever you
load that preset, the plugin will behave exactly like you trained
it to. (Or rather, the way it *thinks* you want it to. ;-)
In short, we're talking about DSP plugins that are also their own
parameter editors, using live input in non-obvious ways to do the
editing.
Sounds like a *very* interesting concept to me, and I definitely
think we should try to get the supporting interfaces right.
This is vaguely interesting - dunno if there is a real need for it,
or if existing interfaces need mods at all.
I would say there is a real need, since VST plugins do it, and VST
supports it through "abuse" of the parameter/preset interface.
Flip on the LEARN control, do your stuff. When you
flip off the
LEARN control a raw-data output is updated. We don't even need to
use a hint for LEARN - it is totally plugin unique.
Right. As long as there is suitable control datatypes, no additional
support is needed, really. It works without explicit support.
That said, it might be nice to allow plugins to somehow hint that an
output generates data that you may write back to a specified input of
the same type. This would allow hosts to be smart about this, rather
than just showing these controls as normal, totally unrelated inputs
and outputs. (Though they still are, technically. You *could* chain a
bunch of instances of such plugins through their "knowledge" control.
Probably pretty useless, but correct from the API POV.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`--------------------------->
http://olofson.net/audiality -'
---
http://olofson.net ---
http://www.reologica.se ---