5 Feb
2003
5 Feb
'03
12:39 a.m.
On Wednesday 05 February 2003 04.38, Tim Hockin wrote:
Dunno... Both seem to be rather "messy" for non-programmers to get
into - and by all means, I expect most serious GUI designers to be
non-programmers, more or less. There are exceptions, but generally,
graphics/design isn't nearly as related to coding as music. Finding
people with interest and skills in all three fields is probably
pretty hard - especially if you're looking for volunteers!
so maybe output controls should be more strict than input controls?
Why? It' actually the inputs that blow up if they get bad data, so
they should be equally careful to specify ranges.
This is provided there is no need for raw data controls at all,
obviously. If there is, they'll be there anyway, which is the basic
motivation behind my idea.
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.
Well, yes; there's one thing I forgot to mention: There would have to
be in/out pairs for these things, of course. Unless the plugin really
cannot change or generate data. If it can't, the data will have to
come from some other plugin - like the GUI - which means you'll get
the data to store from there instead, just like with normal controls.
(The "no need to read back what we write" rule.)
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:
[...XML style stuff
etc...]
No scripting language needed for this level of
rudimentary support.
Just a well-defined schema and image file format.
Right, and that seems realistically doable by all means.
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. Or do we just normalize 'generic' outputs?
Well, what is a "generic output", really? Looks like just another unit
+ range combo to me, and all it means is it's *supposed* to map to
all sorts of inputs. Problem is that it's still not obvious how do
actually get it right.
[...]
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 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
Well, that eliminates the need for the in/out pair, which *is* a
special case after all.
However, how do you actually transfer the raw data through that call?
It's just not about a function call, but also about the data
transferred. We'll need an RT safe solution for the controls. What to
do here? Just assume that it's not RT safe? (Which means you can't
save states without taking plugins out of the net, or requiring that
they're thread safe WRT this call...)
Things are rarely as simple as they look... *heh*
//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 ---