Mikael Johansson joins Beginning Chuck blog
Today Mikael Johansson accepted my invitation to join the Beginning ChucK blog as a co-contributor. There's plenty of room for anyone else who may want to contribute -- please let me know. My email's down there at the bottom of this message. --Gary ---- Chess: http://chessnut.net/ Homepage: http://garywilliams.org/ Blog: http://tfs_reluctant.blogspot.com/ ChucK Blog: http://b-chuck.blogspot.com/ Resume: http://garywilliams.org/resume.htm Store: http://www.cafeshops.com/tfsreluctant/ Phone: (607) 775-0408 Permanent email: gwms@corninglink.com
i would like to propose an idea that might very well have good reasons for not doing. i'm putting this out here - phishing... i want perl and chuck to get married. chuck & perl what a beautiful couple. yeah, perlish things like @arrays & %hashes i need to throw at music. and map, grep, dothis if something, and the bajillion perl modules that might create a barrage of audio somehow. good idea/bad idea? if good how? run script thru perl interpreter which emits chuck code fed into chuck? line by line for speed? i'm not good at this tightly knit processor dependency type coding... what do you think?
On Jan 21, 2005, at 8:51 PM, qbxk wrote:
i would like to propose an idea that might very well have good reasons for not doing. i'm putting this out here - phishing...
i want perl and chuck to get married.
(Isn't ChucK a little young to be married (I mean, age difference aside)?)
chuck & perl what a beautiful couple. yeah, perlish things like @arrays & %hashes i need to throw at music. and map, grep, dothis if something, and the bajillion perl modules that might create a barrage of audio somehow. good idea/bad idea?
Maybe both good and bad? arrays + hashes are good things - going to appear shortly (see below) - and extensive string handling is coming soon. the bajillion Perl modules are tempting. Perhaps someone with more expertise in Perl (i.e. Alex and many other Perl-enthusiasts who are on this list) can give a better answer. I can, however, "articulate" one related aspect: The design goal of ChucK is to enable the precise, elegant, and flexible programming of audio, without loss of generality (i.e. completely flexible control rate, precise timing / concurrency), on-the-fly when appropriate. This aim has driven and hopefully will always guide (and modify) the future of ChucK. It is the hope that we, as a group, can figure out what is good towards that aim. As you can tell, ChucK syntax is glued together from syntax and ideas of many existing languages, ranging from C, Java, to Max/MSP, ML, to ChucK itself (some stuff had to be "invented"). An advantage of building the language from the "ground-up" and not necessarily committing the design to any one existing school of language design frees ChucK from obligations and focuses on the design of the language to reason about and control audio - we include what is useful, and leave out the rest. (It also means we have to re-invent some wheels, but that can be good because sometimes a round wheel isn't always we need) There are certainly a great many things we can learn and take from Perl (like it's powerful string/array processing, and the (sometimes ultra-)concise spirit of the language). There are other considerations which make tight integration difficult - for example, Perl is weakly-typed, unlike the ChucK type system, which is useful for things like resolving the ChucK operator, doing arithmetic on time and duration, and makes larger systems much easier to reason about and debug. In short, ChucK could learn much from Perl - though they are quite different in their "life goals". As for arrays in the next release: - there are arrays - arrays are strongly-typed like the rest of ChucK - arrays can be multi-dimensional - all arrays are, by default, both integer-indexed and associative: - more to come... // basic example { 1, 2, 3, 4 } => int foo[ ]; // assign to element 0 10 => foo[0]; // assign to value mapped from key: "bar", on same array 24 => foo["bar"];
if good how? run script thru perl interpreter which emits chuck code fed into chuck? line by line for speed?
This is an interesting idea to try, even for the sheer spectacle alone. Best, Ge!
On Jan 21, 2005, at 9:44 PM, Ge Wang wrote:
On Jan 21, 2005, at 8:51 PM, qbxk wrote:
chuck & perl what a beautiful couple. yeah, perlish things like @arrays & %hashes i need to throw at music. and map, grep, dothis if something, and the bajillion perl modules that might create a barrage of audio somehow. good idea/bad idea?
Maybe both good and bad? arrays + hashes are good things - going to appear shortly (see below) - and extensive string handling is coming soon. the bajillion Perl modules are tempting. Perhaps someone with more expertise in Perl (i.e. Alex and many other Perl-enthusiasts who are on this list) can give a better answer. Good but, as Ge says.
As you can tell, ChucK syntax is glued together from syntax and ideas of many existing languages, ranging from C, Java, to Max/MSP, ML, to ChucK itself (some stuff had to be "invented"). An advantage of building the language from the "ground-up" and not necessarily committing the design to any one existing school of language design frees ChucK from obligations and focuses on the design of the language to reason about and control audio - we include what is useful, and leave out the rest. (It also means we have to re-invent some wheels, but that can be good because sometimes a round wheel isn't always we need) And this is why I find ChucK to be the first "sensible" music programming language. It has what it needs to express its ideas (okay, arrays would be nice). and nothing more. It's clean and functional.
As for arrays in the next release:
- there are arrays - arrays are strongly-typed like the rest of ChucK - arrays can be multi-dimensional - all arrays are, by default, both integer-indexed and associative: - more to come...
// basic example { 1, 2, 3, 4 } => int foo[ ]; // assign to element 0 10 => foo[0]; // assign to value mapped from key: "bar", on same array 24 => foo["bar"]; This is *good*. ChucK will benefit from having essentially one type of structure - an indexed aggregate. Not tying it specifically to "it's an array"/"it's a hash" and hiding the complexitiy elsewhere fits with the spirit of ChucK, for me.
if good how? run script thru perl interpreter which emits chuck code fed into chuck? line by line for speed?
This is an interesting idea to try, even for the sheer spectacle alone.
This would be my strong suggestion. A whole new set of ChucK:: modules would be a happy happy thing. --- Joe M.
From: Ge Wang
On Jan 21, 2005, at 8:51 PM, qbxk wrote:
i would like to propose an idea that might very well have good reasons for not doing. i'm putting this out here - phishing...
i want perl and chuck to get married.
(Isn't ChucK a little young to be married (I mean, age difference aside)?)
Definitly, I think so at least. Has it got its bachelor degree from Princeton yeat? No? I didn't think so... ok, definitly too young!
chuck & perl what a beautiful couple. yeah, perlish things like @arrays & %hashes i need to throw at music. and map, grep, dothis if something, and the bajillion perl modules that might create a barrage of audio somehow. good idea/bad idea?
Maybe both good and bad? arrays + hashes are good things - going to appear shortly (see below) - and extensive string handling is coming soon. the bajillion Perl modules are tempting. Perhaps someone with more expertise in Perl (i.e. Alex and many other Perl-enthusiasts who are on this list) can give a better answer.
All tempting things may not be a good advice. Also, there are other alternatives available if a marrige is needed.
I can, however, "articulate" one related aspect:
<SNIP>
There are certainly a great many things we can learn and take from Perl (like it's powerful string/array processing, and the (sometimes ultra-)concise spirit of the language). There are other considerations which make tight integration difficult - for example, Perl is weakly-typed, unlike the ChucK type system, which is useful for things like resolving the ChucK operator, doing arithmetic on time and duration, and makes larger systems much easier to reason about and debug.
In short, ChucK could learn much from Perl - though they are quite different in their "life goals".
Just because there are good languages out there, not all the aspects of them will really make them usefull for real-time processing and real-time programming. You really need to think hard about what features you bring in, since the side-consequences may not be to hard when you do make a misstake and you also want to ensure that it is easy to do the right thing to start with.
As for arrays in the next release:
- there are arrays - arrays are strongly-typed like the rest of ChucK - arrays can be multi-dimensional - all arrays are, by default, both integer-indexed and associative: - more to come...
// basic example { 1, 2, 3, 4 } => int foo[ ]; // assign to element 0 10 => foo[0]; // assign to value mapped from key: "bar", on same array 24 => foo["bar"];
Yeah, that is a step forward... (I looked in the v2 grammar) some time back I advice a friend on his livecoding software where he was going to add arrays. His grammar works a bit different (assignments go left and not right) but strangely enought is the curly brackets left over for vector-constructions. So, he also had the starting point: v = {1,2,3,4}; Now he wanted pointers, but I convinced him that this was a *BAD* idea for a live-coding tool. You don't want to bother debugging pointers in realtime. Anyway, while at it I also proposed a slightly expanded grammar for the vector construction, so that not only single values can be added, but a bunch of values. a = {1,2} b = [3,4] v = {a,5,b} results in v = {1,2,5,3,4} Naturally, you may want to pick values out of a previous vector but not use all of them. a = {2,3,5,7} b = {11,13,17,19} v = {a[3],a[4],b[2],b[3]} It's a bit bulky, so introducing range-selection will make things much better: v = {a[3-4],b[2-3]} If you are curious, I recommended reference counters for him, with no destrutor. It took some time to figure out all the side-consequences, but I was able to close all leaks of references such that the vectors was trown exactly when they where no longer accessable, and thus avoiding a garbage-collector. Again, this makes it suitable for a real-time system.
if good how? run script thru perl interpreter which emits chuck code fed into chuck? line by line for speed?
This is an interesting idea to try, even for the sheer spectacle alone.
Mmmmm..... Cheers, Magnus
From: Ge Wang
On Jan 21, 2005, at 8:51 PM, qbxk wrote:
i would like to propose an idea that might very well have good reasons for not doing. i'm putting this out here - phishing...
i want perl and chuck to get married.
(Isn't ChucK a little young to be married (I mean, age difference aside)?)
Definitly, I think so at least. Has it got its bachelor degree from Princeton yeat? No? I didn't think so... ok, definitly too young!
chuck & perl what a beautiful couple. yeah, perlish things like @arrays & %hashes i need to throw at music. and map, grep, dothis if something, and the bajillion perl modules that might create a barrage of audio somehow. good idea/bad idea?
Maybe both good and bad? arrays + hashes are good things - going to appear shortly (see below) - and extensive string handling is coming soon. the bajillion Perl modules are tempting. Perhaps someone with more expertise in Perl (i.e. Alex and many other Perl-enthusiasts who are on this list) can give a better answer.
All tempting things may not be a good advice. Also, there are other alternatives available if a marrige is needed.
I can, however, "articulate" one related aspect:
<SNIP>
There are certainly a great many things we can learn and take from Perl (like it's powerful string/array processing, and the (sometimes ultra-)concise spirit of the language). There are other considerations which make tight integration difficult - for example, Perl is weakly-typed, unlike the ChucK type system, which is useful for things like resolving the ChucK operator, doing arithmetic on time and duration, and makes larger systems much easier to reason about and debug.
In short, ChucK could learn much from Perl - though they are quite different in their "life goals".
Just because there are good languages out there, not all the aspects of them will really make them usefull for real-time processing and real-time programming. You really need to think hard about what features you bring in, since the side-consequences may not be to hard when you do make a misstake and you also want to ensure that it is easy to do the right thing to start with.
As for arrays in the next release:
- there are arrays - arrays are strongly-typed like the rest of ChucK - arrays can be multi-dimensional - all arrays are, by default, both integer-indexed and associative: - more to come...
// basic example { 1, 2, 3, 4 } => int foo[ ]; // assign to element 0 10 => foo[0]; // assign to value mapped from key: "bar", on same array 24 => foo["bar"];
Yeah, that is a step forward... (I looked in the v2 grammar) some time back I advice a friend on his livecoding software where he was going to add arrays. His grammar works a bit different (assignments go left and not right) but strangely enought is the curly brackets left over for vector-constructions. So, he also had the starting point: v = {1,2,3,4}; Now he wanted pointers, but I convinced him that this was a *BAD* idea for a live-coding tool. You don't want to bother debugging pointers in realtime. Anyway, while at it I also proposed a slightly expanded grammar for the vector construction, so that not only single values can be added, but a bunch of values. a = {1,2} b = [3,4] v = {a,5,b} results in v = {1,2,5,3,4} Naturally, you may want to pick values out of a previous vector but not use all of them. a = {2,3,5,7} b = {11,13,17,19} v = {a[3],a[4],b[2],b[3]} It's a bit bulky, so introducing range-selection will make things much better: v = {a[3-4],b[2-3]} If you are curious, I recommended reference counters for him, with no destrutor. It took some time to figure out all the side-consequences, but I was able to close all leaks of references such that the vectors was trown exactly when they where no longer accessable, and thus avoiding a garbage-collector. Again, this makes it suitable for a real-time system.
if good how? run script thru perl interpreter which emits chuck code fed into chuck? line by line for speed?
This is an interesting idea to try, even for the sheer spectacle alone.
Mmmmm..... Cheers, Magnus
participants (5)
-
Gary Williams -
Ge Wang -
Joe McMahon -
Magnus Danielson -
qbxk