Adam;<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>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.<br>
</div></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br>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. </div>
</blockquote><div><br>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.<br>
<br>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. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br><br>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. <br>
</div></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br>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. </div>
</blockquote><div><br>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. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br><br>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.</div>
</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br><br>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.</div>
</blockquote><div><br>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. <br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div> 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.<br>
</div></blockquote><div><br>In rough lines those are indeed exactly my thoughts on this.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>Maybe this needs to be moved to the DEV list as we impliment solutions.<br></div></blockquote><div><br>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.<br>
<br>Yours,<br>Kas.<br></div></div><br>