Josh Lawrence wrote:

holy shit, it worked!!! :)

sorry for my enthusiasm, but you don't know how I've been struggling with getting something to work this past week (on my linux system in general). imagine my excitement just now when I chucked polyfony.ck and got sound!

Enthousiasm is good! There's more enthousiasm to come, you might have noticed in the other thread that you can hook up many more things to ChucK and most of the time they will work! now I must change that script to get me a moog ;) We have something Moogie too! (/examples/stk/ has three examples and it's in the Ugens section of the manual) this is

great...exactly what I wanted in a system. something catered to live playing, where I can define the code prior to performance and then focus my attention on my midi keyboard during performance.

It would be feasable to reserve a octave of your keyboard for firering off bits of code. Auto-acompanyment with home written AI...

I realize I represent a small subset of people who would actually want to use chuck for this purpose (not live coding, but playing a midi keyboard), but I think it would be worthwhile to mention it in the tutorial.

I agree. I don't think this is such a small sub-set. I spoke to more people online who would like to get started playing ChucK in a more traditional "softsynth" way. Livecoding is new and it's exciting so people talk about it but I don't think people start out by installing ChucK, then learning the syntax on stage. Likely there is a stage inbetween of writing custom aplications and softsynths and so on. I could imagine a set of small "tutorials" grouped in the manual after the basics that would consist mainly of pointers about "where to find what you need for..." with topics on softsynths, creating simple rithems, etc. Nearly all of those topics are already there in the examples but it seems that some extra pointers would be helpfull. ChucK has a very small "hump" at the beginning of the learning curve which in my experience consists of 90% of "getting started, installing and getting round to actually writing something" and 10% of figuring out how to use the manual and the value of /examples/. From there on most people seem to be able to get by on their own.

apparently so! thank you for your kind, quick, and very informative answer. of course, the downside to enlightening me is that you will now have to put up with me on this list ;)

That's not a "downside", that's part of the plan. Welcome! Kas.

On 5/30/07, Stephen Sinclair wrote:

when you do this, how can you really write the code completely from scratch?

Yeah. To explain where I am now; I signed up to write ChucK in a livecoding competiton this Friday evening. These will be audience-graded 6 minute sessions. I don't realy like that as a time span in combination with the competitive context as I think that promotes prepared and practiced cantricks. I'd rather explore longer formats with a element of interaction. Interaction would at the same time force people to adapt on the fly and also take advantage of livecoding as a supremely adaptable instrument. You can play for 6 minutes on a guitar too but it's quite hard to turn a guitar into a different instrument within a hour... how come there isn't a 30-minute pause at the beginning of

your set while you figure out what sound effect you want to make and then you perform a z-transform to figure out the filter coefficients you need or whatnot. no i'm kidding, I know there are a lot of pre-built filters in Chuck, but my point is, how much of your code do you write in advance, or is it really _completely_ on the fly?

While practising for this I've written everything on the fly. This is actually a lot of fun. With ChucK it's very easy to write something that makes some sound within half a minute to a minute and it can be elaborated on in similar steps. I'm finding the STK is a treasure-trove for this. The STK has a lot of toys that will make very nice sounds in a very simple way yet that can still be elaborated on to get very personalised results. i'm imagining that a livecoder would have at least prewritten some

sound effects and is triggering them live on stage by sporking them... but how many actual sound routines do you make up right there on the stage?

I imagine this differs per person and per occasion. If you would be asked to supply a entire evening of music it would be nice to have some files at hand to fill at least some of it.... personally it takes me minutes or hours of coding to get the sound

that i want, that's why i can't figure out how you'd do it on a stage in front of people..

Yes; that's most definately a question, but I find that's a question that affects all live performance. For example; I use a farly large analogue mixing desk in my little studio as well as a stack of analogue effects and some of those big old samplers with the cruchy DA's. To me those are great if time-consuming toys to get the exact sound I want but I'm NOT hauling that to a gig. As you mention there would be no time but another matter is that I couldn't even lift all of it at the same time either. So; for live performance there will need to be a compromise which basically means; recording some of it to the laptop. If you make that choice you get the same or nearly the same sound but with less of a live element. I think it's safe to say that live performance of electronic music is a compromise anyway. With livecoding you don't get the same sound that you could otherwise get because there is no time for that. On the other hand; you do get a lot of surprises that can be stimulating and nobody will complain it's not live enough. Another matter is that in my own experience sets that sound perfect but are etched in stone aren't that much fun to perform on stage. For my own primary liveset right now I put the compromise at using prepared sounds and sequencing those (in a ChucK-made sequencer) on the fly. I don't think I'll move to livecoding as a primary instrument any time soon but as a chalenge and a experiment it sounded like fun and it turns out to be, so far. Maybe there's something about the concept that i'm just not getting.. I think the easiest way to "get it" would be to sit down one afternoon and see how much you can do from scratch in a hour. If that's fun, do that a few times and I'm sure you'll soon be able to make something simple yet fun in a few minutes without using the manual. At that point you can considder "showing it off", kinda like guitarists will pick up a guitar in mid-conversation. This isn't a hard process, it's fun and there is no need to fill a stadium for 3 hours by next week. As for my personal interest in Chuck, I'm actually planning on using

