Subject: Re: [linux-audio-dev] PTAF link and comments
From: Tim Hockin (thockin@hockin.org)
Date: Thu Feb 06 2003 - 07:29:48 EET
> > > > 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.
> > 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.
>
> 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.
I'd write my plugins to read their own descriptor struct for their default
values, or use constant definitions.
> 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.
> > 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.
> I think it's a very big difference. I also dislike the idea of
> treating *some* control data in completely different ways.
> Parameters. Most plugin APIs have both parameters and controls, but I
> see nothing but poorly motivated redundancy.
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.
> 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.
> 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.
> 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.
I don't think raw data controls are special in any way...
> > 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. Maybe it's not needed at all, but I suspect
that if we provide it, it will get used.
> 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. Why is that half the solution? What other half of
the problem exists?
Tim
This archive was generated by hypermail 2b28 : Thu Feb 06 2003 - 07:32:08 EET