[chuck-users] NYC-Based ChucKists: "Cloud Seeding" Sept. 1st @ The Stone, 8pm

Andrew C. Smith acsmith at willamette.edu
Sun Aug 30 20:59:49 EDT 2009


Thanks Mike, I got it all working, and the io examples work out as
well.  I'm planning particularly to use the i/o features to store a
database of different tunings that I could access without having to go
into the ChucK code itself.  More for convenience/modularization/clean
code than anything else.  Thanks devs.  Know that you have a fan base.

I mentioned ISSUE mostly because it would be cool to give each
ChucKist a pair of overhead speakers, so that we could just use
internal sound cards if we wanted.  Anyway, I'll see what they have to
say about it, and maybe we could do a trial event (probably on a
Tuesday or something).

Andrew

On Sun, Aug 30, 2009 at 6:03 PM, mike clemow<gelfmuse at gmail.com> wrote:
> Kas,
>
>> Friendly hint; Prepare for a bit of disorientation after you played a bit
>> and resume talking, in my experience it's a good idea to think of a first
>> sentence to say after you stop playing right before you start.
>
> This is really good advice, thanks.  I hope I can pull it off.  I
> mean, it's hard enough trying to get things to work properly, but then
> it's kind of a strange thing to play for people when they have no idea
> what you're doing (or whether or not you're just there checking your
> email while your music plays ;-).  I think that this approach is more
> approachable when so much of what is happening is "under the hood."
>
>> ... Of what I've seen that code-base is one of the
>> most interesting structures build in ChucK so far (my own code for long-term
>> projects is very, very boring on a code level, I fear) so if I can vouch for
>> anything it must be that those in the NYC area would have a great chance of
>> seeing something very interesting at your performance.
>
> I can only hope that's true, Kas!  Thanks for the kind words.  The
> code-base has changed dramatically since you've seen it.  I think that
> the original way of doing what I was doing sacrificed so much
> performance in order to gain the programmatic control I needed, that
> it lent itself much easier to a non-realtime process in the end.  What
> I'm using now isn't quite as open-ended, but it much better suited for
> doing performance in realtime.  I got a lot of mileage out of using
> CurveTables as envelopes.  Dimitris and I were on about that not too
> long ago.
>
>> BTW, I hope you'll be writing on this list about those Spear files later as
>> well. Word on the (rather imaginary) street has it that people are pushing
>> for a official release to include the file IO. So far I only saw the design
>> on the Wiki and if I'd have to go by that alone I see no chance for even
>> parsing files in ChucK at all. File parsing should be exciting; if we can
>> parse Spears files we should be able to parse (and remix) .ck files, then
>> save and run them. For all it's pervesity (and quite likely because of it) I
>> find that idea very hard to resist indeed.
>
> I will definitely be putting that together soon.  You have every right
> to be totally underwhelmed by the file IO functions in CVS (at least,
> the version I'm using anyway)--they are very primitive.  I really wish
> that ChucK handled strings better, but you can get away with using a
> lot of Std.atof() and Std.atoi() functions, although I do wish that
> they could fail with NaN rather than default to 0.0 if you feed them
> something like "asdf12.97asdf."
>
> What we have to look forward to are some file IO objects with various
> read functions - readFloat(), readInt(), and readline() - a simple
> tokenizer that splits on white space, and a way to write files too.  I
> don't know if I would try to parse .ck files with them...  but it
> can't hurt to try!  It would be fun thing to mess around with.
>
> For some of my projects, I've been using OSC as a communication tool
> between ChucK programs and other running things.  Now I'm really
> excited about the prospect of using fifo pipe in Unix to communicate
> lots of information between ChucK and something else--a simple
> numbers-only protocol between Python and ChucK over a fifo pipe would
> give a ChucK program access to Python's string-parsing abilities...
>
> Anyway, the possibilities are endless and endlessly interesting.  I
> would love to see this functionality in the next release.  (I would
> love to see the next release!)
>
> -Mike
>
>
> 2009/8/29 Kassen <signal.automatique at gmail.com>:
>> Mike;
>>
>>> I'm planning on doing a
>>> quasi-participatory didactic thing with the audience to teach them
>>> about granular synthesis as I demonstrate the instruments I've built,
>>> so it's a little non-traditional as far as concert flow.
>>
>> The times when I saw Michel Waisvisz play he performed like that, gradually
>> shifting the focus from a talk to a concert. If done well it can solve a lot
>> of the problems with non-traditional performance methods. I tried it a few
>> times as well and while it's hard to come anywhere near Michel's level (I
>> consider him to have been one of the great minds and performers in the
>> history of electronic music) it's a underapreciated form.
>>
>> Friendly hint; Prepare for a bit of disorientation after you played a bit
>> and resume talking, in my experience it's a good idea to think of a first
>> sentence to say after you stop playing right before you start.
>>
>>>
>>> Even if you won't be in the area, you might want to take a look
>>> through my (spaghetti) code.  As Kassen can tell you, my attempts at
>>> doing granular synthesis in ChucK border on obsession and have spent a
>>> long time trying to squeeze out as much performance while keeping it
>>> as easy to program as possible.
>>
>> I like obsessions (well, healthy obsessions). As I experienced that code the
>> real obsession there isn't actually with the grains themselves but with your
>> perspective on- and your control over them, which is of course a far more
>> stimulating mental illness. Of what I've seen that code-base is one of the
>> most interesting structures build in ChucK so far (my own code for long-term
>> projects is very, very boring on a code level, I fear) so if I can vouch for
>> anything it must be that those in the NYC area would have a great chance of
>> seeing something very interesting at your performance.
>>
>>>
>>> There's a possibility that I'll document the show, so there might also
>>> be video at some point.
>>>
>> I hope you'll find the time and attention to do that; I know how hard it can
>> be to have to mind both your own performance and record at the same time. I
>> have of late been very bad at that.
>>
>> BTW, I hope you'll be writing on this list about those Spear files later as
>> well. Word on the (rather imaginary) street has it that people are pushing
>> for a official release to include the file IO. So far I only saw the design
>> on the Wiki and if I'd have to go by that alone I see no chance for even
>> parsing files in ChucK at all. File parsing should be exciting; if we can
>> parse Spears files we should be able to parse (and remix) .ck files, then
>> save and run them. For all it's pervesity (and quite likely because of it) I
>> find that idea very hard to resist indeed.
>>
>> Yours,
>> Kas.
>>
>> _______________________________________________
>> chuck-users mailing list
>> chuck-users at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>
>>
>
>
>
> --
> http://michaelclemow.com
> http://semiotech.org
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>


More information about the chuck-users mailing list