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

Detecting when child shred has finished
by Paul Reiners 20 Sep '08

20 Sep '08

Is it possible to determine when a child shred has finished executing if you have a reference to the child shred? For example, in this code: // define function go() fun void go() { // insert code } // spork another, store reference to new shred in offspring spork ~ go() => Shred @ offspring; Is it possible to determine when offspring is done executing?

3 2

infinitely stuck
by Kassen 19 Sep '08

19 Sep '08

Dear ChucKists, Another day, another novel and exciting way to get the whole VM stuck; Wurely w => dac; 1.0 / 0 => w.freq; 1 => w.noteOn; second => now; At a frequency of infinity (which admittedly is a bit silly but it happened by accident...) Wurley (and probably the other FM instruments as well, I imagine) gets completely stuck and takes 100% CPU time. This is quite understandable but what's not so nice is that this gets the whole VM stuck as well. Watchdog will offer to stop the shred (in the Mini) but fails... so that forces us to quit the whole thing the hard way. I think LiSa can cause a similar situation if we request a lot of voices very quickly, say one every few ms, and she runs out of voices (I'm not yet certain about the exact conditions there). Generally it seems like watchdog is unable to remidy the situation if it's a UGen and not a shred that gets stuck. I'm not sure how we should deal with this. Perhaps there could be some way to get watchdog to interupt UGens, or perhaps we should sanitise UGen function calls. I'm not sure, for example, whether there is a perceived need for fm electrical pianos to accept frequencies above the nequist... It probably can't be avoided that some things will get suck under some conditions but I would like to have some safeguards against this taking down the whole VM, where possible. Yours, Kas.

2 2

UGen v.s. code in timing; very tricky
by Kassen 19 Sep '08

19 Sep '08

Dear list. Suppose we have a SinOsc named "s", connected to the dac, that has been playing for some arbitrary amount of time at a arbitrary frequency. Suppose we'd like to disconnect this from the dac while minimising the "click". One thing to try would be this; (1 - s.phase() )::s.period() => now; //strong timing to the rescue! s =< dac; Quite ChucKian, I thought, however this still clicks a bit. Some clickery is to be expected as not all frequencies will have a period that can be expressed in a integer number of samp's but this seemed like a bit much. On a whim I tried; (1 - s.phase() )::s.period() + samp => now; s =< dac; This clicks less and when I print the s.last(), the value is on -average- lower in magnitude. I then tried lining up the shred's timing with the UGen graph's; samp - (now % samp) => now; //yes; that's quite anal (1 - s.phase() )::s.period() => now; s =< dac; This doesn't affect matters quite as much as simply adding a samp to the time advanced; waiting a extra sample generally seems (to me) to decrease the magnitude of the s.last() right before we disconnect it. This would lead us to ask; "where does this samp come from?". I'm a bit at loss here, does anybody have any insights? Yours, Kas.

4 7

determining the type of an Object in code
by mike clemow 17 Sep '08

17 Sep '08

Hi list, Is there a way to determine an object's type programmatically? Cheers, Mike -- http://semiotech.org http://semiotech.org/michael

8 27

Double ChucK cleanup (bug)
by Kassen 16 Sep '08

16 Sep '08

Fellow ChucKists, With the return of "double chucking" (making more then one connection between two UGens or a UGen and the dac) something seems to have gone wrong; SinOsc s=> dac; second=> now; s=> dac; second=> now; If this is run in a VM set to loop or a MiniAudicle with it's version of ChucK replaced with the latest greatest only a single connection will be cleaned up as the shred exits, meaning "s" will stay connected to the dac and as "s" is never garbage collected this means a beep. This also means there is no way at all to get rid of this beep (short of stopping the whole VM) as there is no way at all to reach the namespace "s" is/was in. I'm adding this to the WiKi as a bug. Yours, Kas.

3 5

what is Gluck?
by lucas samaruga 15 Sep '08

15 Sep '08

Hola a todos I have two questions. Somebody knows what is about Gluck (Ogl api)? Is something like fluxus or is for a GUI use within audicle? BTW: Fluxus like ChucK is a great project!!! www.pawfal.org BTW2: An unified language approach would be surely better, (a time based approach) *1. Inventor: I think it can be good for your multimedia projects (fluxus can manage and RECORD OSC events). Cheers Lucas *1 PS: Ok, I'm musician, I have my preferences.

