Atte;<br><br>Another day, more testing!<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;">They are indeed more expensive than their counterparts. Number of harmonics doesn't seem to matter, though (see link below).<div class="im">
</div></blockquote><div><br><br>Interesting; I expected them to be more expensive but I wasn't sure we could get any number of harmonics for that price.<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>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Another interesting thing to compare might be LiSa with multiple voices v.s. as many copies of SndBuf.<br>
</blockquote>
<br></div>
Hmm. Could you supply a test file for this?<div class="im"></div></blockquote><div><br><br>Let me think about this because doing this in a way that's as neutral as possible doesn't seem so easy now that I considered it.<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>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The list goes on; we might want to know the cost of member functions like the .freq() parameter of filters, we may even want to know the cost of certain operations.<br>
</blockquote>
<br></div>
But this (and other operations needs to be done at a rate. Would every samp make sense? Or should we pump more operations per samp, for instance with a inline repeat?<br>
</blockquote><div><br>I'd say we need to do it at whatever rate gives us numbers in a 40-80% (or so) CPU usage range because of the factors you pointed out previously; at too little CPU usage other factors weigh too heavily, at too much the measuring will likely become inaccurate. Maybe a inline repeat makes more sense than looping at fractions of a samp; we'd have less conditions (per second) but that would also make the code slightly more complicated and I'm also in favour of simple code here for simple analysis. Sigh; not so easy, this.<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>
Another thing: Some UGens could prove more expensive in use (Envelope and ADSR seems to fall into this category), which ones should I test, and how? For Envelope/ADSR I simply connected them to a SinOsc, and found that the cost of ADSR => SinOsc => dac is more than ADSR => dac + SinOsc => dac.<br>
</blockquote><div><br>The one difference I know for sure is there is that in the case of chaining them up there will be a second UGen pulling ticks through the chain; you won't have just dac polling the envelope and the osc but you'll have dac polling the osc, then the osc polling the envelope. Maybe that's more expensive. It could also be that SinOsc calculates numbers in a more complicated way when it's fed a signal to it's sync input? I suppose that to get beyond this we're simply going to have to dig into the code to see what exactly is going on there. There might be something going on that will be interesting should we want to optimise UGen graphs for speed of calculation.<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've wrapped it up a bit, with direct links to the test files for easier browsing:<br>
<br>
<a href="http://atte.dk/chuck/" target="_blank">http://atte.dk/chuck/</a><div><div></div><div class="h5"><br>
</div></div></blockquote><div><br>Cool!<br><br>Kas. <br></div></div><br>