> We may be able to have a optimising compiler but we can't (preserving
> current functionality) condence the UGen graph like some digital modulars do
> (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?

Kas.