Atte;<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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 &lt;5% at the most) that way. So now I&#39;m usually sticking to gnome with bells/whistles.<br>
<font class="Apple-style-span" color="#888888"><br></font></blockquote><div><br></div><div>That&#39;s roughly what I found too. The bells&amp;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.</div>
<div><br></div><div>We need the context-sensitive block processing as it&#39;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.</div>
<div><br></div><div>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&#39;s especially hard, for what I understand of it.</div>
<div><br></div><div>Yours,</div><div>Kas.</div></div>