I know that Chuck was intentionally designed as a live-coding language, however, I think that a really cool feature would be file IO. My main reason for thinking this is my absolute fascination with the growing field of data-sonification. Work by Andrea Polli, who has taking large data sets from hurricanes and turned them into sound, as well as others who have done the same with other data sources, like EEG readings, & c. is a really interesting possibility with something as easy and intuitive to code as Chuck. The state of IO in Chuck right now is severely limited when it comes to doing something like this. There's keyboard in, MIDI, HID, and OSC. While those are fantastic, if I have a database full of information that I want to Chuck into Chuck, I'm stuck coding it up in another language and sending data to Chuck as one of the above. I can't even communicate with Chuck via stdin, AFAIK. At the very least, I'd love to see Chuck be able to read a file and have some string functionality available so that I could write some functions to parse things like CSV files so that I could get my data into Chuck and turn it into a soundscape. That plus a decent print function to stdout, stderr, and reading from stdin would really be helpful... to me at least. What do the rest of you think? Mike On 8/15/07, Kassen wrote:

I just wanted to bump this and offer my small and humble opinion;

To me it's a sort of utopia to have this amount of open-ness about the process of ChucK's development. It's therefore quite odd to me that there isn't more debate on the sugested features and that only a very small group of people has added desirered features and there is hardly any discussion at all about which ideas are good and which ones are silly/redundant/dangerous.

Why isn't there more debate?

Kas.

On 8/8/07, Ge Wang wrote:

...

Greetings!

We are nearing the next very sporktacular release of ChucK and want to coordinate with you on organizing and prioritizing some bug fixes/ features/updates. We've been scouring through the forums, wiki pages, and posts and collected much good info. Thanks to all who have been kind and patient enough to enter requests, reports, and suggestions into the various pages. At this stage, we'd like to get your input on prioritizing them for the new release (in about 2 weeks). For this purpose, we've created two new wiki pages for feature requests/reports and bug reports/requests from here:

http://wiki.cs.princeton.edu/index.php/ChucK/Bugs

http://wiki.cs.princeton.edu/index.php/ChucK/Features

...

Please enter full descriptions and concise accompanying code when helpful. While we can't guarantee that these would make it into the immediate next version, they are very helpful in getting a sense of disaster zones that needs more urgent attention, and is a chance to tidy up the information. If you don't want to deal with the wiki directly, feel free to post here or to chuck-dev, and our uh wiki specialists will transfer the text there.

As for the manual, let's keep going here:

http://wiki.cs.princeton.edu/index.php/ChucK/Manual

Thank you very much! Let us know if you have any questions.

Keep on ChucKin'

Best, chuck team _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu

https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

...

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://shadowofaculture.blogspot.com

you are right, there should be more discussion. my top priorities are: Include statement. Would make it easier to reuse code. this is not in the Prioritized Wish List for Next Release, but i think the java-esque auto dependency finding system mentioned there might be even better. for me this is extremely important. better string support. a dynamic structure like lists in Python for example. arrays are not enough. let miniAudicle search for audio-files relative to the path of the ck-file. now it is extremely annoying that miniAudicle doesn't find audio files that are in the same directory as the ck-file. you have to use absolute paths or the miniAudicle preferences. both is not really an option if you receive sixty projects by students each with audio files and ck-files... best joerg Kassen schrieb:

I just wanted to bump this and offer my small and humble opinion;

To me it's a sort of utopia to have this amount of open-ness about the process of ChucK's development. It's therefore quite odd to me that there isn't more debate on the sugested features and that only a very small group of people has added desirered features and there is hardly any discussion at all about which ideas are good and which ones are silly/redundant/dangerous.

Why isn't there more debate?

Kas.

On 8/8/07, *Ge Wang* mailto:gewang@cs.princeton.edu> wrote:

Greetings!

We are nearing the next very sporktacular release of ChucK and want to coordinate with you on organizing and prioritizing some bug fixes/ features/updates. We've been scouring through the forums, wiki pages, and posts and collected much good info. Thanks to all who have been kind and patient enough to enter requests, reports, and suggestions into the various pages. At this stage, we'd like to get your input on prioritizing them for the new release (in about 2 weeks). For this purpose, we've created two new wiki pages for feature requests/reports and bug reports/requests from here:

