[linux-audio-dev] PTAF link and comments
Tim Hockin
thockin at hockin.org
Sat Feb 8 00:06:01 UTC 2003
[ 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.
More information about the Linux-audio-dev
mailing list