it as an audio back-end for some GUI-style audio applications, I think it makes for a really nice, OSC-enabled, cross-platform sound driver. (Well, as soon as I have time to work on something new...)

Well, that's perfectly fine as well but that's not mutually exclusive with occasional one hour livecoding jamsessions for personal enjoyment at all. In fact I think that those two would benefit from eachother. I think it's clear that I'd like to take this moment to encourage people to try livecoding a few times but it should also be clear that there is no pressure on anyone. There is most definately nothing wrong with making softsynths "OSC-enabled, cross-platform sound drivers" or midi-learn tools for devices that lack one! Cheers, Kas. ps, wow, that turned out long....

Josh Lawrence wrote: I felt much like stephan, in that

if I wasn't live coding I wasn't welcome. this idea was, of course, wrong - I had "prejudged" the chuck community prior to actually checking it out for myself.

Yes, that's not just wrong, I think it's fundamentally silly idea in that nobody could go from not using ChucK to livecoding in one step. I think everybody is welcome and everybody is invited to livecode if (s)he wants to but those are quite unrelated. To me it would be quite sad if some single dogmatic way of "playing" ChucK would be established. I'm so excited about this tool that I can barely stand it. finally, a

toolkit without a gui! yes! and it does everything you could want it to do. besides, as stated before it is jack/midi/osc aware, so it *should* play nicely with other apps that are the same.

Yeah, exactly. Some people are using ChucK to make a Monome controler talk to Ableton Live, I've been using it to turn gaming devices into MIDI controlers, it makes a great "glue" between aplications and devices. I think that aspect of it will only grow with the Wii interface rumoured and maybe future suport for sysex-MIDI. Kas.

Somewhat related to the whole livecode issue is this; http://electro-music.com/forum/viewtopic.php?t=13512 Kijjaz cooked up this game of very short ChucK programs; "let's make up some rules for this game: * the code must be on only 1 line * no more than 80 characters * crazy " To me that has a smilar sort of idea to livecoding but where livecoding rewards writing as quickly as possible this rewards writing as compactly as possible. At least that topic should demostrate that a lot can be done without labouring over 5000 lines spread out over at least ten files... Kas.

On 5/30/07, Stephen Sinclair wrote:

i'm personally more into beat-oriented electronic music, so i imagine perhaps having a bank of samples at my disposal for messing with might be helpful.

glad you brought that up - I was going to scour the manual for this, but since you mentioned it...does chuck have any sort of mechanism for dealing with .wav files? specifically, playing samples? just point me in the right direction... -- Josh Lawrence http://www.hardbop200.com http://www.joshlawrencetrio.com

Josh Lawrence wrote:

On 5/30/07, Stephen Sinclair wrote:

...

i'm personally more into beat-oriented electronic music, so i imagine perhaps having a bank of samples at my disposal for messing with might be helpful.

glad you brought that up - I was going to scour the manual for this, but since you mentioned it...does chuck have any sort of mechanism for dealing with .wav files? specifically, playing samples? just point me in the right direction...

Definitely check out the examples/hanoi++.ck example. It really helped me figure out how to deal with .wav files in the ChucK manner. My complaint is that it took a while to figure out what exactly was going on, since it isn't straightforward like "load a file, tell it to play"; it's "load a stream, constantly play samples until the stream ends, and set the position to 0 to restart it". Basically, my tactic when using a bank of samples is to now load them, set them all to the end of the files (so they don't play immediately upon loading), and when I want them to play, I just set the position to 0. I guess it does offer more flexibility in certain circumstances, but why isn't there (or /is/ there?) a more straightforward way to play a .wav file like a simple sampler (load, play)? Sorry for the jumbled thoughts, but I just woke up. :D -Drew