Blob (was; Physics Engine In Chuck)

newer
ChucK fails to compile on GCC...

older
Seasonal greetings

Kassen

15 Dec 2008 15 Dec '08

10:41 a.m.

Steve; Yeah sorry I haven't had time to mess with this more lately.

...

Maybe I'll get back into it throughout the christmas break. I'm a little wary of doing it without discussion with the official chuck devs, maybe we should discuss the idea more on chuck-dev@.

I agree. IMHO the core of what ChucK's development will need in the future is de-centralisation and communication. To me it's clear that we have people around that can write a decent UGen or two and we have plenty of people who can test such things. If some people verify a certain new UGen works, is stable, useful and relatively efficient I feel it should need no more then a glance of one of the main DEV's to be included in the main build. There will be bugs anyway and we'll find them, no big deal. If we had a shortage of people willing to risk their computer and sanity on untested ideas we wouldn't be here :¬). The same goes for the manual,etc. I'm no project leader, I have next to no experience with this type of process so take my words with a few lumps of salt. It's my impression that our main DEV's are highly tallented people and that becuase of this their time is in great demand. I suspect comunication is becoming a bottle-neck and that with a properly organised de-centralised structure we could get more done. There is a lot of stuff that could be done that wouldn't need somebody like Ge personally, at least not beyond the occasional check for coherency. We do need quality control but quallity control is the one thing we've proven to be very good at de-centralising. We've got more senior users that will work together to hunt down more complicated issues and we've got a steady influx of enthousiastic new users that have turned out to be great at pointing out some things are under-documented. IMHO, Kas.

Attachments:

attachment.html (text/html — 2.1 KB)

Show replies by date

Adam Tindale

16 Dec 16 Dec

3:11 p.m.

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

Stephen Sinclair

3:49 p.m.

On Tue, Dec 16, 2008 at 3:11 PM, Adam Tindale wrote:

...

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.

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.

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.

I'm not sure I'm clear on the difference between a "chuck-users" package, as you mention, and what Kassen is talking about, regarding a community edition? Just to clarify, I think you have misunderstood the idea. The fact that ChucK uses a central CVS server means that it's impossible for people to work together to create patches that can then be submitted to the main ChucK team. The idea was to create a place where we could integrate and test works-in-progress without needing to get access to ChucK's CVS. However it has always been a goal with this idea to make sure that all developments are based on ChucK's upstream, so that the ChucK team could then easily apply them. The community edition would forever be considered "unstable", and we wouldn't encourage people to use it for real work. In any case, if a "chuck-users" approach is preferred, where would you suggest that be developed? Anyways, if you think about it, the only actual difference between creating a "community edition", and everyone just making their own git repos and sharing patches on the list, is that the former case has a web page to describe how to do it. Steve

Kassen

4:45 p.m.

Steve;

...

Just to clarify, I think you have misunderstood the idea. The fact that ChucK uses a central CVS server means that it's impossible for people to work together to create patches that can then be submitted to the main ChucK team.

I think that may have been partially due to me not being sufficiently clear about what I meant by "decentralisation". I meant a certain type of organisation, not complete chaos. Right now, IMHO, too many questions and issues have no answer beyond "email Ge". Now; it's always very nice to correspond with Ge but aside from ChucK Ge has students, SLORK, he has Smule and there are only 24::hour in 1::day. We could do a lot ourselves. I suspect some things that could be done simply don't get done because there is no clear way of doing them. Also; it's just plain fun to build things with others. Yours, Kas.

Adam Tindale

7:44 p.m.

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 _________________________________________________________________

Stephen Sinclair

8:15 p.m.

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 wrote:

...

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

Kassen

9:07 p.m.

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

I see your point but wouldn't a "include" feature risk the same? I think we all agree that inclusions would be extremely useful for managing larger ChucK projects and I think we agree it would be a waste of time for me to re-write something you already created. So; I'd point to your site or re-distribute your code (assuming it would allow for that), packing it all up in a archive file. I'm not sure I'd have a real problem with plugins, assuming we could have cross-platform ones. Popular/stable/useful ones could be distributed with ChucK or even merged into it. These are hard questions but right now I feel that a central repository of "useful things to be shared" will be unavoidable and indeed a useful and probably fun thing to have in the future. For UGens in the current situation I still think a "experimental" and a "stable" version is the most practical idea on the table so far. Yours, Kas.

Tom Lieber

11:34 p.m.

On Tue, Dec 16, 2008 at 3:49 PM, Stephen Sinclair wrote:

...

Anyways, if you think about it, the only actual difference between creating a "community edition", and everyone just making their own git repos and sharing patches on the list, is that the former case has a web page to describe how to do it.

On Tue, Dec 16, 2008 at 8:15 PM, Stephen Sinclair wrote:

...

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.

srsly. and with github, you also get the web page. and on the 'network' page you can see everybody's branches. http://github.com/AllTom/chuck/tree/1.2.1.2 Someone should do it! -- Tom Lieber http://AllTom.com/

Stephen Sinclair

11:44 p.m.

On Tue, Dec 16, 2008 at 11:34 PM, Tom Lieber wrote:

...

On Tue, Dec 16, 2008 at 3:49 PM, Stephen Sinclair wrote:

...
Anyways, if you think about it, the only actual difference between creating a "community edition", and everyone just making their own git repos and sharing patches on the list, is that the former case has a web page to describe how to do it.

On Tue, Dec 16, 2008 at 8:15 PM, Stephen Sinclair wrote:

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

srsly. and with github, you also get the web page. and on the 'network' page you can see everybody's branches.

