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

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

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

09 Jan '08

As for casting durations or floats to time one should always ask how the newly made time relates to the one(s) we already have? Most logical would be that: minute $ time => time sometime; refered to "one minute after the VM started". But it could also refer to "one minute after this shred started". I find it more clear syntatically if we had predifined global and local time variables of VMstart and me.start (or me.birth). Then it would be clear from the syntax what is meant. VMstart + minute => time sometime; //As opposed to: me.start + minute => time anothertime; >>Kassen wrote: >>As for actual use, I could imagine that referring to absolute moments in time could become useful when writing a score, especially with some sort of sorting, Csound style. Maybe there are other better uses, maybe it's all quite academic? I'm already enthusiastic there are people that have a position on this too. That's what I thought when I first read about time in the ChucK manual. And I did make some tests with absolute time (relative to shred start time) ie. Calling: now => time start; //1st line And then making an array with [time,note,velocity,note_duration] float vectors to drive a score-player that would play the notes and chuck the time of the next note to now: spork~instrument(pitch,velocity,duration); start + time_of_the_next_note::second => now; But then I realized that this was a very unflexible way of doing things. If I wanted to add a new melody in between the old notes I would have to modify all of the times after it. Also tempo changes would be virtually impossible. So instead I went with an array of [time_separation,note,velocity,note_duration] vectors. Now the score-player would go: spork~instrument(pitch,velocity,duration); time_separation::second => now; //I recommend using a global duration of a quarter note here instead of an absolute duration of a second ...and it already felt more chuckish. :) Now adding new notes to the score needed no modification on the ones already present. I'm still thinking for the most effective way of changing the tempo on the fly... Thine, -Pyry

2 1

Re: [chuck-users] WORKSHOP: Introduction to the ChucK Music Programming Language, January 13th
by Noah Thorp 07 Jan '08

07 Jan '08

Yes, it is free. > Sender Allowed > > Is this free? > > -----Original Message----- > From: chuck-users-bounces(a)lists.cs.princeton.edu > [mailto:chuck-users-bounces@lists.cs.princeton.edu] On Behalf Of Noah > Thorp > Sent: Sunday, January 06, 2008 11:22 AM > To: chuck-users(a)lists.cs.princeton.edu > Subject: [chuck-users] WORKSHOP: Introduction to the ChucK Music > Programming > Language, January 13th > > WORKSHOP: Introduction to the ChucK Music Programming Language, January > 13th > > RSVP: Please RSVP for this event through the Bay Area Computer Music > Technology Group at > http://electronicmusic.meetup.com/152/calendar/6710874/ > > PRESENTED BY: Ge Wang (http://ccrma.stanford.edu/~ge/) > > TIME: > Sunday January 13th, 2008 > 1:00-1:30pm: ChucK presentation (30min) > 1:30pm-4:00: ChucK workshop > > LOCATION: > CCRMA, Stanford University > 660 Lomita Drive, Stanford, CA 94305 > More information: http://ccrma.stanford.edu/~ge/knoll/ > > INTENDED AUDIENCES: composers, sound designers/researchers, laptop > performers, programming language enthusiasts, and anyone else interested > in programming computer music. participants are encouraged, but NOT > required, to bring laptops (if you do bring one, OS X, Linux, Windows are > all supported). No prior experience with ChucK expected. > > DESCRIPTION: ChucK is a continually evolving computer music language being > jointly developed at Princeton University and now Stanford University > (with Ge's joining CCRMA). It combines familiar programming language > constructs with a new time-based concurrent programming model and the > ability to write code on-the-fly. This workshop is a crash course in the > philosophy and use of ChucK. The audience will hopefully leave with basic > ChucK programming skills, awareness of possible uses, as well as examples > and documentation provided in the workshop. > > ChucK is freely available, cross-platform, and open-source. > > http://chuck.cs.princeton.edu/ > > --- > WORKSHOP SCHEDULE: > > Presentation: What is ChucK? > * uses of ChucK (real-time synthesis/analysis, composition/performance, > experimentation/education, laptop orchestras) > * "strongly-timed": precise control over time > * what is concurrent programming and using it for music > * on-the-fly programming (write/edit code at runtime) > > workshop: part 1 (language basics) > * syntax and semantics > - overview > - types, values, variables > - operators > - control structures > * real-time sound synthesis > * unit generators > * manipulating time to make timbres and music > * functions, arrays (modularizing and organizing) > * concurrency, processes, shreds, events (powerful music programming) > * basic on-the-fly programming with ChucK > > workshop: part 2 (extended examples) > * extended examples > - mapping controllers via MIDI and OpenSoundControl (OSC) > - creating instruments using laptop capabilities > (keyboard, trackpad, sudden motion sensor, mic) > - network synchronization > - gui control with the audicle/miniAudicle > > > --- > BIO > > Ge Wang (http://ccrma.stanford.edu/~ge/) received his B.S. in Computer > Science in 2000 from Duke University, PhD (soon) in Computer Science > (advisor Perry Cook) in 2007 from Princeton University, and is currently > an assistant professor at Stanford University in the Center for Computer > Research in Music and Acoustics (CCRMA). His research interests include > interactive software systems for computer music, programming languages, > sound synthesis and analysis, music information retrieval, new performance > ensembles (e.g., laptop orchestras) and paradigms (e.g., live coding), > visualization, interfaces for human-computer interaction, interactive > audio over networks, and methodologies for education at the intersection > of computer science and music. > > Ge is the chief architect and creator of the ChucK audio programming > language. He is a founding developer and co-director of the Princeton > Laptop Orchestra (PLOrk), and a co-creator of the TAPESTREA sound design > environment. Ge composes and performs via various electro-acoustic and > computer-mediated means. At CCRMA, Ge continues to research and develop > ideas and systems for computer music (including ChucK), works on new > music, and plans to initiate a Stanford Laptop Orchestra. > > _______________________________________________ > chuck-users mailing list > chuck-users(a)lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users > > _______________________________________________ > chuck-users mailing list > chuck-users(a)lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >

1 0

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

07 Jan '08

I personally like the way time and duration are done right now, that you cannot make an explicit time-type variables. Those kind of things would only be limiting because they always had to refer to VM-time. If they instead refered to some kind of shred birth time then "chucking time to now" would lose meaning and unambiguity. And we can already define a birth time and times relative to that with the current state of affairs. //First line now => time birth_time; birth_time + 4::day => time four_days_from_birth; birth_time + minute => now; //Wait until the shred is one minute old >>; //Stuff four_days_from_birth => now; //Assuming it hasn't been four days yet. If it has then this chuck throws an exception. That should be enough. Requesting time casting sounds to me of requesting different kinds of time like VM time, shred time, real time, tea time and what not... :) There should only be one time. VM time. I think of it like a kind of a big bang time... everything else is relative. (Did someone say Einstein?) -Pyry, (Frostburn)

3 2

cast dur to time?
by Kassen 07 Jan '08

07 Jan '08

Dear list (and language designers in particular), this is legal; now + 2::second => time later; so, we know that time and duration are quite similar things (we already knew that ourselves but now we know ChucK agrees). However, this isn't legal; 2::second $ time => time later; I tried this, intending "later" to refer to the moment 2 seconds after the VM sprang to life. Are there good reasons not to allow the casting from time to dur and dur to time? Yours, Kas.

4 7