Atte;<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;"><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think getting as close as possible to the actual cost of a single UGen would be useful. We may have several ways of constructing a certain sound out of a few UGens, in that case the relative cost of single UGens would be quite relevant.<br>
</blockquote>
<br></div>
I'm not sure what you mean. Could you outline how one of the <a href="http://testfiles.ck" target="_blank">testfiles.ck</a> should look and how you propose I call chuck on it from my test script? Note that the "heavyness" on the cpu (in my case the number of instances of the .ck file) should be controllable from the bash script and hence not hardcoded into the chuck code.<div class="im">
<br>
</div></blockquote><div><br>Sorry. Here I meant we are working from the assumption that every UGen will have a (knowable) cost in cpu. So; if we want to create a certain sound in ChucK this will use certain UGens in a certain configuration. In some cases we will have several ways of creating a UGen graph that will yield this sound. At that point we may choose one option for it's CPU cost, but we can only make that choice knowing the cost of single UGens (so we may add those). Above I meant that for this scenario it makes a difference to know what those costs are -exactly- as opposed to just knowing what order the UGens are in if we'd order them based on CPU cost.<br>
<br>I meant this as a reason to be curious about the exact (as opposed to relative) cost of UGens, not as a speciffic scenario to test.<br></div></div><br>I hope that clarifies.<br><br>Yours,<br>Kas.<br>