4 Feb
2003
4 Feb
'03
11:48 p.m.
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. 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(). 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