2009/8/22 Lucas Samaruga <samarugalucas@gmail.com>
I was referring to the musical style.

That's interesting. I've been wondering how syntax might affect music. Why can I often recognise MAX by ear, for example?

I don't know...
 

I think the recursion is very good in this case.

Yeah, and it even works nicely. The technique is viable, at least... Though of course GC would help a lot here for serious work.

 

I don't understand this cast to UGens not defined

       1.0 / n => (bar $ Phasor).phase;
       (n%3) + 1 => (bar $ PulseOsc).sync;
       (75 * (n-1)) + 1 => bar.gain;
       (5 * n) => (bar $ Shakers).freq;


Deliberate perversity. I needed to cast to UGens of a type that had the member-function in question as UGen itself doesn't. We are fooling the type-system here, the only thing that really matters is the name of the member function. This, BTW, is why it's "playing with fire", we lose the protection of the type-system and so one typo in the name of the member function would mean a machine crash.

I would advocate that the type system hierarchy here would be more like with the STK instruments, going;

Object, UGen, Osc, (TriOsc/SqrOsc/SawOsc/PulseOsc/Phasor)

All of those plain oscs have the same member functions and indeed behind the scenes I think they inherit (with Phasor being the core one). I don't think there is a real need for ChucK requiring this cast here. It would be more convenient (and potentially safe) to have a base-class, like the STK instruments can be used interchangably with regard to NoteOn() and .freq().

Basically we *do* have a lot of the "duck typing" that some have requested, you just need to be absolutely sure you do know it's a duck (or at least a goose) or there will be crashes. Ge did mention "chucking excptions" as a wishlist item, but I'm not sure to what degree that is a word-pun on "throwing" or whether it is a serious plan. Fortunately there is nothing wrong with word-puns inspiring features....

Kas.