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

Mac OS X on-the-fly issue
by David Posey 26 Jan '08

26 Jan '08

I'm unable to get the on-the-fly features of ChucK working. I can do one thing at a time from the command line, i.e. %> chuck foo.ck or %> chuck --loop But I cannot do, say, "--loop" followed by "--add bar.ck" to add a shred. The problem is that once I do "--loop" no prompt reappears for me to type in "--add bar.ck", unless I ctrl-C out of it first, which kills the first process anyways. What's the catch? How do I run a second shred from the command line? (I'm running Chuck 1.2.1.1 on Mac OS X 10.4 using the command-line interface.) Any help would be greatly appreciated. --David

4 3

Looped sample playback rate
by Ollie Glass 25 Jan '08

25 Jan '08

Hello ChucKers, I'm using SndBuf to loop samples. I read a sample and call .loop(1) to do this, but if I call .freq(x) nothing plays, where 0.25 < x < 4. Is this an issue with SndBuf or am I missing something? Thanks, Ollie

2 1

giving birth made easy (and head-hitting)
by Kassen 24 Jan '08

24 Jan '08

Dear list, It turns out that for a VM that has been running for a arbitrarily long time it's still easy to find the time of it's birth. considder the following; ================= time birth; now - (now /samp)::samp => time start; if (start == birth) <<<"Yay">>>; ============================= *hits head* So, it's possible after all to define objects of type time wthout using time after all; adding durations to a "fresh" time object will in fact do. Next up; a poor man's casting; ============================= //demo <<<dtot(second)>>>; <<<ttod(now)>>>; //the meat //time to duration and dur to time by Kassen. //considered trivial once I thought of it //no rights reserved fun time dtot (dur input) { //duration to time //probably leaks memory time garbage; input +=> garbage; return garbage; } fun dur ttod (time input) { //time to duration //here we go again with the strong typing return ( input/samp )::samp; } ==================================== *hits head again* Cheers, Kas.

2 2

Help!
by mike clemow 21 Jan '08

21 Jan '08

I'm suddenly, for no apparent reason, getting this error: [Untitled]:line(1): ugen's of type 'DAC' have no input - cannot => from another ugen my patch is: SinOsc s => dac; 2::second => now; Any hints here? This is... just... wrong. -Mike -- http://semiotech.org http://blog.deadlylittlepills.com http://www.murderkills.com http://shadowofaculture.blogspot.com

4 12

winxp problems?
by miya6611 20 Jan '08

20 Jan '08

hello. I downloaded "chuck-1.2.1.1". But --version is as follows. Chuck version: 1.2.0.8 (Dracula) Exe target: Microsoft win32 http: //chuck.cs.princeton.edu/ example/analysis does not operate :( and... chuck --bufsize950 [chuck]: no input files... (try --help) -- miya6611 http://mindblast.jp/

2 3

Chuck used in NYC tonight
by mike clemow 19 Jan '08

19 Jan '08

Hey there, fellow Chuckists! Just wanted to let you guys know that Chuck is getting some public exercise tonight at the Heart and Soul Gallery in Brooklyn, NY from 6-10pm EST. My band, Murder, is collaborating with another band, Stars Like Fleas, to create an interactive sound sculpture from found-objects that uses Chuck as part of its technology stack. Sensors -> Microcontroller -> Python -> OSC (via simpleOSC) -> Chuck It's nothing terribly complicated on the Chuck side, since we're using it to listen for OSC messages and play back sound samples from the bands in interesting configurations, but I thought it deserved mention, so at the very least, since you folks helped me learn Chuck ;-), honor is due. Plus, if anyone is in the area and totally bored, you should stop by. Here are the details, links: http://www.heartandsoulpilates.com/showing.html http://www.murderkills.com http://slf.praemedia.com/ (I hope it works!) Cheers, Mike Clemow -- http://semiotech.org http://blog.deadlylittlepills.com http://www.murderkills.com http://shadowofaculture.blogspot.com

2 2

LiSa zero-crossing snap how-to
by Kassen 14 Jan '08

14 Jan '08

