8 Feb
2003
8 Feb
'03
1:05 a.m.
[ 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.
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.
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.