<br><br><div class="gmail_quote">2009/8/22 Lucas Samaruga <span dir="ltr">&lt;<a href="mailto:samarugalucas@gmail.com">samarugalucas@gmail.com</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I was referring to the musical style.</blockquote><div><br>That&#39;s interesting. I&#39;ve been wondering how syntax might affect music. Why can I often recognise MAX by ear, for example?<br><br>I don&#39;t know...<br> <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
I think the recursion is very good in this case.</blockquote><div><br>Yeah, and it even works nicely. The technique is viable, at least... Though of course GC would help a lot here for serious work.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I don&#39;t understand this cast to UGens not defined<br>
<div class="im"><br>
        1.0 / n =&gt; (bar $ Phasor).phase;<br>
        (n%3) + 1 =&gt; (bar $ PulseOsc).sync;<br>
        (75 * (n-1)) + 1 =&gt; bar.gain;<br>
        (5 * n) =&gt; (bar $ Shakers).freq;<br>
<br>
</div></blockquote><div><br>Deliberate perversity. I needed to cast to UGens of a type that had the member-function in question as UGen itself doesn&#39;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&#39;s &quot;playing with fire&quot;, we lose the protection of the type-system and so one typo in the name of the member function would mean a machine crash.<br>
<br>I would advocate that the type system hierarchy here would be more like with the STK instruments, going;<br><br>Object, UGen, Osc, (TriOsc/SqrOsc/SawOsc/PulseOsc/Phasor)<br><br>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&#39;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().<br>
</div></div><br>Basically we *do* have a lot of the &quot;duck typing&quot; that some have requested, you just need to be absolutely sure you do know it&#39;s a duck (or at least a goose) or there will be crashes. Ge did mention &quot;chucking excptions&quot; as a wishlist item, but I&#39;m not sure to what degree that is a word-pun on &quot;throwing&quot; or whether it is a serious plan. Fortunately there is nothing wrong with word-puns inspiring features....<br>
<br>Kas.<br>