OR: it wasn't connected to dac :-)
Right, yes, that would explain it :¬)
I'm not sure it was on purpose, but agree it's confusing at least by looking at the filename (I suspect you didn't look at the chuck code). With it connected it looks different:
Ah, yes. (pasting your notes from your other mail here)
> This means that the non-playing trick "s.samples() => s.pos" won't
do anything for the cpu (which I thought). It must be disconnected from
dac to be easy on the cpu...
That's right; that trick saves the ears, not the cpu. It's still a good trick as it saves a lot of noise in setups where we use a lot of samples.
A different story: Do you have any ideas about how to test stuff like multiplication vs division?
What I came up seems very close to your solution
These results lead me to believe that the usual rave about division being expensive it totally irrelevant as soon as you connect even a single UGen in your chuck code :-)
The difference seems quite small indeed; intersting. I wonder how conditions compare against those; I always thought those were relatively expensive.
PS; As a side note; GMail users can enable a google labs extension that will allow them to view selected emails in fixed-width font. This makes looking at tables like this a lot more convenient.
My lifestyle forces me to use a web-based solution. I'd like to say that's because of traveling so much but in reality it has to do with tinkering with computers and OS's and occasionally having lost a install and all the mail archives that were in it :¬)
Kas.