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

extending UGens thoughts
by Kassen 16 Oct '11

16 Oct '11

Fellow ChucKists, A few days ago I was talking with my friend Casper Schipper about the exciting new thing that extending UGens now works. Here are some modest proposals for extending that; * Reserve a ".tick()" function name for automatically overwriting the base class's tick function. Rationale; while we can (as I demonstrated with a quick example on this list) spork a shred that will make a UGen like Step or Impulse output a signal that shred will not be at the right place in the overall execution order as shreds (by definition) can't run while the Ugen-graph updates. Another down-side to that strategy is that unchucking the UGen in that case won't freeze its behaviour nor save CPU. This is inconvenient, it can harm sound quality and generally makes our own work a sort of "second rate citizen". With custom UGens that behave like build-in ones libraries shared by the community wouldn't need much of a extra manual which will make code more consistent and sharing possibly more popular. This special function would be called instead of the normal tick and would -clearly- need to be of type float or a compilation error would be thrown. Overwriting .tick() would be entirely optional, for a class foo that extends LiSa we may just wish to set some behaviour in some default way that we happen to use a lot today and have LiSa herself deal with the processing. * Reserve a "pull" float for pulling any UGens after our Ugen in the graph. Rationale; to preserve correct execution order and to have maximum flexibility in our own creations we'd like our custom UGens to have inputs. Currently this would be very hard to accomplish, even when we disregard UGen-graph execution order. "pull" would be a float that would be computed from our UGen's inputs (depending on our .op), if it's used in the tick function, and replace all uses of that variable in this call of the function. By that I mean we don't tick all of the UGens behind us multiple times just because we need the value a few times. For that reason I think it's more clear to abstract this away as a float, instead of having it be a explicit function. "pull" in the context of a function named "tick" wouldn't need to be declared, I imagine. That's elegant (I think), it's also a exception to what we have so far in that it would be a highly context dependant special variable but UGens are a unusual type in general and even with regard to timing, our big focus, behave quite unusually. So, let's have a example of what this would look like. Let's say I'd like to have a new UGen that would add a small bit of noise to a signal (example intentionally kept simple). I'll write that UGen and use it on a arbitrary input; class AddNoise extends UGen { float amnt; //some internal state fun float tick() //tick function { return (pull * (1 - amnt) + Std.rand2f(-1 * amnt, amnt); //here we pull, if we don't have a input we'll just get some noise but if we wish we could detect that condition and deal with it, } fun float amount(float in) //way of setting the behaviour { if (in > 1) 1 => in; else if (in < 0) 0 => in; in => amnt; return in; } fun float amount() {return amnt;} //overloaded get function as those are standard. } //let's go! adc => AddNoise an => dac; .1 => an.amount; minute => now; <<<"bye!">>>; This, to me, looks simple, expressive and realistic. Particularly I can't see any big things here that would backfire if at some point we'd like to be able to pre-compile external UGens into some sort of module format. This should also -as far as I can see- play nicely with the existing UGen graph functionality, for example the detection of feedback loops. Note that Casper and me were brainstorming about our wishes, any glaring errors in this post are mine. Also note that this proposal could make .tick() a thing you could explicitly call manually, possibly for all UGens. I don't see a big problem with that, it might even be useful and/or fun. Yours, Kas.

1 0

live-coding resources
by Renato Fabbri 12 Oct '11

12 Oct '11

Dear ChucKists, ChucKers and alike, We are going to do some live-coding performances in November here in Brazil, at São Carlos, and we wish to use ChucK as much as possible! It would be great to hear from you all about your live-coding experiences with ChucK: how you did it, which codes did you use, what was the outcome, what would you do different etc.. I know this has been a topic that once in a while is back, and I see this as a positive thing: ChucK is oriented towards live-coding AFAIK. We will be glad to cite this list and individuals by name (and perhaps more info :-) and about any contribution. Thanks and cheers! Fabbri -- GNU/Linux User #479299 labmacambira.sf.net

2 1

Scale & diatonic
by Hans Aberg 12 Oct '11

12 Oct '11

I have made a program, scale.ck, that admits one to work with scales, including tuning stretch, céleste tremulant, retune them, and then save to a file, with a line of code that can be pasted back into the source, available at next program startup. Scale tunings can be put into tuning banks, and otherwise defined by your favorite method. Details in the file. I have also updated my program for diatonic tuning systems, diatonic.ck. Just a few changes: adding some common tunings, fixing typos. The files are available here: http://www.math.su.se/~haberg/tuning_systems/ Hans

4 6

one-liners
by Kassen 12 Oct '11

12 Oct '11

Fellow ChucKists, This ; http://countercomplex.blogspot.com/2011/10/algorithmic-symphonies-from-one-… ...will likely be of interest to people playing the "most interesting sounds in a single line of code" game. It's also quite inspiring as a source of ideas for very free-form synthesis of lo-fi sounds. Yours, Kas.

5 7

Re: [chuck-users] ChucK & mouse handling on Lion
by Ryan Spicer 11 Oct '11

11 Oct '11

Spencer, Here's the output of $chuck -v5 fm-mouse.ck $ chuck -v5 fm-mouse.ck [chuck]:(2:SYSTEM): setting log level to: 5 (INFORM)... [chuck]:(2:SYSTEM): initializing virtual machine... [chuck]:(2:SYSTEM): | behavior: HALT [chuck]:(2:SYSTEM): | locking down special objects... [chuck]:(2:SYSTEM): | allocating shreduler... [chuck]:(2:SYSTEM): | allocating messaging buffers... [chuck]:(2:SYSTEM): | real-time audio: YES [chuck]:(2:SYSTEM): | mode: CALLBACK [chuck]:(2:SYSTEM): | sample rate: 44100 [chuck]:(2:SYSTEM): | buffer size: 256 [chuck]:(2:SYSTEM): | num buffers: 8 [chuck]:(2:SYSTEM): | devices adc: 0 dac: 0 (default 0) [chuck]:(2:SYSTEM): | adaptive block processing: 0 [chuck]:(2:SYSTEM): | channels in: 2 out: 2 [chuck]:(2:SYSTEM): initializing compiler... [chuck]:(3:SEVERE): | initializing type checker... [chuck]:(3:SEVERE): | | adding base classes... [chuck]:(3:SEVERE): | | | class 'object' [chuck]:(3:SEVERE): | | | class 'array' [chuck]:(3:SEVERE): | | | class 'string' [chuck]:(3:SEVERE): | | | class 'ugen' [chuck]:(3:SEVERE): | | | class 'uanablob' [chuck]:(3:SEVERE): | | | class 'uana' [chuck]:(3:SEVERE): | | | class 'shred' [chuck]:(3:SEVERE): | | | class 'event' [chuck]:(3:SEVERE): | | | class 'io' [chuck]:(3:SEVERE): | | | class 'fileio' [chuck]:(3:SEVERE): | | | class 'chout' [chuck]:(3:SEVERE): | | | class 'cherr' [chuck]:(3:SEVERE): | | | class 'class' [chuck]:(3:SEVERE): | initializing emitter... [chuck]:(3:SEVERE): | loading built-in modules... [chuck]:(3:SEVERE): | | module osc... [chuck]:(3:SEVERE): | | module xxx... [chuck]:(3:SEVERE): | | module filter... [chuck]:(3:SEVERE): | | module STK... [chuck]:(3:SEVERE): | | module xform... [chuck]:(3:SEVERE): | | module extract... [chuck]:(3:SEVERE): | | class 'machine'... [chuck]:(3:SEVERE): | | class 'std'... [chuck]:(5:INFORM): | | initializing KBHitManager... [chuck]:(5:INFORM): | | starting kb loop... [chuck]:(3:SEVERE): | | class 'math'... [chuck]:(3:SEVERE): | | class 'opsc'... [chuck]:(3:SEVERE): | loading chugins [chuck]:(5:INFORM): | | unable to open directory '/usr/lib/chuck', ignoring for chugins [chuck]:(5:INFORM): | | unable to open directory '/Library/Application Support/ChucK', ignoring for chugins [chuck]:(2:SYSTEM): type dependency resolution: MANUAL [chuck]:(2:SYSTEM): initializing synthesis engine... [chuck]:(3:SEVERE): | initializing 'dac'... [chuck]:(3:SEVERE): | initializing 'adc'... [chuck]:(3:SEVERE): | initializing 'blackhole'... [chuck]:(2:SYSTEM): | initializing 'real-time' audio... [chuck]:(3:SEVERE): | allocating buffers for 256 x 2 samples... [chuck]:(3:SEVERE): pre-loading ChucK libs... [chuck]:(3:SEVERE): starting compilation... [chuck]:(5:INFORM): setting thread priority to: 60... [chuck]:(2:SYSTEM): starting listener on port: 8888... [chuck]:(2:SYSTEM): running virtual machine... [chuck]:(3:SEVERE): | initializing audio buffers... [chuck]:(3:SEVERE): | virtual machine running... carrier: 220.000000 modulator: 500.000000 index: 1000.000000 [chuck]:(5:INFORM): initializing HID... [chuck]:(5:INFORM): | hid: new device(s) found [chuck]:(5:INFORM): | hid: preconfiguring joystick 0 [chuck]:(5:INFORM): | hid: preconfiguring joystick 1 [chuck]:(5:INFORM): | hid: device not recognized, attempting to determine HID type [chuck]:(5:INFORM): | hid: configuring Apple Mikey HID Driver [chuck]:(5:INFORM): | unknown page: 1 usage: -1 [chuck]:(5:INFORM): | unknown page: 1 usage: 139 [chuck]:(5:INFORM): | unknown page: 1 usage: 138 [chuck]:(5:INFORM): | unknown page: 1 usage: 137 [chuck]:(5:INFORM): | unknown page: 1 usage: -1 [chuck]:(5:INFORM): | unknown page: 1 usage: 141 [chuck]:(5:INFORM): | unknown page: 1 usage: 140 [chuck]:(5:INFORM): | hid: device not recognized, attempting to determine HID type [chuck]:(5:INFORM): | hid: configuring Apple IR [chuck]:(5:INFORM): | unknown page: 1 usage: -1 [chuck]:(5:INFORM): | unknown page: 1 usage: 134 [chuck]:(5:INFORM): | unknown page: 1 usage: 137 [chuck]:(5:INFORM): | unknown page: 1 usage: 138 [chuck]:(5:INFORM): | unknown page: 1 usage: 139 [chuck]:(5:INFORM): | unknown page: 1 usage: 132 [chuck]:(5:INFORM): | unknown page: 1 usage: 133 [chuck]:(5:INFORM): | unknown page: 1 usage: 130 [chuck]:(5:INFORM): | unknown page: 1 usage: 131 [chuck]:(5:INFORM): | unknown page: 1 usage: -1 [chuck]:(5:INFORM): | unknown page: 1 usage: 140 [chuck]:(5:INFORM): | unknown page: 1 usage: 141 [chuck]:(5:INFORM): | hid: preconfiguring mouse 0 [chuck]:(5:INFORM): | hid: preconfiguring mouse 1 [chuck]:(5:INFORM): | hid: device not recognized, attempting to determine HID type [chuck]:(5:INFORM): | hid: configuring Apple Internal Keyboard / Trackpad [chuck]:(5:INFORM): | hid: preconfiguring keyboard 0 mouse 'Apple Internal Keyboard / Trackpad' ready... [chuck]:(3:SEVERE): starting real-time audio... [chuck]:(5:INFORM): hid: starting Apple Internal Keyboard / Trackpad [chuck]:(5:INFORM): | hid: configuring Apple Internal Keyboard / Trackpad [chuck]:(5:INFORM): | hid: adding Apple Internal Keyboard / Trackpad to run loop [chuck]:(5:INFORM): setting thread priority to: 60... [chuck]:(3:SEVERE): starting real-time watch dog processs... [chuck]:(5:INFORM): | watchdog timeout: 0.500000::second [chuck]:(5:INFORM): | watchdog thread priority: 60 [chuck]:(5:INFORM): | watchdog countermeasure priority: 10 [chuck]:(5:INFORM): setting thread priority to: 60... -- Ryan Spicer =============================== Research Assistant / Teaching Assistant IGERT Trainee Reflective Living Module School of Arts Media + Engineering Arizona State University http://rl.ame.asu.edu

1 0

Esse?
by Lucas Zawacki 11 Oct '11

11 Oct '11

http://www.youtube.com/watch?v=eIzoWNQqnEQ&feature=related

2 2

ChucK & mouse handling on Lion
by Ryan Spicer 10 Oct '11

10 Oct '11

Hi intrepid ChucK developers/users: I've got the Lion-ready beta of ChucK working on my Macbook Pro (late 2010), but it appears that the mouse HID interface isn't working quite right. Is this a known bug? I'm testing with the "mouse-fm.ck" file in MiniAudicle (http://chuck.cs.princeton.edu/doc/examples/hid/mouse-fm.ck) and it appears that the code is never reaching any of the msg.isButtonUp()/msg.isButtonDown()/msg.isMouseMovement(); states. Has anyone else encountered this? Is there a work-around? -- Ryan Spicer =============================== Research Assistant / Teaching Assistant IGERT Trainee Reflective Living Module School of Arts Media + Engineering Arizona State University http://rl.ame.asu.edu

2 1

Re: [chuck-users] Android port
by Harald 04 Oct '11

04 Oct '11

Android apps normally run on java... However, you *can* build native apps, but then they will not run on all possible devices, but only on those having the same CPU (normally ARM based). Then you would need an interface to hardware devices (audio, midi, etc.). Does rtaudio support android?

2 1

Android port
by Christopher Van Kirk 04 Oct '11

04 Oct '11

Hi all. I'm sorry if this question has been asked before. I've been googling for a while now and haven't been able to find an answer to this question. Navigating the archive is a challenge without a search feature. Anyway, my question is this. Has anyone ported ChucK's VM to Android? Just looking at the code it seems as though it might compile..is there any reason why one should not use it on the Android platform? Thanks! Chris...

2 1

extending UGen
by Kassen 01 Oct '11

01 Oct '11

Dear list, Here's a small exercise testing the "new" feature, it generates noise according to the classical "3x+1" series; //may generate extreme signals. Mind your ears, speakers and neighbours, please class Foo extends Step { true => next; spork ~ gen(); fun void gen() { 50 => int x; 1 => float value; while (true) { if (x == 1) Std.rand2(1, 100) => x; else if (x % 2) 1 + (3 * x) => x; else x / 2 => x; x::samp => now; last() * -1 => next; } } } Foo bar => dac; 3::minute => now; Notice that we can use .last() and .next() from inside of the class; this is nice. Not so clear -yet- is whether we can create our own "tick" that will be called every samp at the moment the UGen is ticked by the one downstream or whether we could get to values send into this by the ChucK operator... but it works and it's nice! Yours, Kas.

1 0