Dear all, We would like to conduct a N-part user study (where N >= 1) on using ChucK. To start, we are interested in learning about how everyone is using ChucK, the ways (if any) ChucK has effected the way you write/think about audio programming, and/or your thoughts on ChucK. A dissertation is being written (mine), and we want to include evaluations/feedback from the primary ChucK community (this list). Also, we hope to construct a page to showcase works being done using ChucK. So fire away! Thank you all very much!!! (slightly) more detail here: http://wiki.cs.princeton.edu/index.php/ChucK/UserStudy Best, chuck team
Ge Wang;
We would like to conduct a N-part user study (where N >= 1)
Excelent. I'll go be the degenerate case for this equation then.
on using ChucK. To start, we are interested in learning about how everyone is using ChucK,
I've been using the plain command prompt version. Audicle is a work of art but aparently my video card isn't. Mainly I've been building custom sequencers and beat mangeling devices controlled in realtime by the keyboard, MIDI and recently a joypad as well. The otf commands at the moment seem too indirect to me to be satisfying as a instrument on their own. Random-ness doesn't apeal to me on a compositional level so realtime controll it is. The OTF commands flush my prescious arrays and we can't have that. This may change as global data and command line parameters arrive. Basically I've been building the sort of thing I miss in Live and Renoise, primarily to treat and play samples. One structure I use a lot is having a "step" parameter and increase that as I chuck to now. I then use this as a index to arrays and write all sorts of stuff to the arrays in various ways. Currently I like arrays much better then traditional sequencers. the problem with sequencers is that they tend to asume a "composition" style of taking input and not a "musician" style. The Serge TKB is the one sequencer I like a lot but it lacks S&H type structures and it's also about a order of magnitude out of my financial range.
the ways (if any) ChucK has effected the way you write/think about audio programming, and/or your thoughts on ChucK.
I have to admit that ChucK didn't change the way I think about audio processing or programing in the slightest. Oscilator => filter => output Looks comparatively good compared the equivalent in Csound (or even the pannel of a arp 2500!) but it's not all that different, you can do the same everywhere (and that's good). It did however profoundly change the way I look at controling sound, particularly as time is concerned. My current main ChucK project uses a interface where I am always slightly ahead of realtime, cueing up a series of events, then doing something else while they execute. Also good is that for some reason ChucK is very intuitive and easy to program in. I find I can prototype new ideas very quickly. Where in the past I'd lament the lack of a feature in a tool I can now generally make my own and have it within two or three hours. Another good thing is that ChucK has a very small user base (you may disagree there...) which means you can talk to the developers directly. I don't think Cubase's lead programer is looking to get emails from all users that discovered they have some issue two minutes ago and I imagine that if he did he probably wouldn't reply with links to a updated binary. Finally; MAX and SC fanatics seem to think ChucK users are inherently clinically insane. Actually even my label boss seem to think it's a insane idea to plan on performing with homebrew stuff since it may crash. I suppose that's true, but other things may crash too and other things tend not to be able to conveniently go "if(maybe) machine.crash;" Not so good is that ChucK is heavy on the CPU but I agree with Perry that the main apeal is the way it works and this should get priority over optimistation. I'd like to chime in with your request for feedback because beyond the custom editors I have no idea at all what anybody else is actually doing with this stuff. Kas.
Hi list, I am working with the miniAudicle and I must say I am very pleased and impressed with the editor and the "On the fly" possibilities thus far. Working through the Chuck manual it is quite easy to start programming and I already got some interesting sounding patches (especially using the possibilities of multiple shreds). I could not find a way though to work with buffers and looping as in Max/MSP or Super Collider (without writing audio to disk first). Is this to be implemented in the future or is there a way to do this already? Audicle and miniAudicle are installed and worked fine (except for loading soundfiles). If I want to use the chuck commandline in the terminal (MacOs 10.3.9) I get this message when trying to start the virtual machine with chuck --loop: cannot bind to tcp port 8888... I think chuck must be installed properly because the command chuck --help gives me this message: usage: chuck --[options|commands] [+-=^] file1 file2 file3 ... [options] = halt|loop|audio|silent|dump|nodump|about| srate<N>|bufsize<N>|bufnum<N>|dac<N>|adc<N>| remote<hostname>|port<N>|verbose<N>|probe| channels<N>|shell|empty|blocking|callback [commands] = add|remove|replace|status|time|kill [+-=^] = shortcuts for add, remove, replace, status chuck version: 1.2.0.5b (dracula) http://chuck.cs.princeton.edu/ Is there anybody who can explain this? Best, Hans.
I could not find a way though to work with buffers and looping as in Max/MSP or Super Collider (without writing audio to disk first). Is this to be implemented in the future or is there a way to do this already?
Hi, Hans, I think this is on the list of "to do" things for some upcoming version. I saw it somewhere on the WIKI but now I can't find where anymore. I'd like live sampling too. Kas.
why not use an array as a buffer? i haven't tried it but it should work... best joerg Kassen wrote:
I could not find a way though to work with buffers and looping as in Max/MSP or Super Collider (without writing audio to disk first). Is this to be implemented in the future or is there a way to do this already?
Hi, Hans,
I think this is on the list of "to do" things for some upcoming version. I saw it somewhere on the WIKI but now I can't find where anymore. I'd like live sampling too.
Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- http://joerg.piringer.net http://www.transacoustic-research.com http://www.iftaf.org http://www.vegetableorchestra.org/
On 5/27/06, joerg piringer
why not use an array as a buffer? i haven't tried it but it should work...
True. but for looping you'd need quite a few commands at sample rate and often that's very expensive. I'll try to do a version of the joypad/breakbeat thing a posted a few days ago using a array and see where I end up, then report on results. I'd love to hear about anybody else's atempts at this as well. Kas.
On May 26, 2006, at 7:05 PM, Hans Leeuw wrote:
Hi list,
I am working with the miniAudicle and I must say I am very pleased and impressed with the editor and the "On the fly" possibilities thus far.
Awesome!
I could not find a way though to work with buffers and looping as in Max/MSP or Super Collider (without writing audio to disk first). Is this to be implemented in the future or is there a way to do this already?
As has been mentioned, you could try filling a big array with samples from whichever ugen your are using, and then feed that into an impulse ugen.
Audicle and miniAudicle are installed and worked fine (except for loading soundfiles).
What is the problem you are having loading soundfiles? If youre getting "could not stat file ..." errors, it could be because older versions of miniAudicle basically required absolute pathnames to be supplied to sndbuf ugens. The most recent version of miniAudicle lets you change the current directory, in the preferences, so that pathnames are interpreted relative to that directory. Im not as familiar with the Audicle but I imagine sndbuf errors might result from similar relative filename issues, depending on where/how you invoked the Audicle.
If I want to use the chuck commandline in the terminal (MacOs 10.3.9) I get this message when trying to start the virtual machine with chuck --loop:
cannot bind to tcp port 8888...
the ChucK on-the-fly commands operate by communicating through a standard TCP port, 8888. Are you perhaps running another application at the same time that uses this port? That would cause this sort of conflict. For example, the miniAudicle actually also uses port 8888 to accept remote on the fly commands, so if you were running miniAudicle and then tried to run chuck --loop, you would get that error. If that is what is happening, you can disable this functionality in the miniAudicle preferences and chuck --loop should work. hope this helps spencer
Thanks Spencer, Joerg and Kassen,
It worked (see under live-sampling with a 2 second buffer). I had to use the
Delay trick because I could not address adc directly. That would be more
elegant I think (and saves computing time). Does any of you have a solution
to that as well? Or is there even a more elegant solution.
float array[82400];
adc => Delay d => blackhole;
0::second => d.delay;
impulse i => dac;
for ( 0 => int sample; sample < 82400 ; sample++ )
{
d.last() => array[sample];
1::samp => now;
}
for ( 0 => int sample; sample < 82400 ; sample++ )
{
array[sample] => i.next;
1::samp => now;
}
On 27/5/06 2:07 am, "Spencer Salazar"
On May 26, 2006, at 7:05 PM, Hans Leeuw wrote:
Hi list,
I am working with the miniAudicle and I must say I am very pleased and impressed with the editor and the "On the fly" possibilities thus far.
Awesome!
I could not find a way though to work with buffers and looping as in Max/MSP or Super Collider (without writing audio to disk first). Is this to be implemented in the future or is there a way to do this already?
As has been mentioned, you could try filling a big array with samples from whichever ugen your are using, and then feed that into an impulse ugen.
Audicle and miniAudicle are installed and worked fine (except for loading soundfiles).
What is the problem you are having loading soundfiles? If youre getting "could not stat file ..." errors, it could be because older versions of miniAudicle basically required absolute pathnames to be supplied to sndbuf ugens. The most recent version of miniAudicle lets you change the current directory, in the preferences, so that pathnames are interpreted relative to that directory.
Im not as familiar with the Audicle but I imagine sndbuf errors might result from similar relative filename issues, depending on where/how you invoked the Audicle.
If I want to use the chuck commandline in the terminal (MacOs 10.3.9) I get this message when trying to start the virtual machine with chuck --loop:
cannot bind to tcp port 8888...
the ChucK on-the-fly commands operate by communicating through a standard TCP port, 8888. Are you perhaps running another application at the same time that uses this port? That would cause this sort of conflict.
For example, the miniAudicle actually also uses port 8888 to accept remote on the fly commands, so if you were running miniAudicle and then tried to run chuck --loop, you would get that error. If that is what is happening, you can disable this functionality in the miniAudicle preferences and chuck --loop should work.
hope this helps spencer
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
I had to use the Delay trick because I could not address adc directly. That would be more elegant I think (and saves computing time). Does any of you have a solution to that as well? Or is there even a more elegant solution.
Wait, are you saying we can't chuck adc to blackhole, then use "adc.last()"? I had asumed we could. Let me try this once I've had some sleep. Also;I think I would use "step" intstead of "impulse". I don't think it would make a difference when pitching the playback buffer up but when pitching down it would mean both simpler code and less cpu. Kas.
ChucK Researchers, Hope this isn't too late. I'm a huge fan of chuck, because: a) it's pretty deeply cross-platform (sc is ultra-cool, but harder to use without owning a Mac) b) it's hackable c) the language is both simple and whimsical d) instrument presets! (STK) Mostly I use the Audicle, with command-line chuck a few times (sometimes in conjunction with chuck.el). It's fun and quick for adding and removing layers to music. Once I figured out how to do recordings in Audicle, I don't need to use the other as much. As a programmer and frustrated musician, I feel as if it allows me to express musical ideas in ways that are perhaps unexpressible in other music domains. And I like that. It works for simple improvisation, or making something more deliberate. If the platform remains stable for a few years I hope to develop at least a nice familiarity with it, like the kind that instrumentalists develop with their instruments. At some point, I'd like to swap livecoding wisdom and ideas with you dudes from the NJ camp. I find it hard to articulate these kinds of strategy without falling back on pure musical convention. sketchiness: Also, I find that the chuck-Audicle revision model seems to fulfill a searched-out quantity I prize in creative tools: for lack of a better term I'll call it sketchiness (besides the poor collision with the term meaning low quality or suspect). That is, some of my friends growing up tend to draw, you know whenever. Start a sketch, doodle in class, pick up something, refine it, etc. Anyway, these folks end up getting really good, less out of diligent patience than iterated and distracted practice. * For a while I've been looking for sketchy musical tools. For a process to be sketchy, or like sketching, it should: - be immediate, quick to engage or start up in - be incremental, easy to save and resume working on For me, carrying a chuck shred through many revisions in audicle and layering them is sketchy. In addition, I frequently save some layers and come back to them, adding parts later. creative projects: I'm trying to compose an album of polished chuck sketches. Here are some studies in pursuit of this goal: http://cola-fan.livejournal.com/95649.html (newer) http://cola-fan.livejournal.com/94685.html (already posted here) Also, chuck has slipped into my more directly pop music aspirations (a bossa-nova-ish demo from an upcoming album of my band, the Men of Science **). http://ravelite.org/music/dsmooth/another%20time.mp3 To foray into teaching, I gave a presentation at dorkbot. Perhaps someday I'll break out of the cheesy-pop paradigm that I use for my improvisations, but I made a tutorial to http://ravelite.org/chuck-notes/tutorial.html Music generators are almost as old as music itself, (an excellent article in Roads' Computer Music Tutorial) but I think it would be fun to make one in chuck. If WolframTones is still in vogue... the technical: the chuck emacs mode: http://ravelite.org/code/chuck/chuck-mode.el I made a few additions, but it could use a few more. Right now, you can start chuck processes (win32) but getting feedback from the exec is rough. I had planned to ask the emacs community, but haven't gotten to it. the trivial language hack: http://ravelite.org/code/chuck/instanceof5.patch Mostly I wanted to see how things worked on the inside of ChucK. I'd like to do more of this yet. (Is there a list of open tasks somewhere?) The far off: chuck library interface: For a while, I thought it would be cool to have some sort of library interface to chuck, so mainstream applications and games programmers could compile it into projects and make novel music interfaces quickly. Design issues abound - how shall it be controlled? However, Ollie's awesome drum machine may demonstrate that this is not necessary. Having a musical kernel controlled by OSC and separately executed seems like a simple and natural solution available in most platforms. silly: (functional language frontend for ChucK) http://atlhack.org/images/sonicboomchuck.png Finally, there are silly vanity projects: http://www.flickr.com/photos/73155597@N00/120589645/ (the egg) http://www.flickr.com/photos/73155597@N00/163444838/ (the shirt) Graham *This reminds me of a passage from Walter Benjamin The Work of Art in the Age of Mechanical Reproduction, which is about fascism and film, and not chuck http://bid.berkeley.edu/bidclass/readings/benjamin.html "The distracted person, too, can form habits. More, the ability to master certain tasks in a state of distraction proves that their solution has become a matter of habit. Distraction as provided by art presents a covert control of the extent to which new tasks have become soluble by apperception. Since, moreover, individuals are tempted to avoid such tasks, art will tackle the most difficult and most important ones where it is able to mobilize the masses." ** http://ravelite.org/menofscience/ On Mon, 22 May 2006, Ge Wang wrote:
Dear all,
We would like to conduct a N-part user study (where N >= 1) on using ChucK. To start, we are interested in learning about how everyone is using ChucK, the ways (if any) ChucK has effected the way you write/think about audio programming, and/or your thoughts on ChucK. A dissertation is being written (mine), and we want to include evaluations/feedback from the primary ChucK community (this list). Also, we hope to construct a page to showcase works being done using ChucK. So fire away! Thank you all very much!!!
(slightly) more detail here:
http://wiki.cs.princeton.edu/index.php/ChucK/UserStudy
Best, chuck team
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Graham Coleman;
sketchiness: Also, I find that the chuck-Audicle revision model seems to fulfill a searched-out quantity I prize in creative tools: for lack of a better term I'll call it sketchiness (besides the poor collision with the term meaning low quality or suspect).
This is cool, you are on to something here. I don't think there is that bad a collision; I think my friends are like yours and mine keep dummies. The idea seems to be that dummies are somewhat private, nobody will see it so it doesn't matter what you put in. With "scetching" as I understand it the absense of quality controll is a great catalyst. Something similar is going on in ChucK, even now that it's somewhat stable-ish and mostly documented-like. We need more of that. Also; I want a ChucK shirt too. Can we have official ChucK shirts that say something along the lines of "realtime isn't fast enough" or should one go to a copy-shop? Kas.
Hello,
Also; I want a ChucK shirt too. Can we have official ChucK shirts that say something along the lines of "realtime isn't fast enough" or should one go to a copy-shop?
I second this. I think this should top-priority. Also, I think that the tee-shirt should feature Graham's sonicboomchuck image on the front (see below). ;-)
(functional language frontend for ChucK) http://atlhack.org/images/sonicboomchuck.png
All joking aside, this is seriously important:
sketchiness: Also, I find that the chuck-Audicle revision model seems to fulfill a searched-out quantity I prize in creative tools: for lack of a better term I'll call it sketchiness (besides the poor collision with the term meaning low quality or suspect).
This is cool, you are on to something here.
This means that the Chuck team has taken something powerful but
terribly abstract (live-coding, audio programming) and made it feel
TACTILE, a quality that most computer-music tools do not exhibit.
This is a tremendous achievement. Performers rejoice! I want to see
Chuck small and fast. I want to see embedded Chuck in small devices.
ChuckNet. Ubiquitous Chucking. The ChuckPod. I want to Chuck as I'm
walking down the street.
It's just a matter of time => now.
This is an inspiring tool and an inspiring community. Thanks, everyone!
-Michael
On 6/11/06, Kassen
Graham Coleman;
sketchiness: Also, I find that the chuck-Audicle revision model seems to fulfill a searched-out quantity I prize in creative tools: for lack of a better term I'll call it sketchiness (besides the poor collision with the term meaning low quality or suspect).
This is cool, you are on to something here.
I don't think there is that bad a collision; I think my friends are like yours and mine keep dummies. The idea seems to be that dummies are somewhat private, nobody will see it so it doesn't matter what you put in. With "scetching" as I understand it the absense of quality controll is a great catalyst. Something similar is going on in ChucK, even now that it's somewhat stable-ish and mostly documented-like. We need more of that.
Also; I want a ChucK shirt too. Can we have official ChucK shirts that say something along the lines of "realtime isn't fast enough" or should one go to a copy-shop?
Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- "ooh aah bleep" -miraton
On 11-Jun-06, at 12:39 PM, mike clemow wrote:
It's just a matter of time => now.
I propose that this be the phrase on the shirt. I think that the front of the shirt be Ge's fancy => logo with the url and the back have this phrase. Anyone willing to help get this going? Maybe there is some online thing like cafepress that could do most of the work for us. --art
Adam Tindale
I propose that this be the phrase on the shirt. I think that the front of the shirt be Ge's fancy => logo with the url and the back have this phrase. Anyone willing to help get this going? Maybe there is some online thing like cafepress that could do most of the work for us.
I'm sticking to my "realtime isn't fast enough" proposal. While listening to some old Jazz "'t'aint what you do it's the time that you do it" also struck a chuckian chord with me as a good phrase. Maybe not as shirt thing though but I thought I'd share anyway. Kas.
Hi!
Perhaps we should have a couple of designs / slogans...
design 1: chuck operator/slogan (front) + url/slogan (back)
slogans (one per shirt):
"realtime isn't fast enough"
"the time is now" (now in courier font)
"keep on chuckin'"
design 2: sonic boom!!! (front) + url (back)
http://atlhack.org/images/sonicboomchuck.png
More ideas? slogans?
We also plan to make t-shirt for the ICMC chuck workshop (November).
This is so chuckin' happening!
Ge! currently somewhere in France...
Quoting Kassen
Adam Tindale
I propose that this be the phrase on the shirt. I think that the front of the shirt be Ge's fancy => logo with the url and the back have this phrase. Anyone willing to help get this going? Maybe there is some online thing like cafepress that could do most of the work for us.
I'm sticking to my "realtime isn't fast enough" proposal.
While listening to some old Jazz "'t'aint what you do it's the time that you do it" also struck a chuckian chord with me as a good phrase. Maybe not as shirt thing though but I thought I'd share anyway.
Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
On Jun 12, 2006, at 11:21 AM, Ge Wang wrote:
Hi!
Perhaps we should have a couple of designs / slogans...
design 1: chuck operator/slogan (front) + url/slogan (back)
slogans (one per shirt): "realtime isn't fast enough" "the time is now" (now in courier font) "keep on chuckin'"
Another design, which I'm currently working on: On the front, the chuck operator logo from the Wiki. On the back, in an appropriate font (still deciding): c h u c k s p o r k s h r e d I'll link some mockups of the chuck-spork-shred logo off the wiki Propaganda page when I have a few to choose from. --- Joe M.
Hi Graham,
Hope this isn't too late.
Nope. It's awesome. Thank you very much!! We are taking user study responses always and we hope to put together some coherent documents later this summer. Thanks again to all who have replied so far! To all: feel free to respond! Best, Ge!
On 6/11/06, Graham Coleman
To foray into teaching, I gave a presentation at dorkbot. Perhaps someday I'll break out of the cheesy-pop paradigm that I use for my improvisations, but I made a tutorial to http://ravelite.org/chuck-notes/tutorial.html
Is this link broken? Sincerely, Tom Lieber http://AllTom.com/ http://GadgetLife.org/
Tom Lieber wrote:
Is this link broken?
Not for me... -- peace, love & harmony Atte http://www.atte.dk | quartet: http://www.anagrammer.dk http://www.atte.dk/gps | compositions: http://www.atte.dk/compositions
participants (11)
-
Adam Tindale -
Atte André Jensen -
Ge Wang -
Graham Coleman -
Hans Leeuw -
Joe McMahon -
joerg piringer -
Kassen -
mike clemow -
Spencer Salazar -
Tom Lieber