On 22 Apr 2009, at 17:31, Kassen wrote:

...

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.

I agree, that would be nice but I don't need it especially badly.

Les Hall, thread "Keyboard Stuff", seemed trying to do something similar.

I think there is probably more interest in extending the graphical elements of the MiniAudicle.

That would require more work. I'm not sure how the console display is done - perhaps it suffices with access to control characters.

...

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.

Yes, but ChucK itself (unlike the miniAudicle and the Audicle) doesn't need any graphics manager. You can run ChucK from your CLI without starting your graphical manager (I'm not sure OSX will allow that, on Linux you can hit Ctrl + Alt + Fn where n is 1-6, in Windows you can pick this at startup). I sometimes do that, if ChucK would use Gtk we'd lose that ability.

I have only run 'chuck' from the console. If there is a GUI, one does not need to start it - just have a command line option.

...

Well, it may be intended, but "verbose" is not explained in the manual (just one occurrence).

It's documented in the online docs; http://chuck.cs.princeton.edu/doc/program/vm.html

I tend to prefer a local PDF, as it is easy to search.

If you'd argue that that implies that "verbose0" should stop printouts of started shreds I'd probably have to agree with you. I don't think anyone anticipated that somebody would want to stop this kind of printout but they could become a serious issue when we'd use shreds for grains and would start sporking a few hundred per second.

Yes, threads can be produced in large numbers: that is the point of them. Is there a way to schedule a thread ahead? Like in this pseudocode: // CReate a function for later use as thread: foo(int x, int y) {...} ... // set a thread foo(3,5) to start at time 1100::ms + now: schedule(foo(3,5), 1100::ms + now).id() => int id0; ... // If is pressed key: prevent the thread from sporking: if (id != 0) remove(id0); Hans