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

array of UGens
by Jascha Narveson 07 Oct '07

07 Oct '07

Quick question: How do i define an array of Unit Generators in Chuck? Something like this (obviously not a working example)... Object sines[8]; // create an array for 8 SinOscs for (0 => int i; i < sines.cap(); i++) // put a SinOsc in each slot { SinOsc => sines[i]; (i+1) * 110 => sines[i].freq; // harmonically related tones } thanks, jascha

2 1

tapestrea + chuck ... wow
by Scot Gresham-Lancaster 06 Oct '07

06 Oct '07

Okay, am I the only one who missed this thread earlier or something, but I stumbled on and spent the morning getting oriented to the taps<=>chuck universe and "Holy similarity based retrieval, Batman" This is extra super powerful stuff If you haven't, I recommend taking a ms, sec, minute, day, week ... checking it out http://taps.cs.princeton.edu/ more specifically http://taps.cs.princeton.edu/doc/ui/scripting/synthesis/ Scot Gresham-Lancaster http://o-art.org/Scot " Mechanical tension —> bioenergetic charge —> bioenergetic discharge —> mechanical relaxation " - Wilhelm Reich

2 1

Khagan, tablet via OSC
by Martin Ahnelöv 05 Oct '07

05 Oct '07

'Elo there! Recently found this really cool app that lets you send tablet-input data via OSC. Could this interrest any HID-enthusiasts on the list? http://khagan.berlios.de Gasten

1 0

.cap() for multi-dimensional arrays
by Kassen 03 Oct '07

03 Oct '07

Fellow ChucKists.... First; .cap() for multi-dimensional arrays isn't documented but works. If we have this; int foo[3][5]; then this; <<<foo.cap()>>>; will return "3". We can get the 5 by using this; <<<foo[0].cap()>>>; Other numbers then 0 are also supported as long as it smaller then foo.cap() (otherwise we get a array out of bound error) so 0 is safest. Next up; is this correct? The need for that "0" strikes me as rather in-elegant but omitting it results in a syntax error. Yours, Kas.

4 6

miniAudicle with chuck 1.2.1.0
by Atte André Jensen 03 Oct '07

03 Oct '07

