[chuck-users] Blob (was; Physics Engine In Chuck)

Kassen signal.automatique at gmail.com
Tue Dec 16 16:02:38 EST 2008


I complete disagree with this idea. I have been using a fair bit of PD
> lately and it is very decentralized. It is very difficult to find patches
> and documentation. The PD-Extended is feature rich but is a real mess
> compared to Miller's vanilla version.

Ok, that's a good reason to disagree, yes. Already on the forum, earlier
today (or yesterday?) there was some confusion about why the interface
elements in Les's latest experiment didn't work. The answer was of course
that those only work on OSX. I agree that fragmentation is bad and should be
avoided as much as possible. Actually I feel that the relative uniformity of
ChucK installs is a advantage that CK has over SC, PD and other systems.

> ChucK needs some help but the answer is involvement. We have people who
> comment that parts are lacking. Great. What we need are people who will fix
> them. The source for everything is available and you can change it and send
> it back to the dev team. They have been great at merging patches that have
> been sent.

Well, yes in some cases but not in all. At the risk of repeating myself;
it's still not clear to me what's keeping up the ASIO patch. We know that
ASIO works well with ChucK, we also know newer versions of RTAudio can
include multiple ways of adressing the sound system, for example, yet people
with a need for low-latency performance on Windows depend on executables
hosted on the forum.

I'm not sure all patches would be suitable for merging into the main branch
either, at least not immediately, though perhaps experimental UGens could be
marked as such in the docs.

> What ChucK really needs is a chuck-users package that contains user
> generated UGENS and patches. GNU octave has a project called octave-forge
> that does this and it is very successful. There are some amazing users who
> have developed fantastic patches that have been kind enough to post their
> code for people. If we could put this all in one place then it would be easy
> to manage, update, and show to new users.
> The centralized, controlled nature of ChucK is one of the reasons that it
> is has been so successful. If you want to get involved a higher level,
> please do. As you point out, ChucK is great but we still have a lot of work
> to do until it becomes perfect. Let's build, not rebuild.

Actually, I think the "chuck-users" package that you propose would be
exactly what Steve and me are after here. I don't think anybody is after
"rebuilding", what would be nice would be a sort of "playground" to test
UGen ideas, ideas that might not be fully fledged or optimised yet. Of
course anybody could do this on his or her own but colaboration and feedback
would make it easier and likely more rewarding and fun as well. It sounds to
me like what you propose would meet those needs just as much as the original
idea would.

I'm not sure we disagree all that much, I share many of your concerns and I
do agree that the controlled nature of ChucK has helped keep things very
coherent and structured. I'm sticking to my point that I do feel there is a
lot that could be done that wouldn't need the personal involvement of the
DEV's yet that it's not completely clear how to do such things. I'm still
thinking that a structure (of some kind, I have no real preference) to
contribute such things could help streamlike that process. This would
ideally make it more clear how to help out as well as save time on the side
of the DEV's. This is why I have been trying to keep the WIKI list of bugs
up to date and have moved fixed bugs to sections labeld "fixed in version
x.y.z". At least that way there is some structure to it all.

That is what I meant with "decentralisation"; I think it's good if everybody
has access to the list of bugs that are open in one spot. This should help
baffled users as much as DEV's with a moment to spare (that ideally wouldn't
be spend hunting down posts on the list). By "decentralised" I didn't mean
"everybody going off on his own in random ways", what I'm looking for is a
structure, a structure beyond "a few people do all the work on their own".

I hope that clarifies.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20081216/54c88187/attachment.htm>

More information about the chuck-users mailing list