http://wiki.cs.princeton.edu/index.php/ChucK/Bugs http://wiki.cs.princeton.edu/index.php/ChucK/Features http://wiki.cs.princeton.edu/index.php/ChucK/Features

Please enter full descriptions and concise accompanying code when helpful. While we can't guarantee that these would make it into the immediate next version, they are very helpful in getting a sense of disaster zones that needs more urgent attention, and is a chance to tidy up the information. If you don't want to deal with the wiki directly, feel free to post here or to chuck-dev, and our uh wiki specialists will transfer the text there.

As for the manual, let's keep going here:

http://wiki.cs.princeton.edu/index.php/ChucK/Manual

Thank you very much! Let us know if you have any questions.

Keep on ChucKin'

Best, chuck team _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu mailto:chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

------------------------------------------------------------------------

_______________________________________________ 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 8/15/07, joerg piringer wrote:

you are right, there should be more discussion.

Cool. For a moment I feared ChucK-users didn't have wishes and opinions, that would be so abnormal as to almost seem like a psychological illness :¬). my top priorities are:

Include statement. Would make it easier to reuse code. this is not in the Prioritized Wish List for Next Release, but i think the java-esque auto dependency finding system mentioned there might be even better. for me this is extremely important.

My own is ASIO but ASIO would apear to have been covered with a perfectly fine test-build. I agree a include statement/dependency finding should be at the top. This will not only open the way for easier management of larger projects but it will also allow for easy sharing of tools and extentions which would be good for community building. Practically speaking it would lower the treshold for contributing to ChucK from knowing C++ to knowing ChucK which I think is a big deal. better string support.

a dynamic structure like lists in Python for example. arrays are not enough.

Agreed, both are needed. I don't think I personally ran into situations where I urgently needed either yet but especially lists would be great for ChucK as a introductory language. I also think compositions may be like arrays in a way but composing as a process is more akin to operations on lists. let miniAudicle search for audio-files relative to the path of the

ck-file. now it is extremely annoying that miniAudicle doesn't find audio files that are in the same directory as the ck-file. you have to use absolute paths or the miniAudicle preferences. both is not really an option if you receive sixty projects by students each with audio files and ck-files...

Good point. I don't have sixty students but I do have a sequencer that has a directory for drum-samples for each track, needs locations for files to Machine.add() and a few modified copies of that whole structure as backup when testing new ideas. This gets anoying and confusing (especially between the versions) which is a shame as the Mini is so nice. Aside from those the thing that I realy lust after is graphical hooks from the Mini to ChucK --shell's interface to update just some part of a running file while it runs or inject new code while it runs. I'm not sure wether that is purely a Mini issue or also a ChucK one as the functionality is there but it's interface in comandline ChucK was in such a state that I couldn't tell for sure wether it worked properly last time I tried. I'm not sure how many people have a urgent desire for this right now but I think it would be spectacularly good for both live-coding and rapid-prototyping. Kas.

To me, it seems like the most important thing is to add more preset instruments and make it easier to create your own instruments. At the moment, we have a pretty broad set of instruments, but it could certainly be expanded. Also, the interfaces to them are not entirely standardized. The concept of an instrument could be abstracted more within chuck, which would be an asset to the programmer. Just my 2 cents, Chris On 8/15/07, joerg piringer wrote:

Kassen schrieb:

...

I agree a include statement/dependency finding should be at the top. This will not only open the way for easier management of larger projects but it will also allow for easy sharing of tools and extentions which would be good for community building. Practically speaking it would lower the treshold for contributing to ChucK from knowing C++ to knowing ChucK which I think is a big deal.

and ah yes! i forgot a very important issue: EXTERNALS! i have a couple of ideas that could be easily implemented with external dlls or dynamic libraries. like for example text to speech (flite) or an openGL display.

best joerg

-- http://joerg.piringer.net http://www.transacoustic-research.com http://www.iftaf.org http://www.vegetableorchestra.org/ _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

I would disagree with that reasoning. Sure it's produced by academics, but this is the USERS list. And it is fundamentally a practical tool, not an academic exercise as you suggest. The fact that we are discussing it on this list means that usability is a serious concern. Although I might not disagree with the conclusion, the language itself certainly can and should be improved. I would say that standardizing the Ugen / Instrument interfaces should be high on this list. -- Chris On 8/16/07, mike clemow wrote:

