- chuck-users - lists.cs.princeton.edu

wishlist for the new year
by Michael Heuer 11 Jan '10

11 Jan '10

Hello ChucKers, Good idea on having the documentation sprint -- it has sparked my interest in ChucK again. Given the time of year I thought I'd throw out my wish list for new ChucK features/enhancements: 1. Import/include mechanism with namespaces The import.ck mechanism in LiCK works ok, but is hard to maintain. All dependencies between classes have to be calculated manually so that all the Machine.adds are in the right order. Having 136 or however many it is classes in LiCK all in the same namespace (no namespace, or the "default package", that is) is a mess. 2. Java-style interface abstract classes, or multiple class inheritance I need either class Foo {} interface Bar {} interface Baz {} class Qux extends Foo implements Bar, Baz or class Foo {} class Bar {} class Baz {} class Qux extends Foo, Bar, Baz 3. Tool for generating ChucK class documentation from its source code (similar to doxygen or javadoc) 4. A way to soft-kill a shred when in an on-the-fly programming session By soft-kill, I mean kill the shread when it is no longer producing non-zero samples, not just kill it immediately. Using e.g. $ chuck - 1 is not pleasant when that shred is still producing sound. 5. Class/type introspection 6. Closures or function pointers 7. Constructors michael

11 37

FLOSS (user editable) manual for ChucK
by Tomasz Kaye's brain 11 Jan '10

11 Jan '10

Hi all. I noticed that there doesn't seem to currently be a user editable version of the ChucK manual online (http://wiki.cs.princeton.edu/index.php/ChucK/Manual this page is the nearest thing i found). While learning things there have been a few cases where I thought small changes to the manual wording would make things clearer (for instance my recent question about how Envelope works). I wondered about moving a copy of the ChucK manual to FLOSS Manuals, where it can be edited by users. http://en.flossmanuals.net/flossmanuals. I used this site in a recent Ardour booksprint I took part in. It's not perfect (sometimes navigation is a little unintuitive), but works well. It uses version history (different versions can be compared too). A user is appointed as a maintainers of a particular manual. Chapters can be edited by anyone with a FLOSS account, but maintainers get to decide when new versions of chapters are 'published' (made visible in the canonical version of the FLOSS manual, the one that guest visitors to the FLOSS manuals site will see) http://en.flossmanuals.net/FLOSSManuals/Maintainers . A few preliminary questions about the idea: @Ge: would you be okay with the current manual being copied to another site, and edited? (i couldn't find license details on the current manual). What do people think of this idea in general? Would people use it? Would it greatly confuse matters to have one more url for ChucK documentation? (any other issues?)

9 58

what is the process for suggesting improvements for the manual?
by Andrew Turley 11 Jan '10

11 Jan '10

I haven't found anything that "officially" describes how to suggest changes to the manual. I've spotted a few things that I think should be fixed, or at least discussed. At least one of them is an actual error, while others are suggestions for how certain sections might be improved. Having said that, I would like to thank everyone who contributed to the manual. It looks very useful, and seems to be off to a great start. andy

4 3

making a duration into a string?
by Robert Poor 11 Jan '10

11 Jan '10

How can I cast a duration into a string (e.g. for passing as a string argument)? Consider: // ============= fun void log(string message) { // do something to log the message } 1::second => dur d; log("the duration is " + d); // fails with "cannot perform '+' on object references" log("the duration is " + d.toString()); // fails with "type 'dur' does not have members" // ============= Same question for time objects. TIA. - Rob

4 7

10.6 multiple chucks
by dan trueman 10 Jan '10

10 Jan '10

hey any OSX 10.6 users out there? it seems that it's impossible to run two chucks in separate Terminal windows under 10.6. can anyone confirm or refute this? oy! dan

6 14

chuck crash
by Steve M. Robbins 01 Jan '10

01 Jan '10

