[chuck-users] Killing thread from without

Hans Aberg 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  
>> 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,  

> 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:
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  
>> 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.


More information about the chuck-users mailing list