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

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

Some recent thoughts
by Kassen 20 Sep '07

20 Sep '07

Fellow ChucKsters, I was thinking while lying awake last night.... One of the big questions at the moment is writing non-wave data to disc and recalling it. This would be useful for storing the outcome of (random) algorithms, settings tuned by the use of interfaces and any number of other useful and appealing things. I'm certain we'll have this in the future, but what about right now? One idea I had that I have yet to try in practice is that we could try abusing the call for the OS to execute a terminal command. One of the very old-fashioned commands all three OS's that ChucK runs on is writing a line to a new file or appending a line to a existing file so with some abuse of the new function to form strings we could writem then save a file. If that file would contain a array and a simple command to assign that to a static array in a public class simply executing the file we wrote would give us back the data, asuming we defined some format for this. This is roundabout and not that beautiful but it could help someone out so I thought I'd share. One thing this would lead to is a .ck file that would work on either Windows or OSX&Linux and that would decrease the communicative value of that code, I'm less then happy about that. We could work with a condition and execute either of two versions of this call if only we could detect what the host OS is but I don't believe we can. Would it be a idea to have a standard library function to simply ask the OS what it is or use the fact that upon compiling ChucK we already know what it will run on since we need to set a flag for what version we are building? That's how far I got before dozing off... Perhaps helpful or interesting to some? Cheers, Kas. PS; the same technique might conceivably be used to append lines to the program itself. This sounds like a exciting, daring and dangerous plan that I haven't yet found a use for. Abuse with care.

4 5

how is this "on the fly"?
by AlgoMantra 18 Sep '07

18 Sep '07

Hi there - I'm very new to ChucK so please be kind if I sound incredibly stupid, and very angry because I am going nuts here. (Kassen, I'm here - we had a very brief exchange about ChucK with toplappers) I'm writing my scripts using SciTE, and using the command-line VM. I have tried some Chuck with tutorials, manual and helpful tips on forums, usually by someone too good to be true like Kassen.I want to know what people really mean by OTF (on the fly) or by "livecoding" in Chuck. If you prepare your files and code in advance and then just chuck the shreds in and out of the VM, it really is a a bit like sequencing, rather than livecoding. And if I change the code in the file, save it, then the effects don't appear live, do they? I really don't see how i'm changing the code "while its running" here. Maybe i'm missing something freakin obvious, but I'm so frustrated having had to learn Csound, Chuck, SuperCollider and all sorts of new languages just because Python did not provide me with a simple audio processing module. All I wanted to do using Python was analyse the sound of a live flute playing and plot its frequency, and other characteristics, straight off the audio port. Now I'm a newbie at all of the above, and thats really fantastic because it hasn't solved a single problem. It has certainly added a few more. What a royal mess. ------- 1/f ))) ------- http://www.algomantra.com

7 23

Python problems
by Joe McMahon 18 Sep '07

18 Sep '07

I can understand that you're having some frustration with your project. The folks here have pointed you to stuff they thought would help. It didn't. This happens. Most of the time, if you're asking a question which has some real meat to it (and yours does), the answers you get from just asking people at relatively speaking random don't help much other than to point you toward some possibilities and to confirm that you have a lot of work to do. If you can pull off realtime FFTs in Python and get something musically interesting out of it, you've done something that would probably qualify as graduate-level computer music work. I have to say I'm not surprised that someone else couldn't just hand you a solution! It does seem sometimes as if the Web is a cornucopia of instant gratification - so many things *are* available just for the asking, The fact that this one isn't should make you very happy! You have an opportunity to be "that guy" who's the one people think of when the subject of realtime music processing in Python comes up ... but only if you're willing to pursue the problem yourself, including all the hard bits and "aw crap I have to learn this/write this/figure this out from first principles". I'd *love* to hear what you finally come up with when you get there -- but I'm afraid it's probably going to be your own road. As an afterthought, have you seen the Snack package (http:// www.speech.kth.se/snack/)? It seems to have capabilities that you might be able to use with sufficient work, but Im pretty sure it's not an out-of-the-box fit. --- Joe M.

2 1