I totally agree that there should be some more effort put toward allowing users to create more Ugens, however, I think that because Chuck is also an academic exercise for the Princeton folks, adding features to the language itself is a higher priority than adding more instruments, IMHO.

Mike

...

To me, it seems like the most important thing is to add more preset instruments and make it easier to create your own instruments. At the moment, we have a pretty broad set of instruments, but it could certainly be expanded. Also, the interfaces to them are not entirely standardized. The concept of an instrument could be abstracted more within chuck, which would be an asset to the programmer.

Just my 2 cents, Chris

On 8/15/07, joerg piringer wrote:

...

Kassen schrieb:

...

I agree a include statement/dependency finding should be at the top. This will not only open the way for easier management of larger

On 8/16/07, chris beck wrote: projects

...

...

...

but it will also allow for easy sharing of tools and extentions which would be good for community building. Practically speaking it would lower the treshold for contributing to ChucK from knowing C++ to knowing ChucK which I think is a big deal.

and ah yes! i forgot a very important issue: EXTERNALS! i have a couple of ideas that could be easily implemented with external dlls or dynamic libraries. like for example text to speech (flite) or an openGL display.

best joerg

-- http://joerg.piringer.net http://www.transacoustic-research.com http://www.iftaf.org http://www.vegetableorchestra.org/ _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu

https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

...

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://shadowofaculture.blogspot.com _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

I believe that extending and improving the language will surely help here though: Specifically, when users can create their own UGens, I imagine you'll see quite a few new instruments being developed. Of course, it would be good to make sure the UGen API is standardized, so that UGen developers can create their instruments in a manner consistent with what already exists in ChucK, and currently existing anomalies could be eradicated as a part of that process. Oh and there are a lot of programmers who aren't academics. Extending the language itself should be of interest to everyone who programs with ChucK (and remember: even if you don't need a feature now, you might need it in the future, as your understanding of the language grows!) ~David On 8/22/07, chris beck wrote:

I would disagree with that reasoning. Sure it's produced by academics, but this is the USERS list. And it is fundamentally a practical tool, not an academic exercise as you suggest. The fact that we are discussing it on this list means that usability is a serious concern.

Although I might not disagree with the conclusion, the language itself certainly can and should be improved. I would say that standardizing the Ugen / Instrument interfaces should be high on this list.

-- Chris

Kassen wrote:

I just wanted to bump this and offer my small and humble opinion;

To me it's a sort of utopia to have this amount of open-ness about the process of ChucK's development. It's therefore quite odd to me that there isn't more debate on the sugested features and that only a very small group of people has added desirered features and there is hardly any discussion at all about which ideas are good and which ones are silly/redundant/dangerous.

Why isn't there more debate?

I haven't spent a lot of time with ChucK yet, so I don't have a lot of ideas myself. Since ChucK is intended for music programming on the fly, I'd expect the real "user base" to be working computational musicians that are jamming with ChucK, not dry "language theorists", etc. As I understand it, ChucK programming is a performing art, and like the other performing arts, the real feedback that matters is that between the performer and the audience. I haven't been through the documents recently, but coming from a non-real-time performance background, my own impressions of ChucK probably don't mean much. But for "people like me" (studio musicians rather than live performers), what I would want from ChucK would be documentation, tools, and even some encouragement that would help me transition *out* of "studio mode" and into a live performance mode of some kind. I couldn't make this year's course on live performance, but it's certainly on my list for next year. And, of course, there's "Dorkbot" :) (http://groups.google.com/group/dorkbotpdx-blabber).

On 8/29/07, Martin Ahnelöv wrote:

You should be able to $ chuck + foo bar - 1 2 3 = 4 foobar. Nuff said.

Could you perhaps still say a little more? I don't understand this at all, I fear. On the same topic, you should be able to $ chuck -3, because it's a pain

in the ass to forgett the space =)

Hmmmmmm. Not so sure, because "-3" is also a number. Also, $ chuck foobar.ck shouldn't break a VM. You are quite right, any time that can happen that's a serious bug. Now, more language wise:

a .cycledur on (at least) the oscillators. Sometimes you just want to tell the machine how long time a lfo's cycle should be, instead of having to do hard calculating =)

