Future ChucK: wish list items and one comment
Dear ChucKists, I look into my crystal ball and I see the future of ChucK, AKA my wish list: o MAUI ported to PC/Linux (on the way, woohoo!) o fix noteOff () problem o String Processing: preferably inspired by Perl o File I/O: I want to save and load program settings o printf (): formatted text/numeric output. o Hierarchical Events: i.e. event when any button in an array is pressed o MAUI Expansion: Text I/O, File Browser, 2D drawing, 3D drawing, etc. o Garbage Collection o Tube Amplifier UGen o Piano STK Instrument And there is one observation I'd like to share... Aside from it's musical capabilities, the one outstanding feature of ChucK to me is the way that everything works together. ChucK is very Apple/Linux-like in the way that it seems to be so well thought out. Of the dozen or two languages I've played with over the years, ChucK has got to be the most fun and the easiest to code because stuff just plain works. So my hat's off to the dev ChucKists, us user ChucKists are having a blast with your hard work! Inventor p.s. I went retro on the Pong game with the square ball as I remember from our Pong unit we had as kids, though I agree the LED would be way cooler. Maybe make it blink all three colors...
Greetings Inventor and all! Just a quick note of things on the way, some of which is in progress now, others to happen largely this summer:
I look into my crystal ball and I see the future of ChucK, AKA my wish list:
I like what your crystal ball shows, for it is almost completely in line with our current TODO list...
o MAUI ported to PC/Linux (on the way, woohoo!)
woohoo, indeed!
o fix noteOff () problem
Hopefully by summer!
o String Processing: preferably inspired by Perl o Garbage Collection
I see these things going together. Hopefully by end of summer!
o File I/O: I want to save and load program settings o printf (): formatted text/numeric output.
Andrew Schran, Rebecca, and I are working on this, building on existing work by Martin Robinson and others. ETA: end of summer?
o Hierarchical Events: i.e. event when any button in an array is pressed
This is an often requested feature, we still need assess a few things before going forth on it. Huh, I said "assess"...
o MAUI Expansion: Text I/O, File Browser, 2D drawing, 3D drawing, etc.
There are actually even more encompassing, MAUI-friendly, plans for a cross-platform 2D/3D graphics/OpenGL ChucKian API in general, which would include among other things a 3D-accelerated UI programming interface. Probably not this summer though.
o Tube Amplifier UGen o Piano STK Instrument
No plans for these yet, but hopefully with the to-be-improved UGen/UAna import system, it'd be easier to add chuck-ins! Also, there is a prototype fluidsynth UGen in development (by Kyle Super) that loads and plays soundfonts. One of the reasons that things are going slowly: while we love rapid development/releases when it's appropriate, we also believe that it's important to make sure certain things (particularly new API and syntax/semantics) work as elegantly as we can make them and can support extensions down the line. As for the lack of developer documentation, this is indeed a huge gap we need to address. We'll priority boost that, hopefully an early summer project.
And there is one observation I'd like to share... Aside from it's musical capabilities, the one outstanding feature of ChucK to me is the way that everything works together. ChucK is very Apple/Linux-like in the way that it seems to be so well thought out. Of the dozen or two languages I've played with over the years, ChucK has got to be the most fun and the easiest to code because stuff just plain works. So my hat's off to the dev ChucKists, us user ChucKists are having a blast with your hard work!
Wow, thanks! This means a super great deal to us. We'll keep on ChucKin', and are stoked you are doing the same! For those about to ChucK... we salute you! Ge! PS: MAUI pong is ridiculously sweet... this, along with Perry's recent MAUI-based octave-band spectrum analyzer (which we'll hopefully witness soon!), deserve awards for The Most Unholy/Unexpected/Clever Use of ChucKian Technology of the Month.
(switching between quoting Ge&Inventor as suitable)
o MAUI ported to PC/Linux (on the way, woohoo!)
woohoo, indeed!
Yes! Maybe I'm looking forward to this more then GLucK... but I'm a 2d gamer more then a 3d one. I'd really like sprites... erm, I mean importing images with the option of animating/swapping them.
o String Processing: preferably inspired by Perl
Perl's power yes... but please, please not Perl's typical "stuff everything in one line that looks like you opened a image in a text editor" style. I know there are Perl programmers that write very readable code but the percentage of "sytax terror" that you sometimes see is unusually high in Perl.
o Garbage Collection
I see these things going together. Hopefully by end of summer!
Yes, agreed. Also the lack of garbage collection is making recursive structures a "play with fire" thing while I think recursive structures are a natural fit for some musical structures. Right now function calls (often?) leak memory.
Andrew Schran, Rebecca, and I are working on this, building on existing work by Martin Robinson and others. ETA: end of summer?
If people would look at the WiKi (currently only accessible under "recent changes"?) they'd see the design plan for this that Andrew is working on and where Andrew has been asking for comments. It would probably be good if people with strong feelings on this subject would share their ideas on the talk page there.
This is an often requested feature, we still need assess a few things before going forth on it. Huh, I said "assess"...
And you said "forth"! :¬p
o Tube Amplifier UGen o Piano STK Instrument
No plans for these yet, but hopefully with the to-be-improved UGen/UAna import system, it'd be easier to add chuck-ins! Also, there is a prototype fluidsynth UGen in development (by Kyle Super) that loads and plays soundfonts.
The range of Ugens we could use is virtually endless, I for one would be interested in ports of Fredrick Olafson's game-console-chip inspired designs for SC (I'm sure everybody else has a wish-list as well). I'm starting to think the only long-term way out here is a SDK, a standard and having users cook stuff up, followed by a quality control process and merging into the main executable. Aside from making the SDK nearly all of that could be distributed amongst users. One of the reasons that things are going slowly: while we love rapid
development/releases when it's appropriate, we also believe that it's important to make sure certain things (particularly new API and syntax/semantics) work as elegantly as we can make them and can support extensions down the line. As for the lack of developer documentation, this is indeed a huge gap we need to address. We'll priority boost that, hopefully an early summer project.
I fully agree. As I see it ChucK is mainly a syntax and that's the bit we should guard.
And there is one observation I'd like to share... Aside from it's
musical capabilities, the one outstanding feature of ChucK to me is the way that everything works together. ChucK is very Apple/Linux-like in the way that it seems to be so well thought out. Of the dozen or two languages I've played with over the years, ChucK has got to be the most fun and the easiest to code because stuff just plain works. So my hat's off to the dev ChucKists, us user ChucKists are having a blast with your hard work!
Yes, I can't say this enough. It's a beautiful experience to be a part of this, to get all of these amazing toys, then have the chance to mail the dev's directly if there's a issue or question.... or even collaborate with other users in pinpointing vague issues. Three cheers for everybody! Kas.
Kassen wrote:
Perl's power yes... but please, please not Perl's typical "stuff everything in one line that looks like you opened a image in a text editor" style.
1 vote for python. String processing (as everything else) is super-nice in python. atte@ajstrup:~$ python Python 2.5.1 (r251:54863, Mar 7 2008, 04:10:12) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
ChucK = "good" ChucK[:-2] 'go' ChucK[-1:] 'd' ChucK[:-2].capitalize() + ChucK[-1:] 'God'
-- peace, love & harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://modlys.dk
Ge Wang wrote:
Greetings Inventor and all!
Just a quick note of things on the way, some of which is in progress now, others to happen largely this summer:
I look into my crystal ball and I see the future of ChucK, AKA my wish list:
I like what your crystal ball shows, for it is almost completely in line with our current TODO list...
o MAUI ported to PC/Linux (on the way, woohoo!)
woohoo, indeed!
o fix noteOff () problem
Hopefully by summer!
o String Processing: preferably inspired by Perl o Garbage Collection
I see these things going together. Hopefully by end of summer!
o File I/O: I want to save and load program settings o printf (): formatted text/numeric output.
Andrew Schran, Rebecca, and I are working on this, building on existing work by Martin Robinson and others. ETA: end of summer?
o Hierarchical Events: i.e. event when any button in an array is pressed
This is an often requested feature, we still need assess a few things before going forth on it. Huh, I said "assess"...
o MAUI Expansion: Text I/O, File Browser, 2D drawing, 3D drawing, etc.
There are actually even more encompassing, MAUI-friendly, plans for a cross-platform 2D/3D graphics/OpenGL ChucKian API in general, which would include among other things a 3D-accelerated UI programming interface. Probably not this summer though.
o Tube Amplifier UGen o Piano STK Instrument
No plans for these yet, but hopefully with the to-be-improved UGen/UAna import system, it'd be easier to add chuck-ins! Also, there is a prototype fluidsynth UGen in development (by Kyle Super) that loads and plays soundfonts.
One of the reasons that things are going slowly: while we love rapid development/releases when it's appropriate, we also believe that it's important to make sure certain things (particularly new API and syntax/semantics) work as elegantly as we can make them and can support extensions down the line. As for the lack of developer documentation, this is indeed a huge gap we need to address. We'll priority boost that, hopefully an early summer project.
And there is one observation I'd like to share... Aside from it's musical capabilities, the one outstanding feature of ChucK to me is the way that everything works together. ChucK is very Apple/Linux-like in the way that it seems to be so well thought out. Of the dozen or two languages I've played with over the years, ChucK has got to be the most fun and the easiest to code because stuff just plain works. So my hat's off to the dev ChucKists, us user ChucKists are having a blast with your hard work!
Wow, thanks! This means a super great deal to us. We'll keep on ChucKin', and are stoked you are doing the same!
For those about to ChucK... we salute you! Ge!
PS: MAUI pong is ridiculously sweet... this, along with Perry's recent MAUI-based octave-band spectrum analyzer (which we'll hopefully witness soon!), deserve awards for The Most Unholy/Unexpected/Clever Use of ChucKian Technology of the Month.
Hello Ge, What do you think about others contributing to the development process? The user community doesn't have a good way to maintain patches or other contributions. Some examples for instance are posted to the wiki, some as attachments to the forum. I for one really need 64-bit on linux working, but I am hesitant to contribute because I don't know what the process is. Perhaps we need 1) read-only revision control system access so that we can generate patches, 2) an issue tracking system of some sort to submit patches to, and 3) a sourceforge or similar project for chuck users to maintain other contributions (examples, Objects, UGens, etc.) Regards, michael
Hi Michael!
What do you think about others contributing to the development process? The user community doesn't have a good way to maintain patches or other contributions. Some examples for instance are posted to the wiki, some as attachments to the forum.
Yes, for totally.
I for one really need 64-bit on linux working, but I am hesitant to contribute because I don't know what the process is.
Indeed, we need to be much better at making the process more clear.
Perhaps we need 1) read-only revision control system access so that we can generate patches,
This is already there, but poorly publicized. This is one of the things we hope to improve in this summer big round of ChucKian (anti)progress. Also, we hope to move from CVS to SVN at some point. In the meantime: https://lists.cs.princeton.edu/pipermail/chuck-users/2005-October/000091.htm...
2) an issue tracking system of some sort to submit patches to, and 3) a sourceforge or similar project for chuck users to maintain other contributions (examples, Objects, UGens, etc.)
We have this, but I don't it's linked from anywhere sensible! http://chuck.sf.net/ We very hear you, and completely agree. This is a priority and we hope to get things into shape as soon as we have time to bootstrap it, and hopefully build it together. Thanks all! Best, Ge!
2) an issue tracking system of some sort to submit patches to, and 3) a sourceforge or similar project for chuck users to maintain other contributions (examples, Objects, UGens, etc.)
We have this, but I don't it's linked from anywhere sensible!
We very hear you, and completely agree. This is a priority and we hope to get things into shape as soon as we have time to bootstrap it, and hopefully build it together.
Gnu Octave has a separate package called octave-forge where user additions are kept. Maybe this is a model we could use to amalgamate all the useful user code out there. --art
Adam Tindale wrote:
Ge Wang wrote:
2) an issue tracking system of some sort to submit patches to, and 3) a sourceforge or similar project for chuck users to maintain other contributions (examples, Objects, UGens, etc.)
We have this, but I don't it's linked from anywhere sensible!
Sweet!
Gnu Octave has a separate package called octave-forge where user additions are kept. Maybe this is a model we could use to amalgamate all the useful user code out there.
--art
Appears that any of chuck-forge, chuck-users, chuck-contrib etc. for project names at sourceforge are available. Now only if we had namespaces and imports so that we might organize all the contributed code! ;) michael
Hi Ge,
I'm so glad to hear you are interested in contributed code. I was
really wondering what was going on with the chuck project since there
seemed to be very sparse, large updates. I'm really happy to see it
progress, it's really a fun program, and I'd really love to see a
community form around it. (which of course has already happened, but
it should continue to grow)
On Tue, Apr 1, 2008 at 1:32 PM, Ge Wang
This is already there, but poorly publicized. This is one of the things we hope to improve in this summer big round of ChucKian (anti)progress. Also, we hope to move from CVS to SVN at some point. In the meantime:
https://lists.cs.princeton.edu/pipermail/chuck-users/2005-October/000091.htm...
I'm currently using the CVS repo to follow development, though I
haven't had time yet to make any nice contributions.
However, if you're thinking of switching version control systems at
some point I have to highly recommend skipping SVN and going to Git.
It makes dealing with contributed code so much easier, you wouldn't
believe. It automates merging and applying patches, and meanwhile
allows people to follow other people's branches, all without requiring
you to give random people write access to the repository.
I won't bug about it after this, but I really feel it has to be
mentioned at least once.. I started playing with Git a few months back
and now I use it all the time and can hardly imagine going back to a
non-distributed source control system. For what it's worth I imported
the CVS into git and it compressed the entire history of Chuck down to
6.8 M. That makes it totally trivial for transport around the
internet with a distributed development model. Meanwhile you get to
keep complete control of the "official" repository.
You can clone it here if you want to try it out:
git-clone http://www.music.mcgill.ca/~sinclair/git/chuck_dev.git
(not for general consumption! this would need to be retro-actively
cleaned up with better author info and such before being useful.)
On Tue, Apr 1, 2008 at 3:02 PM, Michael Heuer
Now only if we had namespaces and imports so that we might organize all the contributed code! ;)
On this subject, I think it needs to be considered how contrib would be organized. The Pd project originally organized their code according to contributor. This is a symptom of using CVS to give different permissions for each subfolder. There is currently a bit of a disagreement in the Pd community about whether things should be organized according to author or according to usage. The latter makes a lot more sense (imho) and makes it a lot easier to find things. I'm personally a fan of eventually integrating contributed code into the main project so that it's all accessible instead of drawing lines in the sand. Anyways, just some ideas, and getting a way to contribute UGen's and such into the main code would be great! cheers, Steve
participants (7)
-
Adam Tindale -
Atte André Jensen -
Ge Wang -
Inventor-66＠comcast.net -
Kassen -
Michael Heuer -
Stephen Sinclair