Dear ChucKists. (particularly Dan who asked me for examples of LiSa usage a while back) Below you'll find a example of how to make LiSa's loop points snap to the next positive zero crossing in her buffer, provided the buffer was loaded from a recorded file using SndBuf. This has many uses, particularly to glitch-free loop a sample that's not noisy enough to hide clicks and/or particularly bass heavy in situations where the overall structure of the program loops at a different rate then the sample loop length and crossfading would mean adding shreds..This is a polite way of saying it's especially good for cheap & easy stuttering kick-drums. Mind that this will change the loop's length and thus pitch and/or timing, it's much cleaner sound-wise though. In some situations this may be cleaner or lead to cleaner code than the methods in the examples/docs but it would be a bad idea to think this is the best way to avoid clicks in all cases as it isn't. It's a interesting option though and one I found to work well compared to it's complexity. With lots of comments, I hope others will find this as usefull as I'm finding it now. Yours, Kas. ================================================== //Zero crossing detection and snapping for LiSa by Kassen //Permision granted for redistribution, modification, etc. //no waranties, no refunds, please mind your speakers. //Remixing strongly encouraged. SndBuf buf => LiSa l => dac; //your sample goes here //this patch is primarily meant for low drum beats or notes //clicks aren't as objectionable for claps and the like //may be impractical for lengthy soundscapes..... buf.read("kick.wav"); int n, m; float last; int crossings; 2::second => l.duration; //detect the number of positive zero crossings in the file //we do this faster than realtime //if you try this for long samples while other stuff is running //there may be glitches as this likely maxes out the cpu //due to not advancing time for (0=> n; n<buf.samples(); n++) { if ((last < 0) && ( buf.valueAt(n) >= 0)) { crossings++; } buf.valueAt(n) => last; } <<<crossings, "positive zero crossings in sample">>>; //make a array of this length int zerocrossings[crossings]; //create a index of their locations 0 => crossings; 0 => last; for (0=> n; n<buf.samples(); n++) { if ((last < 0) && ( buf.valueAt(n) >= 0)) { n => zerocrossings[crossings]; crossings++; } buf.valueAt(n) => last; } //go LiSa! l.record(1); buf.samples()::samp => now; l.record(0); //save cpu buf =< l; //loop forever to demo //here we only snap loopEnd() to the crossings, //loopStart() may be treated in the same way, //at which point only using positive crossings becomes usefull. while(1) { //start at the beginning 0::ms => l.playPos; l.play(1); //modulate loop length for (1 => m; m < 8; m++) { m* (2::second /16) => l.loopEnd; //don't bother trying to detect crossings if we already passed the last one if ( (l.loopEnd()/samp)$ int < zerocrossings[zerocrossings.cap()-1]) { //find the next positive zero crossing... 0 => n; while( (((l.loopEnd()/samp) $ int ) > zerocrossings[n]) &&n< zerocrossings.cap()-1 ) n++; //snap to it zerocrossings[n +1]::samp => l.loopEnd; } second => now; } //get rid of clicks at the end, pause and start over l.rampDown(50::ms); second => now; }

1 0

A couple of questions
by Johan Nilsson 14 Jan '08

14 Jan '08

Hi, I started using ChucK some weeks ago and must say it looks promising. It seems to be the language I have been waiting for: simple enough to be usable for musical application yet low level enough to provide enough control. I have stumbled across some questions though. 1) Here is an example of a simple synthesizer with two envelopes, one for gain and one for frequency. For the first one it is rather straight forward how to connect it using the chuck operator, but as for the frequency envelope: is there some better way to implement it? I get the feeling I make things a bit complicated and inefficient this way. It would feel more natural to me to chuck it to a frequency input of osc. public class Synth{ SawOsc osc => ADSR ampEnv => dac; ADSR freqEnv => blackhole; spork~frequencyEnvelope(); float freq; fun void keyOn(float f) { f => freq; ampEnv.keyOn(); freqEnv.keyOn(); } fun void keyOff() { ampEnv.keyOff(); freqEnv.keyOff(); } fun void frequencyEnvelope() { while(10::ms => now) { freqEnv.value() * 1000 + freq => osc.freq; } }} 2) Suppose I want to rout the synth from the above example through a delay, this would feel like a natural way to do that: Synth synth => Delay delay => dac; Is it possible to define your own chuck operator for some class? To get around this I have added a Gain out to the synth which can be routed like this: synth.out => delay => dac; It works, but it is not too beautiful 3) I got the idea I wanted to kill a shread someting like this: spork~theShred() => @ Shred handle; // this is exactly like the "sporking shreds" chapter in the lang spechandle.kill(); //this is pure imagination 3a) My first concern is that the first line doesn’t compile. The compiler gives “cannot resolve operator ‘=>’ on types ‘Shred’ and ‘Shred’… Am I supposed to use the @=> operator in this situation?3b) Is it possible to kill a shred by reference? Thanks for a wonderful musical programming language, Johan Nilsson _________________________________________________________________ Trött på krångliga mejladresser? Skaffa en live.se-adress här! http://get.live.com/mail/options