some chuckian announcements
by Ge G. Wang 16 Sep '07

16 Sep '07

Dear ChucKian community members, Quick announcements: I am being officially chucked/upchucked to the left coast of the U.S., where I begin my appointment at Stanford/CCRMA as Assistant Professor (PhD pending). Super stoked about this, and also super sad to leave Princeton - though in many ways, I don't think I am ever really leaving (the currently unfinished chuckian dissertation is but one testament to this - sorry Perry, I promise it'll be done soon!). ChucKian research, development, and melting of CPU's will continue in full and more, now at Stanford and Princeton and elsewhere, and with the full chuck team and new researchers too. The authoritative (and ever-changing) TODO list shall continue to be implemented, Rebecca and I will continue to explore the upchuck and much more, crazy new things will be investigated/realized/maybe even documented, and we all shall endeavor to make the future of chuck/audio programming more fun and less not-fun. Also, the Princeton Laptop Orchestra is undergoing some sort of related mitosis, for I am also to initiate a laptop orchestra at Stanford - perhaps further fulfilling the Manifest Destiny of PLOrk, first envisioned by Dan and Perry, and which we've set in motion in the last two insane years: "a laptop orchestra on every coast (and in between and beyond), running ChucKian software" uh... I made up that last part (but it's a thought, I guess). I want to take this opportunity (and also on behalf of the chuck team) to give thanks to *you* and to this our little chuck family, for the adventure and invaluable support thus far. Here's to more and better research / features / bugs / buffer underruns / bus errors / seg faults / documentation / etc! ThanK you, CheeRs, and may we upChucK in peace! Ge!

3 2

ChucK and Processing
by Arthur Clemens 15 Sep '07

15 Sep '07

Hi, I am quite new to ChucK (new to audio programming even), but my first impressions are positive. The language is clear and uses familiar concepts, so it is easy to pick up. I have written a demo application to let Chuck be controlled through Processing. See my blog post: http://visiblearea.com/blog/bin/view/ VisibleArea/ProcessingandChucK The demo now plays audio files, but it would be easy to change this to let it create and play custom audio. A number of issues I encountered (perhaps due to my ignorance): - It should be possible to start and stop the ChucK VM in Processing, but no stop handlers are called at closing the app, leaving the VM in the air. I understand this is an issue with Java applets. - I would have liked to use 1 FilePlayer class that is loaded only once into the VM, but I have not found a way to do this. Either: 1) call 'chuck fileplayer.ck' before demo files are called causes errors on running the demo files that FilePlayer is unknown 2) for every demo file call 'chuck fileplayer.ck chuckdemo.ck:all:sorts:of:params' causes an error that FilePlayer is already in the global VM space and this will stop the demo file from running - It would be great if MP3 files are played - How can I use the analysis tools to create an equalizer-like display? I am interested in your opinions and suggestions. Arthur Clemens

7 28

Re: [chuck-users] Bay Area Computer Music Technology Group
by Noah Thorp 13 Sep '07

13 Sep '07

Great. Looking forward to meeting you (and congratulations on your new position!) I am still looking for someone to present a ChucK applicaiton, or just the language itself, at the first meeting. Likely dates are Weds sept 26th or Thursday October 4th, both at 6pm. And let me know when you get around to the Left Coast Laptop Orchestra. Count me in for making that happen. All the best, Noah ----- Original Message ---- From: Ge G. Wang <gewang(a)CS.Princeton.EDU> To: ChucK Users Mailing List <chuck-users(a)lists.cs.princeton.edu> Sent: Thursday, September 13, 2007 12:36:42 AM Subject: Re: [chuck-users] Bay Area Computer Music Technology Group > I am starting a new group in the San Francisco Bay Area for making and > using Computer Music Technology. This sounds really great! Noah, please count me in for sure. Also, Spencer is already in the area (looks like he's already joined). As for ChucK, it'd be fun to incite much west coast chucking (as well as some atlantic-pacific chucking, but that's another story, coming soon). Overall, definitely looking forward to all of it! Thank you. Best, Ge! _______________________________________________ chuck-users mailing list chuck-users(a)lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

1 0