6 11

setting static data at construction (bug)
by Kassen 12 Sep '08

12 Sep '08

Fellow ChucKists, I believe this to be a bug; ------------------------------------------------------- class foo { 3 => static int bar; } <<<foo.bar>>>; ---------------------------------------- For float, int and dur making members static prevents them being set to a default value at construction, instead they are defaulting to 0 (or 0::ms). I ran into this with dur, where it's obviously dangerous to make this mistake. Of course these constructs would (probably?) mean that initialising any instance of such a class would mean resetting the value for all instancesbut I'm dealing with classes that exclusively have static members and not intending to make any specific instances of them. Clearly this is easy to get around but I still feel it's a bug. Yours, Kas.

5 13

ProcessPP + STK = ChucK on steroids?
by Stephen Sinclair 11 Sep '08

11 Sep '08

This was posted on the LAD mailing list: http://tapas.affenbande.org/wordpress/?page_id=91 It's a "livecoding" environment for making music with C++. I bet if you combined it with STK you could get something like ChucK. :) (but, *shudder*, C++... can't stand it more and more these days) Steve

2 2

Re: [chuck-users] emacs, and other editors for chuck
by ynohtna 10 Sep '08

10 Sep '08

Yay, lots of Emacs users! I'm currently, in my spare time, looking into integrating Emacs with ChucK to streamline (live) coding and experimentation. I have recently prototyped an Emacs minor mode that supports real-time text-mode sequencing (sending arbitrary OSC messages via realtime modified Emacs Lisp code) and have been hacking Emacs on and off since the early 90s. So, if anyone wants to express their needs for such a thing I'd be happy to consider converting them into implementable features. No promises, though, as my daylight job often consumes all my computer-centric energy. So far, I have determined a wish list including syntax highlighting, "intellisense" style completion, mode-line representation of ChucK's status, automatic shred/spork replacement, and minibuffer display of micro-documentation for classes/functions/syntax under the point. Any other input is welcome. Anthony. (Sometimes short bearded, often stubbled, no sandals)

4 3

library additions
by Kassen 10 Sep '08

10 Sep '08

I added a section on MIDI and a link to Bruce Murphy's MIDI sender code. I'd prefer to have that code on the WIKI as well and perhaps merge it with Antimon/Stefan's work on MIDI clock out as that fills the largest hole there (see http://electro-music.com/forum/viewtopic.php?p=161799#161799 ), but it's not my code. Yours, Kas.

1 0

emacs, and other editors for chuck
by Stephen Sinclair 10 Sep '08

10 Sep '08