2 1

Re: [chuck-users] A couple of questions
by pibsid＠suomi24.fi 14 Jan '08

14 Jan '08

Johan Nilsson wrote: >>1) Here is an example of a simple synthesizer with two envelopes, one for gain and one for frequency. For the first one it is rather straight forward how to connect it using the chuck operator, but as for the frequency envelope: is there some better way to implement it? I get the feeling I make things a bit complicated and inefficient this way. It would feel more natural to me to chuck it to a frequency input of osc. I'll leave the rest of your questions to more experienced chuckers. But as for question 1: You can chuck an input to an oscillator with a sync mode 2 and it does the same as your control loop: Modified version of your code follows: class Synth { SawOsc osc => ADSR ampEnv => dac; 2 => osc.sync; //Modulate frequency according to input; Step oneThousand => ADSR freqEnv => osc; 1000.0 => oneThousand.next; //Needed so that freqEnv outputs non-zero samples. 500::ms => freqEnv.attackTime; 500::ms => freqEnv.decayTime; 0.5 => freqEnv.sustainLevel; 1000::ms => freqEnv.releaseTime => ampEnv.releaseTime; float freq; fun void keyOn(float f) { f => freq => osc.freq; ampEnv.keyOn(); freqEnv.keyOn(); } fun void keyOff() { ampEnv.keyOff(); freqEnv.keyOff(); } /*fun void frequencyEnvelope() { while(10::ms => now) { freqEnv.value() * 1000 + freq => osc.freq; } }*/ } //Try it out: Synth s; 220 => s.keyOn; 1.5::second => now; s.keyOff(); 2::second => now; //Cheers //-Pyry

1 0

Re: [chuck-users] cast dur to time?
by pibsid＠suomi24.fi 10 Jan '08

10 Jan '08

Mike wrote: >>Still, this would be sugar. >>I really like the argument that if (time / duration = float) is legal, then (time / float = duration) should also be legal, however, it also follows that (time = duration * float), which I don't like. (2::second * 4) ought to return 8::second. So, I think that we're dealing with concepts here that don't fit squarely into the model of mathematics. After all, we don't multiply strings and floats, do we? >>I'm all for a more rigorous understanding of these types, though. This is all very confusing. >>-Mike What I think we're dealing with here mathematically is affine spaces. In an affine space you have points and vectors that connect them. The difference between a regular vector space is that there is no "true" origo but everything is relative. Also the operations on points differ from operations with vectors. Here the big letters denote points in an affine space and small letters denote vectors: -For each two points A and B we have an unambigious vector ab that connects them. -For each three points A, B and C: ac = ab + bc Operations: A - B = x A + x = B But: A + B = (undefined), (How do you add points together? Makes no sense) And thus A*(scalar) = (undefined), (In a vector space all this would be legal) Compare to time: time - time = dur; time + dur = time; time + time = (undefined) time*float = (undefined) The point (no pun intended) with affine spaces is that you can only make new points if you already have at least one to begin with. You can't just throw in a point if you don't define how it relates to the points already present. For the syntax issues I see no harm in adding me.bith = the time since the VM's start that the shred was sporked. To me it's just not a big deal to type: now => time birth; At the beginning of a sporkable funtion. But hey. We all find different things intuitive or counter-intuitive. Cheers -Pyry

6 10