[linux-audio-dev] PTAF link and comments

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


On Saturday 08 February 2003 06.51, Tim Hockin wrote:
> > > 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
>
> Using an output control for this is actually wrong, on another
> thought.  You would NEVER save a VOICE output control or anything
> else output with a preset.  Output goes to some other place.

That's exactly why it *should* be an output. If it was a "readable 
input", it would be saved with the preset whether you like it or not, 
and there's that problem with mysteriously mutating projects again.


> Just because we CAN get data out of an output control, doesn't make
> it consistent with the semantics of an output control.

It *could* still be, but as always, really, it's for the plugin to 
decide when it wants to update the value on an output. The only 
strict rule is that any output has to send it's current value 
directly after a connection is made. Some outputs might do *only* 
that, although it would actually make a lot of sense if these ones 
would update whenever you flip that "LEARN" switch.

So, you *could* have them connected at all times, and they would still 
work as expected.

As a matter of fact, if you just loop the output back to the input, 
the "LEARN" switch is all you need. Whenever you flip the switch to 
"off" the new data would be send back to the input. When you save a 
preset, the host would see the connection of the input and go look 
for the current value - which it finds on that output.

Just make that loop and it all Just Works(TM). Cool, eh? :-)

If the plugin doesn't have a LEARN switch, it gets less sexy, but that 
could be done as well. If you have a user tool that can grab a value 
from an output and put it on an input, you'll be fine. You could 
easily do things like taking the "knowledge" output from a plugin in 
a dummy training net and writing it directly to the instance in the 
real net.


> We'd need Yet Another Flag that says a control is an output that is
> meant JUST for preset data.
>
> Ick?

Well, it should probably be hinted "don't make me a wire in a cable, 
please!", so hosts with that kind of connection features don't mess 
up when you chain these plugins. (You probably don't want to chain 
those unless you're looking for truly weird effects... Plugins 
learning from each other? :-)


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