[linux-audio-dev] PTAF link and comments

David Olofson david at olofson.net
Sat Feb 8 00:44:01 UTC 2003


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 ---




More information about the Linux-audio-dev mailing list