soxchorus works

[luka]

(third time i'm writing this mail... bits have mercy)
yes... there were commas missing in the (3) mod_type param_specs - chased the 
bug trough and trough octal, found it in the machine :)
the start/min/max values were wrong because of the bug... trouble ahoy!
how do you turn such warnings on? gcc just glued two strings together like 
this: "aaa" "bbb" became "aaabbb" without blinking. now it's "aaa","bbb" like 
its meant

it works much better now, also looks nicer. v1.3 is in the cvs. 
i'll wait with the rest of the sox bunch until you release the new docs and 
change the core in cvs to match. anyone seen neil? i guess i should mail him 
directly. 

> 3. param_specs are specified as strings to allow easier future
> extension, rather than as a struct (what happens if we need new fields?)

i like this change. seems so scripting-influenced. :)
will the core have a struct for parsed data? 

> This should be the last of the non-backward-compatible changes. It's
> best to make them now while there are
> only a few machines. Everything else is extensions (package functions
> for the wavetable, etc.)

i think we need to nail the basic wave api real soon... just to test concepts, 
try a few sampler machines and see how it works. we can fix/add fancy stuff if 
necessary (when necessary) 

> Looking through, I notice the machine_type::num_params is set wrong in
> ox_init when the type is registered. There are 17 parameters but this is
> listed as 16.
i fixed that too

> I will look at the code asap... I can probably help port it.

update/event now gets called a lot - so some expressions after the switch 
statement gets re-calculated a lot also... some checks should be added so it 
would do this only when necessary.

if anyone looks at the soxchorus.c and explains the 'flanger' line (there's 
only one) i'd be grateful... why is it there? what does it do? is it ok?

LF