Subject: Re: [linux-audio-dev] PTAF link and comments
From: Tim Hockin (thockin@hockin.org)
Date: Wed Feb 05 2003 - 05:38:42 EET
> Any suggestions for scripting language? Python, Lua, Java...? (Though
TCL? easy, cross platform.. Maybe Perl? But this goes beyond what I was
suggesting. I meant to suggest something like:
<UI name="timsynth" image="tim_bg.xpm">
<KNOB x="15" y="15 image="tim_knob.xpm" width="50" height="50">
CUT
</KNOB>
<KNOB x="115" y="115 image="tim_knob.xpm" width="50" height="50">
RES
</KNOB>
</UI>
And it would draw the tim_bg.xpm, with two knobs on it. Knob.xpm would have
64 50x50 images of the knob in one of 64 positions. The knob bitmap would
be overlayed on the background. When the user turns it, the host blits in a
different slice of the knob image.
No scripting language needed for this level of rudimentary support. Just a
well-defined schema and image file format.
> > Or we can just say that
> > things like that output normalized data, and have to be passed
> > through some sort of scalar.
>
> That makes a great deal of sense.
so maybe output controls should be more strict than input controls? Or do
we just normalize 'generic' outputs?
> > hmm, so to save a preset you'd have to connect the INTERNAL_CRAP
> > control to something and process(0)? I don't know. Just saying
> > plug->save_extra_state(raw_data *r); seems cleaner, to me.
>
> Yes, but that requires special case handling on both sides. "Polling"
> and/or analyzing comunication between plugins is something you'll
> have to do in hosts anyway, unless this save_extra_state() becomes
> non-optional and renamed save_state().
This is not done often - just at document save time or when exporting a
preset. Save all controls, and ask the plugin to give you a raw-data
control via a special method. Yeah, it's a special method, but it is a
special case.
> That is, if we already have a standard way of keeping track of plugin
> states, why use a different API for the non-standard data, rather
> than just relying on what has to be there anyway?
Because this is data that you can't know about (internal crap - like fftw
wisdom or something). Since it is different, treat it cleanly, not hack a
way into the existing mechanism just so it doesn't taste different.
> > also contemplating saying that controls need to be readable, just
> > because it irks me that they're not.
>
> It's not perfect, but I don't see how we can safely avoid having some
> form of "raw data" interfaces. "Private" stuff going on between GUIs
Raw data is definitely needed, no doubt. Seperate issue. If controls are
readable, we don't have to hack anything, we just read a raw-data control
called PRIVATE.
So the way I see saving the state of a plugin:
For each control
save snooped control data to output (maybe XML)
endfor
if (plug->get_extra_state)
d = plug->get_extra_state()
save d as if it were a raw control
endif
Tim
This archive was generated by hypermail 2b28 : Wed Feb 05 2003 - 05:41:01 EET