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;">But if the prize of driving were magnitudes lower (say $.01) than candy and pizza and you could only pickup one thing at a time, you could compare the prize of candy and pizza by getting 100 of each:<br>
<br>
pizza: 100 * (4 + 0.01) = 401<br>
candy: 100 * (2 + 0.01) = 201<br>
<br>
Still the picture is a little screwed by the cost of driving, but if that's low (and my tests suggest the shreds are) you're pretty close.</blockquote><div><br>That's fair, yes, but the cost of shreds is non-zero, maybe this was affected by me test on the miniAudicle which also reports on the length of tine a shred has been running for, creating more of a per-shred overhead. Only picking up a single type of product seems like the way to go.<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>
<br>
Still I'm gonna work with your idea! Stupid me doesn't know of a way to pass arguments to a chuck file from the commandline. I'd rather not have the 100 as in "create 100 SinOsc's" hardcoded in the files.<div>
<div></div><div class="h5"><br>
</div></div></blockquote><div>Well, even if the difference is slight I do think my idea has some merit.<br><br>Comand line argument syntax is documented in VERSIONS.txt in your ChucK dir as well as in a example or two in the examples dir. Regardless of the exact numerical outcome using those should simplify the testing process which has advantages in itself. For one thing the outcome of a more simple test should be more simple to analyse.<br>
<br>That might go some way in preventing that guy from killing us :¬).<br><br>Happy testing!<br>Kas.<br></div></div><br>