We have this already :-). What we need is better documentation on it. It's called ".period()" for the oscilators and the type is duration. It was new in 1.2.0.7 and got mentioned in the "wat's new?" file but the manual hasn't caught up yet. I like this one, it's a very logical extention to ChucK's emphasis on time and timing. And a dur => blackhole; would be neat, too. Ie, you forward the shred

dur samples in time. That's isn't too processor-intense to calculate, right?

Could you give a example of what this would do? How would this be different from "dur => now;"? Yours, Kas.

On 8/29/07, Martin Ahnelöv wrote:

ons 2007-08-29 klockan 18:40 +0200 skrev Kassen:

...

On 8/29/07, Martin Ahnelöv wrote:

You should be able to $ chuck + foo bar - 1 2 3 = 4 foobar. Nuff said.

Could you perhaps still say a little more? I don't understand this at all, I fear.

I mean that I would like to add teo new shreds, remove 3, and replace one with another file in the same go, to get the "emotial effect" that I I'm seeking. It could be used to change from verse to refrain in a popsong, for example.

Yes, I see now. I was completely confused, I had asumed the dollar sign meant you wanted to cast a variable called "chuck" to.... and there I lost track. My oops. I agree that more versatility there would help a lot, particularly where the MiniAudicle is concerned and a graphical interface could make it all even easier. One thing I'd like is the ability to update some code, then replace all shreds that came from that window/file in one swoop instead of just one. Sure, but chuck have never accepted any numbers of any kind at the

command-line.

Yes, my oops. I had somehow asumed that you wanted to substract 3 from some value named "chuck". I apologise and blame a lack of coffee. Vool! That's also something I would like to see: documentation on all

features in the language!

Yes, we would all like this, I think. At least we have a WiKi page where everybody can post additions, remarks and requests which should at least decrease the strain on maintaining the manual. I believe Adam Tindale was the last to be semi-officially in charge of the manual but other things took his time. I'd volunteer but I'd need a proofreader as I'm not a native English speaker and I still don't speak any Latex at all (the manual is done in Latex) At least most things can be found by searching the list archives and the manual isn't *that* out of date. Aside from the latest greatest stuff this matter might be one of the worst missing bits.

dur => blackhole would be exactly like SinOsc => blackhole, but with time. When you, for example, chuck second into blackhole, the shred will forward 1 second in it's own timeline (A bit like the -s otion, if I recall).

I'm still not sure exactly how this would be different. What would happen to playing Ugens that would be in the shred? Would those keep computing? Example:

It could be used for plotting numbers over time. If you had two envelopes that ascending from 10 and 15 up to 88 and 100, you could add their value()s to their respective array of floats, round() the floats to ints. Then, in a for loop, you have the computer play a random midi-note between min[i] and max[i]. Congratulations! You got a solo-playing computer! (Sure, I realise that you could do this very task in other ways...)

Yes, chucking time to now would do here, I think. Maybe you could compare how this would be done now to what you propose in some chuck code and some pseudo-code? Kas.

On 8/31/07, Martin Ahnelöv wrote:

ons 2007-08-29 klockan 23:11 +0200 skrev Kassen:

...

dur => blackhole would be exactly like SinOsc => blackhole, but with time. When you, for example, chuck second into blackhole, the shred will forward 1 second in it's own timeline (A bit like the -s otion, if I recall).

I'm still not sure exactly how this would be different. What would happen to playing Ugens that would be in the shred? Would those keep computing?

The thing is... Hm, if we have something like this:

SinOsc 1 => dac;

while (true) { 100::ms => now; 3::samp => blackhole; }

The shred would jump 3 samples forward every 100 ms. If you change the duration to 10::ms, you might get some glitching going on every 100::ms.

Ok, I get it now, you'd like to jump into the future... That should be possible but I think it will often lead to a big strain on the cpu. For simple oscilators or a envelope it could be quite easy but if the shred involves -say- three oscilators in a fm feedback loop there would be no way around calculating all the samples inbetween to know what value the final one is at after the time we skip.. It's a interesting idea but I'm not sure the benefits outweigh the dangers and problems. At least you could record your sounds like that, for example recording them to a LiSa and turning record off at a certain point, advancing time, then resuming recording at the spot where you left off. Kas.