Hi Should something special (except making the symlink "chuck" point to the new sources) be done to make miniAudicle with chuck 1.2.1.0? Make fails like this here: atte@ajstrup:~/software/chuck/mini_audicle/miniAudicle-0.1.3.7$ make linux-jack make -f makefile.jack ....... lm -lsndfile chuck/src/chuck_compile.o: In function `load_internal_modules(Chuck_Compiler*)':chuck_compile.cpp:(.text+0xc04): undefined reference to `xform_query' chuck_compile.cpp:(.text+0xc2f): undefined reference to `extract_query' collect2: ld returned 1 exit status make[1]: *** [wxw/miniAudicle] Error 1 make[1]: Leaving directory `/home/atte/software/chuck/mini_audicle/miniAudicle-0.1.3.7' make: [linux-jack] Error 2 (ignored) NB: I just tried and a fresh, unmodified extracted tarball of the mini compiles just fine. Same goes for a fresh, unmodified extracted tarball of chuck 1.2.1.0... -- peace, love & harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://modlys.dk

1 0

Linux exception at readline.ck
by Kassen 02 Oct '07

02 Oct '07

Small issue; If I hit CTRL+C while /examples/string/readline.ck is waiting for input I get; ------- FATAL: exception not rethrown Aborted ----------- On Linux, this doesn't happen on XP and doesn't happen when hitting CTRL+c at other moments (at least not that I've seen). Kas.

3 4

Envelope doing very weird things.
by Kassen 25 Sep '07

25 Sep '07

Kindly look at this for details http://electro-music.com/forum/viewtopic.php?p=141165 Dr.Spankenstein found some very odd behaviour in Envelope which Kijjaz and me investigated in some more depth. It seems like Envelope, when starting at some non-0 value misbehaves when ramping towards a target. It seems like it ramps relatively in the way that it would when starting at 0, unless it's ramping down in which case it seems to subtract the target from the current value and ramp towards the result of that. Could one of the dev's look into this? Yours, Kas.

1 0

Re: [chuck-users] Killing?
by Noah Thorp 24 Sep '07

24 Sep '07

Announcing the October meetup of the Bay Area Computer Music Group. Many thanks to Ge and Spencer for presenting at this. If you are in the Bay Area I am looking forward to seeing you there. All the best, Noah ------------------------------------------------------------------------------------ BAY AREA COMPUTER MUSIC TECHNOLOGY MEETUP: CHUCK, PYTHON VST, AND MORE Thursday, October 4, 2007, 6:00 PM Space Gallery, 1141 Polk St , San Francisco, CA Click here to RSVP: http://electronicmusic.meetup.com/152/ ------------------------------------------------------------------------------------ Come meet each other and participate in planned and impromptu presentations ("lightning talks"). Presentations will be Ge Wang and Spencer Salazar on ChucK, and Tim Thompson on his Python VST library. Bring your laptop if you would like to make a short impromptu presentation (projection screen and sound system available) or tell the group about new projects and opportunities. PLANNED PRESENTATIONS: * Ge Wang and Spencer Salazar presenting on the ChucK audio programming language: http://chuck.cs.princeton.edu/ . Ge and Spencer are both Alumni of the Princeton Sound Lab and Ge is joining the faculty at Stanford in the Center for Computer Research in Music and Acoustics (CCRMA). There is a lot of interest forming in the Computer Music community around ChucK and they have been at it's originating point. Ge is the chief architect and co-creator of the language and Spencer is the author of several key components, as well as the miniAudicle, an IDE for enjoyable ChucKing. Ge is also enthusiastic about starting a "West Coast Laptop orchestra". * Tim Thompson will be presenting on a library he has written that allows Python programmers to access the vast variety of VST plugins and synth instruments. He is a former longtime Bell Labs / AT&T / Network Appliance developer who has written a number of computer music frameworks (notably KeyKit). He has more recently been inspired by events such as Burning Man and Woodstockhausen, where his interactive creations include a 12-foot high lyre and an antique radio. Tim's home describes his projects and hosts his web-based algorithmic music toys: http://nosuch.com/tjt/index.html * Short "lightning talk" style presentations from users who have attended with their laptops. Contacting me in advance for this is not necessary unless you have specific concerns. The event will be held at Space Gallery, 1141 Polk St in San Francisco - http://www.spacegallerysf.com/ . There will be a projection screen and stereo sound system. It is an enjoyable space and will be open for people to socialize after the presentations. There will be light food to enjoy while you are talking. Many thanks to Ray at Space Gallery for hosting this meetup! At 9pm the venue will switch gears from Computer Music Technology Group tech talk. Further eclectic inspiration begins at 9pm as professional skateboarders do a short exhibition on a small portable half-pipe skate ramp inside the gallery while CB Records Mophone and friends perform mashup sets of live rock and funk re-mixes. Should be amazing! Polk street also offers a variety of restaurants for after meetup dining and conversing. Looking forward to meeting all of you, and please feel free to contact me about presenting for future events, hosting or sponsoring an event, etc. - noah [at] listenlabs.com. BIOS: Ge Wang received his B.S. in 2000 in Computer Science from Duke University and PhD in 2007 studying with Perry Cook in Computer Science at Princeton University, and is an assistant professor at Stanford University in the Center for Computer Research in Music and Acoustics (CCRMA). Ge conducts research in real-time software systems for computer music, programming languages, visualization, new performance ensembles (e.g., laptop orchestras) and paradigms (e.g., live coding), interfaces for human-computer interaction, pedagogical methodologies at the intersection of computer science and computer music. Ge is the chief architect of the ChucK audio programming language and the Audicle environment. 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. Tim Thompson enjoys the creative process of developing artistic software for both music and visuals, often involving the use of unusual controllers. Most widely known as the developer of the KeyKit programming environment for algorithmic and realtime MIDI experimentation, he has more recently been inspired by events such as Burning Man and Woodstockhausen, where his interactive creations include a 12-foot high lyre and an antique radio. He lives in Silicon Valley and collaborates with local ensembles dud ( http://dudland.com/) and DOUBLE VISION ( http://double-vision.biz/ ). Tim's home page ( http://nosuch.com/tjt/index.html ) documents the variety of his activities and allows people to play with web-based algorithmic music toys. Spencer Salazar is a software engineer and music technologist from San Francisco. A cohort of the Princeton Soundlab, he is the main developer of miniAudicle, an integrated development environment for the ChucK audio programming language. He has implemented several components of ChucK proper, and has composed for, performed in, and developed software for the Princeton Laptop orchestra. By day he works on human-computer interface technologies for a Bay Area product development group. ABOUT THE BAY AREA COMPUTER MUSIC TECHNOLOGY GROUP: Meet other computer music technology enthusiasts for presentations of computer music techniques and technologies (all music genre outputs are welcome). If you are a user of max/msp, csound, ChucK, CLM, Live, Reaktor, Kyma, JMSL, SuperCollider, or other computer music synthesis, composition, and live performance software this group is for you. Come to learn new techniques, better the code base, find collaborators, and find out what what's happening in studios, labs, and live work spaces around the Bay Area. You can join the Bay Area Computer Music Group and RSVP for the first event at http://electronicmusic.meetup.com/152/

1 0

Killing?
by Kassen 22 Sep '07

22 Sep '07

Hi, list. Can anyone confirm that since the last update chuck --kill send from a different terminal crashes the VM? I'm getting what sounds like a repeated buffer to me. This is using the latest ASIO version on Win XP. Kas.

2 2

scott may have found a spork bug
by Kassen 21 Sep '07

21 Sep '07

On 9/19/07, Scott Wheeler <wheeler(a)kde.org> wrote: > > > Extra Credit: One thing that I've noticed in a couple of places is that > sometimes sporking doesn't do what I would expect it to. For instance, > if I change line 223 to "spork ~ node.item.set(value);" to make it > non-blocking the program doesn't work. I don't see why. I'll share my thoughts on livecoding practice and so on too, later. I just wanted to say now that bug reports benefit from a bit more exposure then this paragraph got in your mail, hence this rather explicitly topic-changing reply. I don't see why that would affect matters either, this is in reference to the "set" command that also broadcasts a event, right? The one thing I could think of would be a name space issue. Normally sporked shreds have their parent's namespace but this wouldn't be the first time things went a little odd when inside of classes and you certainly have no shortage of those here. Also; if it's namespace that should yield a complaint. Strange. :¬) Cheers, Kas. // MIDI Event IDs > > int codes[0]; > > 144 => codes["NoteOn"]; > 128 => codes["NoteOff"]; > 176 => codes["ControlChange"]; > > class MidiMessage > { > int id; > > fun int[] data() > { > return [ 0, 0 ]; > } > } > > class NoteMessage extends MidiMessage > { > int pitch; > int velocity; > > fun int[] data() > { > return [ pitch, velocity ]; > } > } > > class NoteOnMessage extends NoteMessage > { > codes["NoteOn"] => id; > 100 => velocity; > } > > class NoteOffMessage extends NoteMessage > { > codes["NoteOff"] => id; > 0 => velocity; > } > > class ControlChangeMessage extends MidiMessage > { > codes["ControlChange"] => id; > 8 => int control; > 127 => int value; > > fun int [] data() > { > return [ control, value ]; > } > } > > class MidiHandler > { > // Members > > MidiIn input; > MidiOut output; > > 0 => int inputDevice; > 0 => int outputDevice; > > // Constructor > > if(!input.open(inputDevice)) > { > <<< "Could not open MIDI input device." >>>; > me.exit(); > } > > if(!output.open(outputDevice)) > { > <<< "Could not open MIDI output device." >>>; > me.exit(); > } > > fun void send(MidiMessage message) > { > message.data() @=> int data[]; > > if(data.cap() == 2) > { > MidiMsg out; > > message.id => out.data1; > data[0] => out.data2; > data[1] => out.data3; > > output.send(out); > } > else > { > <<< "Invalid data() for MidiMessage." >>>; > } > } > > fun void run() > { > // Now handle incoming events. > > MidiMsg message; > > while(true) > { > input => now; > > while(input.recv(message)) > { > message.data1 => int code; > > if(code == codes["NoteOn"]) > { > spork ~ noteOn(message.data2, message.data3); > } > else if(code == codes["NoteOff"]) > { > spork ~ noteOff(message.data2, message.data3); > } > else if(code == codes["ControlChange"]) > { > spork ~ controlChange(message.data2, message.data3); > } > else > { > <<< "Unhandled MIDI Message: ", message.data1, > message.data2, message.data3 >>>; > } > } > } > } > > fun void noteOn(int pitch, int velocity) > { > <<< "Note On: ", pitch, velocity >>>; > } > > fun void noteOff(int pitch, int velocity) > { > <<< "Note Off: ", pitch, velocity >>>; > } > > fun void controlChange(int control, int value) > { > <<< "Control Change: ", control, value >>>; > } > } > > class Control > { > -1 => int cc; > > ControlDispatcher.register(this); > > fun void set(int value) > { > <<< "Control Changed: ", cc, ", ", value >>>; > } > } > > class ControlEvent extends Event > { > int control; > int value; > } > > class EventControl extends Control > { > ControlEvent changed; > > fun void set(int value) > { > cc => changed.control; > value => changed.value; > changed.broadcast(); > } > } > > class ControlNode > { > ControlNode @ next; > Control @ item; > } > > class ControlList > { > static ControlNode @ first; > static ControlNode @ last; > > fun void append(Control control) > { > if(first == null) > { > new ControlNode @=> first; > first @=> last; > control @=> first.item; > } > else > { > new ControlNode @=> last.next; > last.next @=> last; > control @=> last.item; > } > } > } > > class ControlDispatcher extends MidiHandler > { > static ControlList @ controls; > > fun void controlChange(int control, int value) > { > if(controls == null) > { > return; > } > > controls.first @=> ControlNode @ node; > > while(node != null) > { > if(node.item.cc == control) > { > node.item.set(value); > } > node.next @=> node; > } > } > > fun static void register(Control control) > { > if(controls == null) > { > new ControlList @=> controls; > } > > controls.append(control); > } > } > > ControlDispatcher controller; > > // Two demos here: one with subclassing, one with events: > > class FooControl extends Control > { > 1 => cc; > > fun void set(int value) > { > <<< "Foo: ", value >>>; > } > } > > FooControl foo; > > // And now with events. > > EventControl bar; > 2 => bar.cc; > > fun void listener() > { > while(true) > { > bar.changed => now; > <<< "Bar: ", bar.changed.value >>>; > } > } > > spork ~ listener(); > > // And now let's create some fake hardware controls to test things. > > fun void fakeKnob() > { > ControlChangeMessage message; > > 1 => message.control; > > for(0 => int i; i < 10; i++) > { > i => message.value; > controller.send(message); > 10::ms => now; > } > } > > fun void fakeButton() > { > ControlChangeMessage message; > > 2 => message.control; > 127 => message.value; > > controller.send(message); > } > > spork ~ fakeKnob(); > spork ~ fakeButton(); > > controller.run(); > > _______________________________________________ > chuck-users mailing list > chuck-users(a)lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users > >

3 4