I think the part that I don't get about what you're saying is that you
seem convinced that create extensions (ckx) is a good idea, yet you
are worried about fracturing the development model. I'm suggesting
providing a place where we can build them into the actual program. I
would claim that creating ckx extensions is far more "fracturing",
like the Pd model.
I'm not a fan of plugins. I think including the kitchen sink is a
good way to go with this kind of program, because it gives you
something you can depend on. With two versions available, an
experimental version and a 'master' version, you can easily say, "this
program works with real ChucK", or "this program works with the
experimental version".
If you start throwing ckx files in there, it becomes much more
complicated. "This program works with real ChucK, with this and that
extension loaded, which you can go download from this guy's website",
etc. That's why I thought it would be prudent to create a community
edition that allows people to get their code in to a central location,
without putting any overhead on the ChucK team.
Using a central git repo, we can have branches for each feature people
want to integrate, and then just give a shout to the ChucK team
saying, "hey we did this, it's in branch X, grab the patch if you
want." The key thing being that there will be a "mob" branch that
anyone can submit patches to without having to ask for permission.
Steve
On Tue, Dec 16, 2008 at 7:44 PM, Adam Tindale
I think we are not actually that far apart, but I still think that fracturing the project in any way weakens it. Making it easier for users to go deeper and experiment with the guts sounds like a good idea. I suggest we proceed with caution.
You guys bring up a good point: Ge has created a monster. The state of the ASIO patch is not good. I think we need to apply pressure to the DEV team to get an explanation about this.
To create a playground is possible by downloading any release and messing with the source. In the past, people have created diffs, forwarded them to the DEV team, and they were then merged. Some people have become part of the DEV team and gotten access to the CVS, made their changes, did the commits themselves, and then that was it for their time as DEVs.
Here is what I would like to see ChucK-users or ChucK-forge to be: A collection of user .ck files. I think we could get it hosted at Princeton as well or we could open a sourceforge project.
I think you guys bring up a good point that it isn't quite enough at this point. Steve's work at compiling UGENS is great and now what we need is the proposed .ckx file which was supposed to be exactly this. Maybe this is something to revisit, it would help others and also make it so that Steve wouldn't have to appologize. The work was great, we should all build upon it.
If we cannot get a .ckx thing going then at that point I think it becomes necessary to create a ChucK thing where user generated UGENS are compiled in. I don't think we need to get there though. I think we investigate some of Kas' work on the wiki and look at the tracking and reporting structure that is not in place right now. The DEVs are busy. If we ask something from them we should give back, that is excatly why I started on the manual oh so many moons ago. We could help integrate a bug tracking system or organization software solution to address some of the problems we have noticed in ChucK's development.
Maybe this needs to be moved to the DEV list as we impliment solutions.
--art
________________________________ Visit messengerbuddies.ca to find out how you could win. Enter today. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users