Steve;<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">That's basically true. It's not _impossible_ to optimize them<br>
(inlining "tick" functions, etc), but it would be a completely<br>
different problem to tackle. A pretty interesting one however!<br>
<div class="im"></div></blockquote><div><br>That would be a interesting approach indeed. We would need to be careful and make sure we could still consider the internal state of individual UGens in such a graph, as we may want to change the UGen graph with as few glitches as possible.<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;"><div class="im"><br>
</div>Sorry for the confusion. I meant opcode as it is used in talking<br>
about compilers. The word just refers to "operation codes", i.e.,<br>
codes that represent machine instructions. In ChucK, its VM opcodes<br>
are actually instances of the Chuck_Instr class. Not the same as<br>
CSound's opcodes. (Though, shamefully, I don't actually know CSound<br>
very well.)<br>
<div></div></blockquote><div><br>Ah, I see. IMHO CSound is nice as it's so old and established that many very worthwhile articles have been written with it in mind. It can pay off to be able to read it to be able to understand those articles. To me personally it does look a lot like a language that's decades old if we compare it to ChucK; I think you'll be fine without it.<br>
</div></div> Anyway, that's something completely different indeed. Fortunately we have words like "spork" and "shred", at least those won't easily be confused with other concepts elsewhere!<br>
<br>Yours,<br>Kas.<br>