Subject: Re: [linux-audio-dev] PTAF link and comments
From: David Olofson (david@olofson.net)
Date: Thu Feb 06 2003 - 03:40:34 EET
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 ---
This archive was generated by hypermail 2b28 : Thu Feb 06 2003 - 03:43:42 EET