> 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.