[linux-audio-dev] PTAF link and comments

David Olofson david at olofson.net
Thu Feb 6 14:02:00 UTC 2003


On Thursday 06 February 2003 06.29, Tim Hockin wrote:
> > > > > right, we only need to 'read' data we didn't write.
> > > >
> > > > Actually, do we? Where would that data come from?
> > >
> > > Internal.
> >
> > Yes - but it has to come from somewhere, and it has to make sense
> > to write it back.
>
> It comes from the plugin.  The point is that we can't know wht a
> plugin might want to save here.

Then we don't know when to save it, or when to write it back either, I 
think. Is it state data (delay buffers, filter states etc) or 
"private" parameter data (FFT spectra, impulses, waveforms etc)?


[...default values...]
> I'd write my plugins to read their own descriptor struct for their
> default values, or use constant definitions.

Both alternatives mean code that you have to get right in every 
plugin.


> > How about allowing lazy plugins to ask the host to load their
> > defaults for them?
>
> It won't hurt for a plugin and host to BOTH do it.  I just think
> that defaults should be set by the plugin.  It doesn't cost
> anything beyond init time, and just seems RIGHT.

I just don't like the idea of having the same data in two places, or 
implementing code for stuff that could be done by the host. Some 
plugin SDK tool to parse metadata and set controls would make me 
happy, but the latter has only one standard interface (events), which 
cannot be used without calling run().

Besides, don't forget that setting a control is generally quite a bit 
more work than just putting the control value somewhere. Some of the 
Audiality FX plugins call their own control() callbacks to load and 
*implement* defaults, but that's only doable because FX controls are 
not (yet) event driven.


> > > examples I can think of right now are things like fftw wisdom
> > > or maybe tables for a wave-table synth with custom waveforms. 
> > > In fact that is a good one.
> >
> > This sounds like a form of control data to me. It's stuff that
> > you can't get back in there in any other way than explicitly
> > writing it back.
>
> No, it's related to controls.  It is not control data.

*How* is it reated to controls? Either it's state information (ie 
history affected by control and/or audio input) or it *is* control 
data. There's a big difference in the way you'd use those two things.


[...]
> I don't want non-control controls.  Controls are controls.  And we
> have a way of knowing their data.  What I am saying is that there
> might be some state that the plugin wants to save with a preset
> that is NOT user controllable and is not a control.

Then it's *state* data. I don't think mixing that up with non-standard 
control/parameter data does any good.


> > We have discussed presets and basically concluded that a preset
> > is nothing but a full set of control input values. This is where
> > most
>
> Right.  Except what of a plugin that wants to store <something
> else> with the preset.  This is stuff that it has generated and
> wants to come back with the preset.

Like state of a neural network and that kind of stuff? Yeah, then I 
think I get your point. Each instance of a plugin should be able to 
remember what it's learned in the environment it's been used.

However, I still think this is a form of control data. The only 
differences are that the plugin will dynamically change the *internal 
version* of this data (just like plugins that filter control input!), 
and that it might be of interest to save the internal state, to keep 
developing it later.

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

If, OTOH, we implement this as two separate controls; one input and 
one output, this becomes explicit and user controllable. The plugin 
has an output from which you can read data that represents what the 
plugin has learned so far. It also has a compatible input where you 
can write anything you've read from the input, to literally move the 
plugin back to the state it was in when you read that data.

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.


> > We have controls for everything, and that's really rather handy
> > in many ways. Let's not ruin that design.
>
> OK, then we need a way to read controls, directly.  Then the plugin
> can just use a raw control for it's internal junk.

No need for direct reading of inputs. The "internal junk" format 
controls still have to obey the general rules for controls, or we'll 
create a real mess.

So, there are only two things you can ever find on an input:
	1) The default value (whatever put it there...)
	2) Some value you wrote there.

The obvious question is "What created the value for 2)?" Well, in the 
normal case, it would be some other plugin (including sequencers and 
real time input translators), or it's the plugin's custom GUI.

Or, it comes from the internal "editor" of the plugin, and is 
available from an output with the same format.


And actual state data, as in "I want it to sound *exactly* as if I 
started playing a recorded version of the full song from the position 
this was grabbed", is still something else. *That's* where function 
calls or some other special interface would make senes to me. It 
basically involves musical time as an implicit qualifier for the 
data, and tells the plugin to step aside from normal operation. As 
such, it does not map to the control paradigm very well.


[...]
> I don't think raw data controls are special in any way...

Right - so they shouldn't have a special API either, if we can help 
it. It just seems hairy and pointless to try to guarantee identical 
semantics in a different, parallel interface.


> > > plug->get_extra_state() hands back a raw-data block.  We can
> > > base64 it and store it in our XML preset file, or whatever we
> > > want.  When we reload a document, plug->set_extra_state() gets
> > > the raw_data block back, if we have one.
> >
> > Yes, I see. But I still don't see how you wold *create* that data
> > in
>
> YOU don't.  The PLUGIN does.

Agreed.


> Maybe it's not needed at all, but I
> suspect that if we provide it, it will get used.

Well, if you're thinking of what I describe above, it's certainly both 
very interesting and useful.

Many VST plugins (like noise reduction plugins) do this - although VST 
doesn't really support it. It has to be implemented on top of the 
existing parameter interface one way or another. The only reason it 
works properly is that VST plugins handle presets themselves, so it's 
no big deal if some of them do slightly "weird" stuff in this area.


> > Maybe. It seems to me that the *_extra_state() calls are just
> > half a solution, since they can only be used to save and load
> > data that cannot be edited. I must be missign something.
>
> That is correct - they just save some chunk of crap that the plugin
> wants to know when you reload it.

Yes - but *when* do you save this data? Since it changes all the time 
(unless you have an explicit "LEARN" switch control), I'm pretty sure 
I wouldn't want the host to reread and save it every time I hit 
"Save" in the host app.


> Why is that half the solution? 

Because I was too tired to figure out what I've explained above, about 
plugins being their own editors. :-)


> What other half of the problem exists?

The UI, basically. When to save etc.


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