Hi, I've discovered chuck only a few days ago so I'm working through tutorials. Today I tried the following code from Graham Coleman's tutorial http://www.iua.upf.es/~gcoleman/chuck/tutorial/tutorial.html //connect a plucked string to the soundcard out StifKarp inst => dac; [0,2,3,1,4,2,6,3,4,4] @=> int mel[]; //sequence data for (0=>int i; ; i++) { //infinite loop std.mtof( 48 + mel[i%mel.cap()] ) => inst.freq; //set the note inst.noteOn( 0.5 ); //play a note at half volume 300::ms => now; //compute audio for 0.3 sec } This crashes chuck (v 1.2.1.3) at the "for" loop line. The code presumably used to work. Has the language changed or is this a simple bug? Thanks, -Steve

2 1

Chuck-ing SinOsc inputs
by Robert Poor 31 Dec '09

31 Dec '09

What is the predicted effect of: SinOsc s1 => SinOsc s2 => dac; ? I was expecting some form of FM, but instead I'm met with stony silence (*). I understand that the .op parameter controls how the input to a UGen is interpreted, but I don't see any documentation on the effect of chucking to a SinOsc input. If the real answer "go read Ge's thesis", I can handle that, but I was hoping for more instant gratification. Thanks in advance... - Rob (*) Of course, I've also initialized gains and frequencies to reasonable values. The full code is: SinOsc s1 => SinOsc s2 => dac; 330.0 => s1.freq; 1.0 => s1.gain; 440.0 => s2.freq; 1.0 => s2.gain; 1::second => now;

2 2

LiSa duration issue
by Kassen 30 Dec '09

30 Dec '09

Fellow ChucKists, Dear Dan, Two minor issues with LiSa.duration(). When we set the recording buffer to any size over 100::second a error will be given. However, the error won't make it clear it's coming from LiSa. In larger .ck files that also involve -for example- fft and the like it becomes a minor chore to detect the source of that warning message. This does not match the behaviour of other UGens and is generally inconvenient so I'd like to suggest pre-pending "LiSa; " to it. Though extremely minor I feel this is a issue. The second point is more subjective and open for debate. I feel that 100::second for the max duration made sense back when LiSa could only .record() but these days we can fill her memory using valueAt() and using longer buffers becomes practical. On top of that loading files straight into LiSa has been hinted at. Are there reasons to not extend this max to 10::minute or something in that order of magnitude? Would there be real issues with setting it to 1::hour and leaving people to shoot their own RAM-foot if and when they really wanted to? We allocate and free this memory properly, right? It is already possible to casually have ChucK blow your RAM out the window if you really wanted to; float foo[1000][1000][1000][1000]; //don't actually run this Yours, Kas.

2 2

Issue/bug tracker system?
by Tomasz Kaye 30 Dec '09

30 Dec '09

Would an issue/bug tracker system be useful to ChucK people? Working on the manual sprint got me thinking about the way bugs are currently handled. From a users point of view i think that a web based tracking system has the following advantages: 1. It removes doubt that I might be filing a duplicate bug report (I don't want to needlessly make noise). 2. It would avoid having to pester people to find out what the status of a bug is. As a test I went ahead and registered one with lighthouse which seems like a nice system (free to use for open source projects) http://chuckissues.lighthouseapp.com/ My favourite bug is listed there already ;) Any thoughts, comments etc appreciated. Would devs use this? Thanks, Tomasz

7 13

Hid open by string [bug]
by Kassen 22 Dec '09

22 Dec '09

Fellow ChucKists, Dear Spencer. I was going over the VERSIONS file, looking for more things that are lacking in the manual and found the .open( string name ) member function for Hid and HidIn. As far as I can tell this works fine, provided we know the exact name of the device. The following example will instead crash; HidIn hi; hi.open( "foo" ); ...this is of course assuming you don't accidentally have a device named "foo". The following does work for me; HidIn hi; hi.open("SynPS/2 Synaptics TouchPad"); It seems like the existence of the device isn't properly verified before ChucK attempts to open it. Tested using the latest mini on Ubuntu 9.10 Yours, Kas.

4 9