On Tue, Sep 9, 2008 at 10:29 AM, Kassen <signal.automatique(a)gmail.com> wrote: > Stephen Sinclair; > >> I don't use it (emacs ftw!) > > Would you have the time to share some of your thoughts on the advantages of > emacs for ChucKing? I looked at it but it's quite a daunting editor and I'd > like to know a bit about the potential gains before investing time in it. Hm, let's see. _mainly_ I use emacs because i'm used to it. I use it for coding, and my fingers know the shortcuts, and it just works for me. I've tried to get used to vim, for example, and just can't seem to do it. This goes for any editor, of course: use what you know, and what you like. I'm not on any mission to make people use specific software, I can't only make recommendations. However, there are some virtues, I think that deserve mention. (Some of these will of course be available in other programs.) One, is that emacs has "windows". You can drop a shell into one window, an editor into another, and a status window into a third. You can split the screen in any desireable way. Two, is that I have F6 configured for "compile", which gives me a one-liner shell command, and F7 for "recompile", which just repeats whatever the last compile command was. This is insanely useful for chucking, because you can hit F6 and tell chuck to load your script, and then take note of which shred ID it got, and use the '=' command to replace it the next time. Then just edit and keep hitting F7. On top of that, emacs has really good search & replace and regexp support. (I use the former more than the latter.) Which I have configured to Ctrl-A on my keyboard so that's a really fast thing to do. Then I can switch between files by hitting Ctrl-B and typing the first few letters of the file name and then Tab (if i've loaded it already) or load or create a new file with Ctrl-F. The filename completion rocks. Lastly, it's completely programmable with lisp. So if I wanted I could probably make it way more intelligently communicate with ChucK, interpreting its error messages among other things. But I don't have the patience for that. :) One thing that I sorely miss is the ability to automatically track which shred IDs get assigned to which files, for when I want to remove or replace a shred. However I think this is also partly the fault of ChucK which can't be bothered to tell me this information in a useful way, since it doesn't differentiate between files and sporks. But I'd love to be able to remove or replace a shred by *name* instead of by some number that I have to look way back in the buffer to find. (But of course Ctrl-S-S "search" is pretty quick for this.) All in all I don't have to take my hand off the keyboard, which is particularly nice. As for it being a daunting editor, I really only use a handful of commands, though of course it's capable of much more. > >> >> but I just tried to compile it quickly and >> it failed, so I can't help directly. > > Hmmm. I found the Mini quite easy to compile, at least since there is a > clear list of all that you need for it, on top of ChucK's dependencies. Yeah I don't know why it didn't work. But I haven't taken the time to figure it out. Probably something small. > I just wish it would have a more intelligent "replace" function for shreds > then always replacing the last one that was run. It's nice and simple, I > like that. There are hotkeys for running code though not enough for editing > it. emacs will solve all of those issues, I'm sure but that would go at the > expense of the simplicity? I'd love to program some emacs lisp, or some other mechanism, to track which shreds have been loaded. Something that would give super-quick keyboard access to remove or replace specific shreds. Perhaps Tab completion would be good for this. By the way, with all this talk about emacs, I should really specify, honestly, that I really only have a very short beard. And no, I don't wear sandles. ;-) cheers, Steve

3 3

paper trail
by Kassen 09 Sep '08

09 Sep '08

Fellow ChucKists, Does anybody know what my options are in printing (to paper, the old-fashioned way) from the Mini under (Ubuntu) Linux? Ideally I'd like to periodically or on command print edit buffers to paper as text as part of a performance. Is this possible at all? Yours, Kas.

4 5

Re: [chuck-users] Reconnecting Ugens (was; determining type)
by Tiemen Meerman 07 Sep '08

07 Sep '08

Kassen, (Long time no speak, btw!) > What if we'd wish-list two new member functions for UGen's, similar to the new "UGen.isConnectedTo( Ugen )"? I'm imagining "isConnectedTo()" and ".connectsTo()", both of which would return a array of type Ugen (that could obviously be of length 0). Fully agree! Introspection of this kind is a must in my opinion! The possibilities would be endless and I don't see why the scope should be limited - access to the entire graph from anywhere should be possible and makes for a much simpler implementation. I am uncertain whether the instanceof operator/function was ever implemented, but that would be equally essential. While wish-listing (and slightly related) a cool feature would be a way of tagging UGens with a arbitrary string. This would give us a way of providing a unique AND meaningful identifier to a UGen. Useful while traversing complicated graphs. > I am starting to think that this kind of wrapping, for what sounds like it could also be seen as a very general and atomic operation, is a bit much; to get the extra feature of reconfiguring the UGen graph we'd have to sacrifice the ChucK operator as it applies to UGen's. I like the ChucK operator, too, but wish it was overloadable by the user - this would allow us a hook to do a lot of things! (I will not even try to list them ;) Have been away from my computer for too long, and wish ChucK ran on BlackBerries! -T

2 1

Re: [chuck-users] Reconnecting Ugens (was; determining type)
by Kassen 07 Sep '08

07 Sep '08

Tiemen; > That sounds like the correct behaviour, as you only change the memory > address 'patchpoint' is pointing to. The actual graph will know nothing of > this event. > Ok. Learned another thing. I suppose I took the word "assignment" too literally. Thanks! > > This method adds yet another wrapper around the UGens, but might be worth > it for the flexibility it provides. > Yes, could be interesting and worthwhile for specific applications like perhaps a configurable multi FX. I am starting to think that this kind of wrapping, for what sounds like it could also be seen as a very general and atomic operation, is a bit much; to get the extra feature of reconfiguring the UGen graph we'd have to sacrifice the ChucK operator as it applies to UGen's. What if we'd wish-list two new member functions for UGen's, similar to the new "UGen.isConnectedTo( Ugen )"? I'm imagining "isConnectedTo()" and ".connectsTo()", both of which would return a array of type Ugen (that could obviously be of length 0). This would enable us to write something like; ========================================= fun void replace (UGen target, UGen replacement) { while(target.isConnectedTo().cap() ) { target.isConnectedTo()[0] => replacement; target.isConnectedTo()[0] =< target; } while (target.connectsTo().cap() { replacement => target.connectsTo()[0]; target =< target.connectsTo()[0]; } } ======================== To me this sounds more general then the new "UGen.isConnectedTo( Ugen )" function from the latest version which could be re-written in terms of my modest proposal while the reverse isn't true. Am I making sense here? It's not that I don't see the use of wrapping Ugens to gain some domain specific functionality and it's great that we can, but reconfiguring the UGen graph sounds to me like a very general type of functionality that may be desirable as a part of the language. There are, of course, namespace issues here. Using these and starting from the DAC we could map the complete (active) UGen Graph while this should be limited to the UGens that are reachable from the current namespace. I'm not sure how feasible this is right now; clearly all of the knowledge we need is there in the system but that need not mean it's easily reachable, seeing as how the UGen graph is relatively independent from the code. Apologies for jumping from topic to topic like that; little sleep meant a bit of a heightened associativity for me. :¬) Yours, Kas.

1 0

Re: [chuck-users] determining the type of an Object in code
by Tiemen Meerman 07 Sep '08

07 Sep '08

Hmmm, after testing I found that sadly the following will run (without errors) but won't "fly"; =============== SawOsc s => UGen patchpoint => dac; second => now; new LPF @=> patchpoint; second => now; ======================== It seems that asignment to a UGen doesn't affect the Ugen-graph? That sounds like the correct behaviour, as you only change the memory address 'patchpoint' is pointing to. The actual graph will know nothing of this event. I was thinking of a class that achieves what you are aiming for: UGenRepatch - usage would look like: UGenRepatch repatch; repatch.ugen(LPF lpf); repatch.addIn(SawOsc osc); repatch.addOut(dac); To setup the basic graph. After this you could repatch by saying: repatch.ugen(HPF hpf); Internally it would then unchuck the old LPF and place the HPF in the middle. Obviously you could also write functions to remove/replace Ins or Outs from the central UGen. This method adds yet another wrapper around the UGens, but might be worth it for the flexibility it provides. -Tiemen

1 0

Audicle updating and shredID tracking
by Kassen 05 Sep '08

05 Sep '08

Dear list, Because I quite like some of the new features (especially the array appending) and quite like the Mini I tried ripping out the "chuck" bit of the Mini source, putting in the new version and compiling (Ubuntu, latest long term support version, up to date, I could look up details if needed). As far as I could see this works perfectly (so far...), no need at all to be burdened by any knowledge of C. Still, my current series of experiments could benefit a great deal from linking editor windows to shred ID's so I tried the same with the Audicle and got some errors that made it quite clear I'd need to know C/C++ in some detail to deal with them. So, first of all; the adventurous might like to try their hand at this and have a updated Mini (the "about" dialogue even reports the correct ChucK version, nice). Secondly, should the Audicle take such abuse? I feel this would be quite nice but there might be hard questions? Would it be a idea to use something like colour coding of window-headers (or some similar graphical element) to link editor buffers to running shreds in the Mini? I think that would be very nice as a help in livecoding. Like most people I can keep track of about 7 or so things at a time and the link between editor buffers and shred ID's that was steablished 15 minutes ago tends to be one of the things that gets lost.... Yours, Kas.

1 0

Chuck Concurrency Best Practices
by mike clemow 02 Sep '08

02 Sep '08

Hi everyone, So, I've been struggling to find a method to leverage the concurrency model in Chuck and I keep running up against the same issue: my guts tell me to do things that I can't do because of fact that child processes are alive only as long as the parent and the fact that objects are only passed by reference. Let me unpack this for you. I'm building a granular synthesis class library for Chuck. Most everything is being cast as one of two types of objects: 1) Forkable - a process that takes parameters and can be run or sporked 2) Forker - an object that knows how run a process and will fork it out for you. In order to get over the fact that functions are not (yet) datatypes in Chuck which can be passed to other functions, I'm basically following the example that Kassen, Mike, et al. were discussing in this forum topic: http://electro-music.com/forum/viewtopic.php?highlight=functor&t=23546 My problems always seem to rise from the fact that every Forker (whose job it is to fork a process) also has to be aware of how long that process is going to take or else run the risk of dying before it's child has completed. This leads to infinite passing of responsibility for time and every Forker seems to also need to be a Forkable and have it's own Forker, et cetera ad inifinitum. At higher and higher levels of abstraction, finding the duration of a process BEFORE it runs and figuring out how to handle it, is requiring more and more analysis and feels... for lack of a better word, "wrong" to me. This is compounded by the fact that the objects I'm passing into these functions (methods of other objects) can only be passed by reference and it's increasingly difficult to set-and-forget these processes, since they constantly reference other global objects. The passing by reference is fine, but I find myself wishing I had the choice to make a copy. Now, it's entirely probable that I just haven't caught on yet and am going about this process in a completely backward way. Does anyone here run into similar issues and (even better) have good methods of avoiding them? One idea I have considered is to make a Forker a looping process that receives Events as input, rather than an object with methods. As this would require a(nother) complete re-write, I'm stalling. ;-) So, how do you manage your concurrent processes in Chuck? Cheers, Michael PS: Love dynamic Arrays! Can't wait for those SC/Smalltalk-like array methods! -- http://semiotech.org/wp-prod/ http://semiotech.org/michael

6 11

I: taps+chuck+osc
by Giacomo 28 Aug '08

28 Aug '08

Da: Giacomo [mailto:giacomo.serafini@poste.it] Inviato: giovedì 28 agosto 2008 17.58 A: chuck-users(a)lists.cs.princeton.edu Oggetto: taps+chuck+osc Hi, Im a computer sciences student at Udine (Italy) university. Im working on a thesis about tapestrea, in my opinion really a great tool. Recently Ive experimenting with chuck; Ive found great documentation on tapss and chucks official sites, but Im interested in a very specific subject: is there a way to synthetize a sound in taps (running on localhost) and reproduce this sound in another host (in the same wired network)? Ive already looked at chuck osc examples, they work great, but I would use a sound synthetized by tapestrea. Thanks for your help (and sorry for my English) Giacomo

1 0

Neural Nets in ChucK
by Inventor-66＠comcast.net 27 Aug '08

27 Aug '08

Hi, Did I read correctly that ChucK now has support for neural nets? I've been coding neural nets in the signal path and in the time loop, and my beloved ChucK is so slow that I can only do 30 neurons or so in real time. I would like to hear more about this new feature. I looked on the Unit Generators page and didn't see anything there. What's up? Les Hall (Inventor) http://www.freedomodds.com/music/ <--- my ChucK web page : )

3 2

newbie questions
by joachim heintz 25 Aug '08

25 Aug '08

Hi - I'm new in ChucK (up to now I used mainly Max and Csound). I like the language and would like to use it for my next piece, which will be for trombone and live-electronics. What I need is: 1. record the live input (6 microphones) in buffers and play the content back later (in parts); 2. live transposition via fft (like the gizmo object in Max); 3. working on partials (e.g. changing the amplitudes or selecting any). I think this is not very sophisticated, but after having a look in the documentation and the examples I don't know whether it can be done in ChucK, and how. So I'd appreciate a lot if anyone can tell me where I can find some examples. Thanks in advance! joachim

2 2

Filter.coefs (STRING )
by Kassen 23 Aug '08

23 Aug '08

Dear list, I'm helping a friend with a project and would like to use ChucK to analyse some signals. In particular I'd like to calculate the average of a audio signal over the last n samples (where n is something between say 500 and 1000). The best strategy I can come up with right now is to use Filter and give it a series of n coefficients that make it add the current input sample, the last...... the one n-1 samples ago, all at a amplitude of 1/n, and not use any feedback. This would make Filter do all the work which is good because typically Perry and Gary write C that's much, much faster then the ChucK I write. The bad news is that the docs make it clear that Filter takes a input of type string but it doesn't tell us how this string is formatted. I'm fine generating the string I need procedurally but I would need some more instructions then that it's a string and a rough idea of what's in it. I'd also like to suggest the doc's would be updated with this because as they are Filter isn't that practical to use. Yours, Kas.

1 0

read/write text from file
by Joel Matthys 21 Aug '08

21 Aug '08

Does ChucK a method of writing and reading ints, floats or strings from a file? The documentation only includes WvIn and WvOut for file I/O. I hacked a technique for sending data by scaling it to values -1.0 to 1.0 and sending it to a sound file: //WRITE1.ck// // write values to file Step x => WvOut file => blackhole; "data" => file.sndFilename; float n; for (int ii; ii<20; ii++) { ii/20.0 => n; <<< n >>>; n => x.next; 1::samp => now; } file.closeFile(); These values can then be read sequentially with WvIn: //READ1.ck// WvIn w => blackhole; "data.snd" => w.path; float n; repeat(20) { 1::samp => now; w.last() => n; <<< n >>>; } But I don't get exactly the same values returned; ie, I try to store the value 0.500000 but when read, I get 0.500015. That's a significant variance. Does anyone know where this variance comes from, or how to get around it? And is this the only way to store and read data? What about strings from files? Joel

3 2

chuck arguments
by N. Cameron Britt 16 Aug '08

16 Aug '08

Renato, If you know the sizes of your vectors you could simply pass the elements of your vectors as separate arguments and populate the various arrays in chuck. The following makes two arrays -- one with two elements, one with three: chuck test.ck:1:2:3:4:5 test.ck as follows: int vect1[2]; int vect2[3]; for( 0 => int i; i < me.args(); i++) { //fill vect1 if(i == 0) { for( 0 => int i; i < vect1.cap(); i++) { Std.atoi(me.arg(i)) => vect1[i]; } } //fill vect2 if(i == 2) { for( 0 => int i; i < vect2.cap(); i++) { Std.atoi(me.arg(i+2)) => vect2[i]; } } } for(0 => int i; i < vect1.cap(); i++) { <<<"vect1", vect1[i]>>>; } for(0 => int i; i < vect2.cap(); i++) { <<<"vect2", vect2[i]>>>; } test.ck outputs: vect1 1 vect1 2 vect2 3 vect2 4 vect2 5

2 1

chuck arguments
by Renato Fabbri 16 Aug '08

16 Aug '08

Hi Chuckists, chuck -s test:walk-sample:silence-rest:loop:ap-ppa-appp:3-1-2_1-2-3-4-5-7-6 test.ck is as follows: <<<me.args()>>>; for(0=>int i; i < me.args(); i++){ <<<i, me.arg(i)>>>; } and outputs: 5 :(int) 0 walk-sample 1 silence-rest 2 loop 3 01-001-1000 4 3-1-2_1-2-3-4-5-7-6 i undestand that ChucK has only atof and atoi to get values from incomming strings. and i but 01-001-1000 is/are three vectors: [0,1], [0,0,1] and [1,0,0,0]. and 3-1-2_1-2-3-4-5-7-6 is/are actually two vectors: [3,1,2] and [1,2,3,4,5,7,6]. the first arguments are stringed options passed to ChucK scripts, seems okay. i need these two separate ordered sets of vectors.. i am thinking of sending each value independently (test:.....:4:6:9......) separating each vector by, say, 999. and each set of vectors by 9999 any better idea?

1 0

Asio build (please?)
by Kassen 12 Aug '08

12 Aug '08

Fellow ChucKists, Would there perhaps be somebody who has some experience with building on Windows and who could spare the time to roll me and others like me a ASIO version of the latest& greatest? Perhaps somebody already has? I'd like to use the latest version but I'd also like the have decent latency on Windows, judging by the download stats on the forum (where the previous versions were hosted) there is a significant amount of interest in this; the last version (by Moudi) was downloaded 34 times, the version before that (by Philippe) 184 times, I'm not sure exactly how many ChucKists there are but I suspect those to be signifficant numbers. Eternal gratitude as well as a drink if/when/where we meet shall be yours. Cheers, Kas.

5 15