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

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

Bay Area Computer Music Technology Group
by Noah Thorp 13 Sep '07

13 Sep '07

Hi All, I am starting a new group in the San Francisco Bay Area for making and using Computer Music Technology. The group's objective is to meet other computer music technology experts and enthusiasts for presentations of computer music techniques and technologies (all music genre outputs are welcome). Presentations and discussion will revolve around the use of Max/MSP, Csound, PD, ChucK, CLM, Live, Reaktor, Kyma, JMSL, SuperCollider as well as other computer music synthesis, composition, or live performance software. Attend to learn new techniques, better the code base, find collaborators, and find out what others are doing in studios, labs, and live work spaces around the Bay Area. If you would like to present a project or technology that you are working on please contact me. Also, if you have a venue that we can host events in (one or more times) let me know. Please pass this email on to other colleagues, collaborators, friends, or students who may be interested in attending. Join the group at: http://electronicmusic.meetup.com/152/?gj=sj2 Feel free to contact me with any questions. All the best, Noah Thorp listenlabs.com / aquabu.com / rabbitsrum.com

4 3

miniAudicle tab issues
by mike clemow 13 Sep '07

13 Sep '07

Salutations, I'm using miniAudicle version 0.1.3.7c on OS X intel and I'm having issues with tabs. Regardless of whether or not the smart-tab function is on or off, the first tab of a function or if statement code block is larger than the second one. I can't make the second one larger by adding more tab white space and usually have to make the first one shorter by 4 spaces or one tab. I didn't think so until now, but apparently I'm really anal about this... Cheers, Mike -- http://shadowofaculture.blogspot.com

1 0

KBHit on a macbook the 2nd !
by Luigi Rensinghoff 10 Sep '07

10 Sep '07

Hi Chuckers Well, the quality of free software, depends on the mailing lists ;-) I am on a Macbook using miniaudicle, for some reason KBHit does not produce any output. Nobody wants to answer ??? Please !!! Luigi

3 4