On 22 Apr 2009, at 13:26, Kassen wrote:
ChucK needs to pipe these to some other process. Scala gets around this somehow - it uses Gtk.
Right, but plain ChucK -intentionally- doesn't depend on a graphical server (like X on Linux, Explorer on Windows and Quartz/Aqua on OSX).
It would be nice if one could generate a console display like when one is using programs like 'top -uR' or 'less'. That will work on computers that have terminal emulators like 'xterm' (and Terminal on Mac OS X). With it, one could display information about the output. For a playing keyboard, one might display information about the tuning, key shift, etc.
Most people will of course be using graphics and a mouse but you *can* use it without which might get relevant for installations and the like (or even when you simply don't feel like graphics). I'm not sure there is anything we could pipe it into that can be depended on cross platform.
For high level GUI, Scala now uses Gtk2 (Gtk+). It is available on Linux and Windows, I think. On Mac OS X, the situation is a bit messy. There is a package that has bindings directly to Aqua: http://www.gtk-osx.org/ but works only in Intel. Otherwise, it is simplest to use MacPorts, but one gets absolute paths to /opt/, which is not good for a standalone distribution. Installing it alone requires a lot of package chasing.
It would help to increase your buffer size but of course that would go at the expense of latency.
I'm not sure what buffers there are - I am on Mac OS X, which is Unix.
Buffers will be the same regardless of your platform. They refer to how many samples ChucK sends to your soundcard at a time. If your buffersize is larger there is more leeway for interuptions as the "deadline" to be done calculating the samples isn't quite as frequent.
I see now there is a --bufsize(N) option. Thanks.
It is more how I expect compilers to work. Both optimizations and extra warnings should one turn on by hand.
Yes, but there is a difference between the typical usage of -say- GCC and ChucK; with GCC your write it once and when it work it will compile all the time, hopefully for everyone and you are done. I'd say ChucK sits between that and something like Prolog where it's normal to have a dialogue with the interpreter until results are right.
Frequent printouts may cause problem, unless the printout delay problem can be solved. The problem with the thread-kills is that the programmers might have thought it being a rare event, like an exception, and not used as frequently as on every key release.
Anyway, it turns out that --verbose0 does not turn it off. So in view it chokes on printouts, it is a bug.
I respectfully disagree. I think everything works as intended and documented (here...).
Well, it may be intended, but "verbose" is not explained in the manual (just one occurrence).
I do think that turning all printouts off would be a good and useful feature to have, maybe something like "--verbose-1". I could see many cases like yours where printing except for printing from the code itself wouldn't have any use at all and it can indeed cause delays. Sporking hundreds of shreds, for example when using grains, could become a serious issue on some systems.
One can write stuff to a file, and then look at it using 'tail -f'. File writes are usually fast, and will not (I think) be disturbed by looking at it from another process. Info about thread-kills might be rewritten to stderr, as opposed to stdout, and redirected to a file. Hans