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 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.<br>
</div></blockquote><div><br>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.<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>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.</div>
</blockquote><div><br>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.<br>
<br>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.<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>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. <br>
<br>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.<br>
</div></blockquote><div><br>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.<br>
</div></div><br>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.<br>
<br>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".<br>
<br>I hope that clarifies.<br><br>Yours,<br>Kas.<br>