Spencer wrote: *>personally be interested in a framework where ChucK can advance not just in response to academic research but in continuing to improve a nice programming language for musicians. I have thought a lot about this over the years and I still don't have an answer, but I do care :) Thoughts? I'm not an exper by any means on open source funding, but could you build a foundation similar to the Mozilla foundation? They somehow kept their code alive and thriving after netscape went away. Just my one cent... -- Rich On 1/25/2018 5:36 AM, Spencer Salazar wrote:
Hi all,
In terms of recent developments you'll notice a flurry of commits in the past year or so, mostly by Jack Atherton and Ge: https://github.com/ccrma/chuck/commits/master https://github.com/ccrma/chuck/commits/master Not to steal Jack's thunder but these are related to a very interesting research project hes been developing and perhaps can talk more about :) And in fact, at the moment we are actually at the verge of a new release.
Chuck Racks recently came out of my group at CalArts, though it is still very much in a beta state (and open to pull requests :). https://mtiid.calarts.edu/projects/software/chuck-racks/ https://mtiid.calarts.edu/projects/software/chuck-racks/
ChucK is going strong at CalArts, where we teach it to ~50 multidisciplinary art students every year and many, many more through Kadenze. The similarity of ChucK's syntax to e.g. Processing, Arduino, and C++ make it an ideal starting point for teaching this family of languages in the context of creative coding (this is also one reason why we do not start with teaching more well-known languages for music such as PureData, Max, or SuperCollider).
We also use ChucK to power most of our advanced music computing systems, for instance our entire Machine Orchestra architecture, our musical interface design instruction, and anything else involving physical hardware. ChucK is still the first tool I reach for for "musical systems integration," with its ability to synchronize between different hardware interfaces, software environments, network endpoints, and audio capture + emission.
Suffice it to say, my colleagues, students, and I have a significant interest in seeing ChucK thrive and continuing to nurture it in that direction.
That being said, if you look at the big picture of everything I detailed above, developments in ChucK are mainly driven by research initiatives (even the Kadenze course was originally created as part of an NSF grant). There is no research-oriented motivation to e.g. make static strings work better, or to improve and update documentation. The only real recent push to improve the user-facing aspect of programming with ChucK came in anticipation of the ChucK book, published in 2015, in which we allocated some funding to fix bugs and add some sorely missing features (such as string processing and SerialIO) -- huge thanks to Ajay for really pushing this effort.
Aside from that, its hard for me to really see how the nuts and bolts development of ChucK has been carried on outside of specific research agendas, or especially motivated grad students. I am personally be interested in a framework where ChucK can advance not just in response to academic research but in continuing to improve a nice programming language for musicians. I have thought a lot about this over the years and I still don't have an answer, but I do care :)
Thoughts?
Spencer
On Sat, Jan 13, 2018 at 6:53 PM, JP Yepez
mailto:jpyepezimc@gmail.com> wrote: Hello all,
I can't say much about the development part itself, but in my experience I've noticed that ChucK is still being used widely at an academic level. I understand it's being used in a few universities that include creative technology programs and computer orchestra courses in their curriculums, including CalArts, Stanford, and VUW (New Zealand). Like Mario mentioned, it is a core part of a few Kadenze courses; I've been involved as a producer/teaching assistant in a couple of them and it seems like it's a popular language among students who are just learning how to code, and musicians who would like to develop more advanced projects. Also, ChucK Racks popped up a couple of months ago, which was pretty exciting. So yeah, I think there's quite a bit going on, but it certainly would be nice to have a more active community (I'm hoping to contribute, and hopefully I'll get to it before too long).
About the *static strings* issue, I think they're kind of in a shady spot. Like Gonzalo mentioned, you can't have static non-primitives in your code, but there is a workaround to this by declaring objects as a reference and then initializing them outside of the class. However, if you try to do this with strings, it will tell you that they're a primitive type and it throws an error. The best hack I've found for this is through arrays (even if the size of the array is 1 in many cases). Here's an example:
publicclassContainer{
staticstringstaticString[];
publicstaticvoidinit(){
newstring[1]@=>staticString;
"Hello World"@=>staticString[0];
}
publicstaticvoidprint(){
<<
>>; }
}
Container.init();
Container.print();
You don't really need an init() function, and you can initialize the array on the actual script, but I usually end up with much larger classes, which is why I like to keep things clean. Hope this helps!
Best,
JP
*JP Yepez* New Media Artist - Musician - Researcher Website: http://www.jpyepez.com/ Email: jpyepezimc@gmail.com mailto:jpyepezimc@gmail.com -------------------------------------------------------- https://www.instagram.com/jpyepez/https://twitter.com/jpyepezmusichttps://www.linkedin.com/in/jp-yepez-063928123/
On Sun, Jan 14, 2018 at 12:19 AM, mario buoninfante
mailto:mario.buoninfante@gmail.com> wrote: Hi,
I'd like to ask the same question about the development status.
the only thing I can say is that also if the development seems to be a bit stuck, on the other side I noticed that they're pushing on the educational side (see Kadenze courses), and if you look at the github repository, there's been some update in the last 2 years.
but as you guys said, it's important to know what's the plan ;)
it's a couple of years I'm really diving into ChucK and I strongly believe that is a good programming language which opens up a lot of possibilities that other languages don't.
but at the same time I feel like it's been a bit abandoned (maybe that's a huge word, let's say put aside ;) ) and of course using a "tool" which has an "uncertain future" it's not the best thing.
I wish I was able to offer my contribution to the development, but unfortunately I'm not really into C/C++, I'm more a "scripting language guy" :)
btw, it would be nice to hear what developers and/or other users have to say about it.
cheers,
Mario
On 12/01/18 22:14, Gonzalo wrote:
Yes, I'm wondering the same thing. There's a Facebook group (https://www.facebook.com/groups/1593843507578422/ https://www.facebook.com/groups/1593843507578422/) but it doesn't look super active either.
As far as static strings: I'm pretty sure you just can't have static non-primitives. What are you trying to achieve?
Cheers, Gonzalo
On 13.01.18 00:20, Atte wrote:
Hi
I've been away for a long time and surprised that activity seems to have slowed down a lot, both on the development of new releases chuck and the life of this list. Am I looking at the wrong places? What's the status of chuck development now and in the future?
I really like chuck (mostly the timing and sporking including Machine.add()), should I look other places for a language that will privide a more secure future? I'm on linux and looked at Csound, Super Collider and PD, each has it's challenges in how I work (realtime generative and algorithmic MIDI), python seems to have realtime problems (garbage collection at random points). Any idea what former chuck users have switched to now?
Back to chuck! A problem that I never been able to solve, static strings:
public class A { "b" @=> static string B;
public static void C(){ <<<B>>>; } }
That throws an error, how would I go about what I'm trying to do?
Cheers
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu mailto:chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu mailto:chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- Spencer Salazar, PhD Special Faculty Music Technology: Interaction, Intelligence, and Design California Institute of the Arts
ssalazar@calarts.edu mailto:ssalazar@calarts.edu | +1 831.277.4654 https://spencersalazar.com https://spencersalazar.com/
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users