Atte; And regarding WM (Window manager) I used to chuck in tty, with X killed, but
recently it seems that I cannot get more performance (ok maybe <5% at the most) that way. So now I'm usually sticking to gnome with bells/whistles.
That's roughly what I found too. The bells&whistles run -mostly- on the GPU anyway. I think it will only matter at extremely low buffer settings where the occasional usage spike of non-ChucK processes may cause a glitch. We need the context-sensitive block processing as it's our lack of block processing that is the main reason ChucK takes a comparatively large amount of cpu. The context-sensitive version (as in; no block processing for parts of the UGen graph that have feedback) sounds like a very good idea, I think it should be possible, in a way it even seems obvious. The one issue is that I don;t think anyone else has ever done that. That one should be a big leap in performance, after that we may have to think about multi-core support. Strongly typed multi-core support sounds distinctly non-trivial to me. I think Ge was looking into it but the problem is notoriously hard and we are smack in the middle of the kind of area where it's especially hard, for what I understand of it. Yours, Kas.