http://github.com/AllTom/chuck/tree/1.2.1.2

Someone should do it!

Oh cool I guess it's done then. :) I was thinking of maintain a branch called "upstream" that is always synced against the CVS. As far as I know github doesn't support "mob", that's why I was thinking of using git.or.cz. Steve

Tom Lieber

17 Dec 17 Dec

12:26 a.m.

On Tue, Dec 16, 2008 at 11:44 PM, Stephen Sinclair wrote:

...

On Tue, Dec 16, 2008 at 11:34 PM, Tom Lieber wrote:

...
srsly. and with github, you also get the web page. and on the 'network' page you can see everybody's branches.

http://github.com/AllTom/chuck/tree/1.2.1.2

Someone should do it!

Oh cool I guess it's done then. :)

I was thinking of maintain a branch called "upstream" that is always synced against the CVS.

As far as I know github doesn't support "mob", that's why I was thinking of using git.or.cz.

Well, wherever. :) Free-for-all doesn't scare you at all? GitHub doesn't have that, but it does at least flatten the hierarchy -- anyone's branch is as "official" as any other one, so people will cluster how they will. -- Tom Lieber http://AllTom.com/

Stephen Sinclair

28 Dec 28 Dec

6:27 p.m.

On Wed, Dec 17, 2008 at 12:26 AM, Tom Lieber wrote:

...

On Tue, Dec 16, 2008 at 11:44 PM, Stephen Sinclair wrote:

...
On Tue, Dec 16, 2008 at 11:34 PM, Tom Lieber wrote:

...
srsly. and with github, you also get the web page. and on the 'network' page you can see everybody's branches.

http://github.com/AllTom/chuck/tree/1.2.1.2

Someone should do it!

Oh cool I guess it's done then. :)

I was thinking of maintain a branch called "upstream" that is always synced against the CVS.

As far as I know github doesn't support "mob", that's why I was thinking of using git.or.cz.

Well, wherever. :)

Free-for-all doesn't scare you at all? GitHub doesn't have that, but it does at least flatten the hierarchy -- anyone's branch is as "official" as any other one, so people will cluster how they will.

Just to follow up, I finally got around to making my public git repo: http://repo.or.cz/w/chuck-blob.git It's a clone of the ChucK CVS rather than just a dump of the release tarball. I'll generally try to keep "upstream" up to date. (I'll use a cron job I think..) Clone it with: git clone git://repo.or.cz/chuck-blob.git Once you have some patches for mob, you can push them with: git push origin mob (Too bad it's not called 'blob'!) I'll hold off on creating any kind of website to describe using it. For now, this just happens to be my public ChucK workspace, which should be convenient to clone for anyone wanting to work on ChucK. Just think of it as an alternative to using the CVS. You can also just post git-generated patches to the mailing list as usual, and I may integrate them into a public branch. Steve

Kassen

16 Dec 16 Dec

8:49 p.m.

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

I agree. Actually one of the things I'm hoping a initiative like this would lead to is more unity, not more fracturing. I believe that if implemented properly user generated UGens will create a closer community. This could also create fracturing, I agree, and I agree proceeding with caution is a good idea.

...

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.

Last thing I heard was that Princeton lacked Windows systems with suitable soundcards to test this. I was hoping Ge's move to Stanford would change that situation, I also volunteered to stress test release candidates. Not only is latency a real issue for many ChucKist applications; the Direct Sound version also lacks support for channels beyond stereo while the ASIO patch fixes this for reasons beyond my understanding. I recognise that OSX is extremely popular in US universities but Windows is a hard platform to ignore. Multi channel output (for surround application and external treatment) and low-latency (for live improvisations) sound to me like topics that are hard to live without for a system like ChucK. I'm sorry that I have to keep bringing this up but I feel it's a important issue.

...

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.

Yes, I have the source, I read it when in doubt about features, I once submitted a minor patch. We can do this, it works, but it's not really a platform for collaboration. Waiting for a new official release may take some months. If some people would want to try each-other's new experiments that would be too much time to wait. Submitting patches to the main branch is a great way of fixing bugs but I don't think it would be a good way to play with experimental UGen designs.

...

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.

This is also a good idea. I feel it's one of the advantages of ChucK that we can do DSP in the language if we want to but this isn't necessarily a good idea CPU-wise, at least not for basic building blocks.

...

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.

Yes and no. I'm torn about this. On the one hand I feel that having to compile UGens straight into the main source is somewhat heavy-handed (but it works and it's here right now!) on the other hand I also fear that completely separate plugins might lead to less compatibility between ChucKists. I'd like to see us move in this direction and ideally try to side-step those issues if possible.

...

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.

Maybe... but for general usage I don't believe we can expect the average user to have to compile a binary using a C++ compiler, at least not on commercial platforms. Even if it would be relatively easy this will scare people. I could imagine ChucK itself doing some of that but I also share some of your thoughts about PD. Again; I'm torn, I like the idea of people being able to customise their instrument according to their needs but I also think uniformity can help make things a lot easier, both to the individual and to the community. 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.

In rough lines those are indeed exactly my thoughts on this.

...

Maybe this needs to be moved to the DEV list as we impliment solutions.

I don't disagree with this but I'd also like to see what ideas people have on these topics. In a way these questions are about how developers relate to the community (and the other way around); how we'd like to work, learn and play with each other. Yours, Kas.

Kassen

4:02 p.m.

Adam; 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. Yours, Kas.

5963

Age (days ago)

5976

Last active (days ago)

List overview

Download

12 comments

4 participants

participants (4)

Adam Tindale
Kassen
Stephen Sinclair
Tom Lieber