[linux-audio-dev] PTAF link and comments

[David Olofson]

On Wednesday 05 February 2003 23.57, 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.

Sounds like plugin state data to me, but other parts of this 
discussion suggest that it's for *parameter* data that won't fit in 
standard control datatypes. These are two rather different things.


> > IIRC, we concluded that default values should be part of the
> > metadata, rather than built into the plugin code. Motivation:
> >
> > 	* Having plugins load defaults at some point would
> > 	  violate the semantics of inputs. Inputs should not
> > 	  change their values spontaneously, but *only* as a
> > 	  result of incoming CONTROL events.
>
> I don't know - if the metadata lists the default, do we really need
> to write that value to it, or can we assume that when you create
> the plugin the controls have their default values.  They have to
> have SOME value. 

Random garbage or zeroed?


> Might as well be defaults.

But then someone actually has to hack the code to put the right value 
in the right place - and get it right. Why do that *and* put the 
values in the metadata? I see redundant code, as well an easy way of 
creating strange bugs.

The only point I can see in having plugins doing it is that it would 
be a bit faster, which matters if you want to do real time 
instantiation.

I was thinking that you could provide a plugin SDK function that 
parses metadata and loads defaults through the control interface - 
but then I realized it's kind of nasty (if at all possible) to have 
plugins call their own run() callbacks from the wrong context. *heh*

How about allowing lazy plugins to ask the host to load their defaults 
for them?


> > Now, if this doesn't apply at all to the problems that you want
> > to address with save_extra_state(), please expand. I *suspect*
> > we're talking about two (or more) different features here.
>
> I am not sure what you're talking about anymore :)

*I'm* not sure about *anything*... ;-)


> I'm suggesting that with a document (song/track/whatever) a plugin
> may want to save some state that is NOT control data.  The only
> 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.

That is, it's *not* state data. State data can (at least 
theoretically) be reconstructed by creating a new instance and 
feeding the control and audio inputs with the exact same data as the 
original got.

I think it's a very big difference. I also dislike the idea of 
treating *some* control data in completely different ways.


> It is somewhat related to a control, but it is not input or output.

Parameters. Most plugin APIs have both parameters and controls, but I 
see nothing but poorly motivated redundancy.

We have discussed presets and basically concluded that a preset is 
nothing but a full set of control input values. This is where most 
plugin APIs use an alternative API instead - and as a result, you end 
up having to think carefully about what you want to make controllable 
in real time, and what you want to be able to save in presets. You 
*can* usually automate the parameters as well, but that's has to be 
handled specially by the host - and of course, it will generally not 
be sample accurate or support ramping. This all looks pointless, 
messy and restrictive to me.

We have controls for everything, and that's really rather handy in 
many ways. Let's not ruin that design.


Now, *state* data is another thing. It has nothing to do with "opaque 
control types" though, so that would be a *third* interface, provided 
we have a special one for raw data block controls.


>  It is internally generated and can safely be cached until the
> waveform changes.
>
> The host never reads or writes that data, but the plugin would like
> to save that data with the document or preset.
>
> 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 
the first place, unless there is an interface that a GUI plugin or 
similar can use to access it. If what you mention here is all there 
is to it, there's no reason to store the data, because it will have 
to be hardcoded into the plugin anyway.


> Am I clearer with a real example?

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.


[...]
> ok, so perhaps we can say that it falls under some RT constraints. 
> A plugin which has extra state has an RT problem.  If you want to
> call the extra_state functions you need to do it in a separate
> thread (thus mandating thread safety - ugg) or you need to remove
> it from the net.

Another way is to stream the data, block by block... *hehe*


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