[linux-audio-dev] PTAF link and comments

David Olofson david at olofson.net
Tue Feb 4 23:39:01 UTC 2003


On Wednesday 05 February 2003 04.38, Tim Hockin wrote:
> > Any suggestions for scripting language? Python, Lua, Java...?
> > (Though
>
> TCL?  easy, cross platform..  Maybe Perl?

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!


> 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.
>
> 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.


>  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.

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.


> > > 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.

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.)


> 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 ---




More information about the Linux-audio-dev mailing list