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

Kassen signal.automatique at gmail.com
Tue Dec 16 20:49:35 EST 2008


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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20081217/de4230fe/attachment-0001.html>

More information about the chuck-users mailing list