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

granular music recommendations?
by AlgoMantra 23 Jul '24

23 Jul '24

Yo All....I'm trying to download and study some of the best music out there which features granular synthesis. I haven't heard much yet beyond Iannis Xenakis, but I'd love to know what your favorites are. Perhaps it would be worthwhile putting up a torrent of the same. If possible, kindly provide links to mp3 files or any other type of free downloads. (What do you think of Jaron Lanier's music?) http://www.jaronlanier.com/musicdownload.html cheers! ------- -.- 1/f ))) --. ------- ... http://www.algomantra.com

12 28

Granul8: UPDATED
by Wolfgang Gil 25 Oct '11

25 Oct '11

Hello everyone, I invested a few minutes today updating the granul8, a simple granular synthesizer i made using the chuck language. I fixed some time-based issues... I usually use in granul8 along with an 8 inputs mixing console and a Motu 828 audio interface. With this setup you will have 8 discrete voices that then you can spatialize and filter independently Enjoy! http://dl.dropbox.com/u/17247286/Granul8.zip -- http://www.wolfganggil.com <http://www.wolfganggil.com/about>

1 0

Syntax Highlight on Windows?
by John Gamboa 22 Oct '11

22 Oct '11

Hello everyone... I've decided to use Chuck lately on a university project and I was wondering if there is any editor that support syntax highlight for Chuck on Windows. I have searched for it in internet but didn't find anything useful D= (sorry if this has an obvious answer and I couldn't figure it out immediately) -- John Gamboa rabanetescebolas.blogspot.com

3 3

Clipping with LiSa
by Timothy Leonido 21 Oct '11

21 Oct '11

Hey All, I'm trying to write a patch that will regularly take new samples from its input. I'm routing itunes to chuck (via soundflower) and manipulating the samples with LiSa. The patch is creating a lot of strange clipping noises— like the sounds of bad guitar cables, which is confusing since this is all internal. Here is my patch, if anyone has any ideas: adc => LiSa loopme => NRev r=> Envelope e=> dac; .05=>r.mix; 10::second => loopme.duration; 10::ms => loopme.recRamp;  1::second => loopme.loopEndRec; .25 => loopme.rate; 1::second => loopme.loopEnd; 1 => loopme.loop; 1 => loopme.bi; 1 => loopme.play; 250::ms => dur t => e.duration; while(true) { e.keyOn(); 1 => loopme.record; 600::ms => now; 400::ms => loopme.recRamp; 400::ms => now; e.keyOff(); 0 => loopme.record; } Sometimes the crackling builds up and gets really abrasive, which some people seem to like. I'd prefer to get rid of it. Thanks! Tim

1 0

granular synthesis in chuck
by konstantinos vasilakos 20 Oct '11

20 Oct '11

Hello Guys, I new to the list and to Chuck as well, I am starting to use this language and see what happens, in creative level, therefore as I am working nowadays to a project using granular synthesis and the wii as a controller I would like to know with which objects or whatever you call that, should I mess around, thank you in advance. Konstantinos Vasilakos

6 16

DelayC (a delay class with cubic interpolation)
by Casper Schipper 19 Oct '11

19 Oct '11

Hi everybody, because I noticed that the DelayA ugen is not interpolating very smoothly (I find its quality to be much worse than DelayL actually, for modulated delay times), I made a DelayC class that uses cubic interpolation (with some critical bug fixing help by Kassen !). It is not very efficient by any standard, but the quality of interpolation is really good, much better than DelayL. My aim is to turn it into a real uGen, if anybody can help with that, would be great ! Best, Casper // Schipper, okt. 2011 class DelayC { Step n; // Output generator UGen @ input; // nullpointer for input ugen 1024 => int delaySize; // delaySize float data[delaySize]; // memory for delayline int wPos; // writing position in the delayline float delay; // delaytime in samples (float) float L1,L0,H0,H1; // the values used to make the spline interpolation. float frac; int index; // position in the buffer UGen @ delaytime; spork ~delayShred(); fun void delayShred() { while(1) { input.last() => data[wPos]; // writing samples clipf(delaytime.last(),2,delaySize-2) => delay; // clipped delaytime (minimum is 2 samples,maximum is delaySize-2) interp(wPos-delay) => n.next; (wPos + 1) % delaySize => wPos; // moving writehead to next sample samp => now; } } // function to make buffer circular fun int wrap(int x) { if (x < 0) return x + delaySize; return x % delaySize; } // three function to connect the delay to other ugens fun void connectInput(UGen ugen) { ugen @=> input; } fun void connectDelayTime(UGen ugen) { ugen @=> delaytime; } fun void connectOutput(UGen ugen) { n => ugen; } // sets the maxsize of the delayline fun void setsize(dur size) { (size / samp) $ int => delaySize => data.size; } // simple clipping function fun float clipf(float x,float min,float max) { if (x < min) return min; else if (x > max) return max; return x; } // 3rd order spline interpolation based on code from http://www.musicdsp.org/showArchiveComment.php?ArchiveID=62 fun float interp(float x) { Math.floor(x) $ int => index; // finding position in buffer x - index => frac; // calc remainder // reading 4 adjecent samples data[wrap(index-2)] => L1; data[wrap(index-1)] => L0; data[wrap(index)] => H0; data[wrap(index+1)] => H1; // interp formula return L0 + .5* frac*(H0-L1+ frac*(H0 + L0*(-2) + L1 + frac*((H0 - L0)*9 + (L1 - H1)*3 + frac*((L0 - H0)*15 + (H1 - L1)*5 + frac*((H0 - L0)*6 + (L1 - H1)*2 ))))); } } //test code DelayC delay; delay.setsize(44100::samp); SinOsc lfo => Gain mod => blackhole; lfo.gain(20000); lfo.freq(.29); Step offset => mod; 22050 => offset.next; Noise testnoise => BPF f => blackhole; 440 => f.freq;1 => f.Q; delay.connectInput(f); delay.connectOutput(dac); delay.connectDelayTime(mod); hour => now;

1 0

extending UGens thoughts
by Kassen 16 Oct '11

16 Oct '11

Fellow ChucKists, A few days ago I was talking with my friend Casper Schipper about the exciting new thing that extending UGens now works. Here are some modest proposals for extending that; * Reserve a ".tick()" function name for automatically overwriting the base class's tick function. Rationale; while we can (as I demonstrated with a quick example on this list) spork a shred that will make a UGen like Step or Impulse output a signal that shred will not be at the right place in the overall execution order as shreds (by definition) can't run while the Ugen-graph updates. Another down-side to that strategy is that unchucking the UGen in that case won't freeze its behaviour nor save CPU. This is inconvenient, it can harm sound quality and generally makes our own work a sort of "second rate citizen". With custom UGens that behave like build-in ones libraries shared by the community wouldn't need much of a extra manual which will make code more consistent and sharing possibly more popular. This special function would be called instead of the normal tick and would -clearly- need to be of type float or a compilation error would be thrown. Overwriting .tick() would be entirely optional, for a class foo that extends LiSa we may just wish to set some behaviour in some default way that we happen to use a lot today and have LiSa herself deal with the processing. * Reserve a "pull" float for pulling any UGens after our Ugen in the graph. Rationale; to preserve correct execution order and to have maximum flexibility in our own creations we'd like our custom UGens to have inputs. Currently this would be very hard to accomplish, even when we disregard UGen-graph execution order. "pull" would be a float that would be computed from our UGen's inputs (depending on our .op), if it's used in the tick function, and replace all uses of that variable in this call of the function. By that I mean we don't tick all of the UGens behind us multiple times just because we need the value a few times. For that reason I think it's more clear to abstract this away as a float, instead of having it be a explicit function. "pull" in the context of a function named "tick" wouldn't need to be declared, I imagine. That's elegant (I think), it's also a exception to what we have so far in that it would be a highly context dependant special variable but UGens are a unusual type in general and even with regard to timing, our big focus, behave quite unusually. So, let's have a example of what this would look like. Let's say I'd like to have a new UGen that would add a small bit of noise to a signal (example intentionally kept simple). I'll write that UGen and use it on a arbitrary input; class AddNoise extends UGen { float amnt; //some internal state fun float tick() //tick function { return (pull * (1 - amnt) + Std.rand2f(-1 * amnt, amnt); //here we pull, if we don't have a input we'll just get some noise but if we wish we could detect that condition and deal with it, } fun float amount(float in) //way of setting the behaviour { if (in > 1) 1 => in; else if (in < 0) 0 => in; in => amnt; return in; } fun float amount() {return amnt;} //overloaded get function as those are standard. } //let's go! adc => AddNoise an => dac; .1 => an.amount; minute => now; <<<"bye!">>>; This, to me, looks simple, expressive and realistic. Particularly I can't see any big things here that would backfire if at some point we'd like to be able to pre-compile external UGens into some sort of module format. This should also -as far as I can see- play nicely with the existing UGen graph functionality, for example the detection of feedback loops. Note that Casper and me were brainstorming about our wishes, any glaring errors in this post are mine. Also note that this proposal could make .tick() a thing you could explicitly call manually, possibly for all UGens. I don't see a big problem with that, it might even be useful and/or fun. Yours, Kas.

1 0

live-coding resources
by Renato Fabbri 12 Oct '11

12 Oct '11

Dear ChucKists, ChucKers and alike, We are going to do some live-coding performances in November here in Brazil, at São Carlos, and we wish to use ChucK as much as possible! It would be great to hear from you all about your live-coding experiences with ChucK: how you did it, which codes did you use, what was the outcome, what would you do different etc.. I know this has been a topic that once in a while is back, and I see this as a positive thing: ChucK is oriented towards live-coding AFAIK. We will be glad to cite this list and individuals by name (and perhaps more info :-) and about any contribution. Thanks and cheers! Fabbri -- GNU/Linux User #479299 labmacambira.sf.net

2 1

Scale & diatonic
by Hans Aberg 12 Oct '11

12 Oct '11

I have made a program, scale.ck, that admits one to work with scales, including tuning stretch, céleste tremulant, retune them, and then save to a file, with a line of code that can be pasted back into the source, available at next program startup. Scale tunings can be put into tuning banks, and otherwise defined by your favorite method. Details in the file. I have also updated my program for diatonic tuning systems, diatonic.ck. Just a few changes: adding some common tunings, fixing typos. The files are available here: http://www.math.su.se/~haberg/tuning_systems/ Hans

4 6

one-liners
by Kassen 12 Oct '11

12 Oct '11

Fellow ChucKists, This ; http://countercomplex.blogspot.com/2011/10/algorithmic-symphonies-from-one-… ...will likely be of interest to people playing the "most interesting sounds in a single line of code" game. It's also quite inspiring as a source of ideas for very free-form synthesis of lo-fi sounds. Yours, Kas.

5 7