[chuck-users] Killing thread from without
haberg at math.su.se
Wed Apr 22 08:33:27 EDT 2009
On 22 Apr 2009, at 13:26, Kassen wrote:
>> ChucK needs to pipe these to some other process. Scala gets around
>> 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,
> 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
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:
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
>>> 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
> 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
>> 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.
More information about the chuck-users