2009/8/22 Lucas Samaruga
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.