[linux-audio-dev] PTAF link and comments

[Tim Hockin]

> > right, we only need to 'read' data we didn't write.
> 
> Actually, do we? Where would that data come from?

Internal.

> 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.  Might as
well be defaults.

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

It is somewhat related to a control, but it is not input or output.  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.

Am I clearer with a real example?

> > I'd assume this is NOT RT safe.  Don't save a preset while your
> > track is running :)
> 
> I don't like that. It seems nasty to prevent people from saving their 
> work without shutting down the whole engine for a moment. I'm 
> strongly opposed to the idea of confusing audio time with musical 
> time, and this is a typical example of assuming they're almost the 
> same. Stopping the sequencer does *not* mean the audio engine stops. 
> It *might* in some apps, but that's incompatible with what most users 
> of "real" synths expect, and should not be enforced.

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.