[chuck-users] benchmarking UGens
signal.automatique at gmail.com
Wed Mar 11 10:08:57 EDT 2009
> We may be able to have a optimising compiler but we can't (preserving
> > current functionality) condence the UGen graph like some digital modulars
> > (simplifying groups of UGens internally). Well, maybe we could but even
> > thinking about it makes my head hurt. IMHO we need more facilities for
> > hot-swapping UGens, not less.
> That's basically true. Even if the compiler produced machine code as
> fast as C, it would still issue calls to connect up UGens the same way
> it is done now.
Yes, I was talking about optimising UGen performance though. There are some
digital modular synths that optimise by taking a group of "UGens" and
converting those to instructions in a optimised way. I meant we couldn't do
that as we want to be able to re-route them.
> On the other hand, if the compiler really could generate code that
> fast, it would be worthwhile to implement UGens directly in ChucK.
I still think that would be worthwhile to have as a option. Even if it would
be slow(er) it would be great for prototyping and would lead to cleaner
code. For example; I sometimes use a overdrive that consists of a a set of
UGens. When I use that a few times, on a few sounds, I end up with code that
may work and be relatively fast but that's not so pretty.
> I've been playing more and more with LLVM lately, but still too early
> to say anything. I was messing around with the ChucK compiler
> previously, and found a few places to play with its opcode generator.
> Don't hold your breath though, as I'm way too busy on other things. :)
> I'd love to spend some more time with it in the summer though.
Could you explain what you mean by "ChucK's opcode generator"? "Opcode" is a
CSound term that translates roughly to "UGen", right?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the chuck-users