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