[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