Author |
Message |
majutsu
Joined: Jun 18, 2006 Posts: 151 Location: New York
Audio files: 1
|
Posted: Thu Sep 14, 2006 3:18 pm Post subject:
programming in chuck |
|
|
i was reading a history and analysis of programming languages yesterday. it kind of blew my mind. reading about data structures, hypothetical future approaches, world modelling, typed versus untyped, logic programming versus object programming etc. i kept seeing hints of chuck in different styles. what elements does chuck have as a programming language. like i see some c++, some smalltalk, its strongly typed, object oriented (?) etc. what do you think? what is chuck like as a programming language. what are its features vis a vis other music programming languages? any programming experts out there? _________________ All phenomena are atoms in association and dissociation. |
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Fri Sep 15, 2006 12:07 pm Post subject:
Re: programming in chuck |
|
|
majutsu wrote: | i was reading a history and analysis of programming languages yesterday. |
Would you have a link for that? That sounds quite interesting. _________________ Kassen |
|
Back to top
|
|
|
kijjaz
Joined: Sep 20, 2004 Posts: 765 Location: bangkok, thailand
Audio files: 4
|
|
Back to top
|
|
|
blue hell
Site Admin
Joined: Apr 03, 2004 Posts: 24079 Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320
|
Posted: Fri Sep 15, 2006 1:30 pm Post subject:
|
|
|
Maybe http://en.wikipedia.org/wiki/Programming_language_theory , http://www.levenez.com/lang/history.html and http://en.wikipedia.org/wiki/FALSE
oops that last one was a mistake ...
Didn't go too deep into Chuck yet, so the following may have some nonsense in it - it might start a discussion maybe
Chuck uses some strange words, but to me it looks pretty much like a regular block structured language with OOP extensions, like the basic stuff from C++ or Object Pascal - or Fortran even.
The built-in scheduler is not seen much in other languages, although maybe that is not really a language feature but more like a runtime environment feature., The chaining of unit generators seems to borrow from graphical languages a bit ?
Seen some indications that a lot a of stuff is global in nature, probably some of that will be weeded out later ? _________________ Jan
also .. could someone please turn down the thermostat a bit.
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Mon Sep 18, 2006 6:44 am Post subject:
|
|
|
Blue Hell wrote: |
Chuck uses some strange words, but to me it looks pretty much like a regular block structured language with OOP extensions, like the basic stuff from C++ or Object Pascal - or Fortran even.
|
Yeah, sure there are some strange words but they tend to refer to concepts that are new-ish. That's fine with me; if you make something new you get to name it.
Shreds are a lot like "threats" and "spork" is a bit like "fork" (in a way) so those make sense to me.
Quote: |
The built-in scheduler is not seen much in other languages, although maybe that is not really a language feature but more like a runtime environment feature., The chaining of unit generators seems to borrow from graphical languages a bit ?
|
To me both of those are mainly a matter of having a expressive syntax suitable for the field it works for. You could (if you wanted to) emulate "shreduling" in linear code with loads and loads of flags and a stack (which happens at the lower level anyway). Even in languages that don't openly deal with execution order and time you can trace what order stuff happens in, then force it into some speciffic order if needed. For realtime music it makes a lot of sense to me to bve explicid about that.
Quote: |
Seen some indications that a lot a of stuff is global in nature, probably some of that will be weeded out later ? |
Not sure what you mean here. A few days ago I realy needed some stuff to be excplicidly global (a event in a public class) and it wasn't so much fun to wade through mailing list hints for the correct workaround. _________________ Kassen |
|
Back to top
|
|
|
dewdrop_world
Joined: Aug 28, 2006 Posts: 858 Location: Guangzhou, China
Audio files: 4
|
|
Back to top
|
|
|
kruhft
Joined: Oct 20, 2006 Posts: 50 Location: Canada
Audio files: 5
|
Posted: Fri Oct 20, 2006 8:10 pm Post subject:
|
|
|
dewdrop_world wrote: | Who is going to do the ChucK implementation of "99 Bottles of Beer" here? |
Code: |
for (99 => int i; i >= 0; i--) {
if(i > 1) {
<<< i, "bottles of beer on the wall", i, "bottles of beer." >>>;
<<< "Take one down and pass it around,", i-1, "bottles of beer on the wall" >>>;
} else if (i == 1) {
<<< i, "bottle of beer on the wall", i, "bottle of beer." >>>;
<<< "Take one down and pass it around,", "no more bottles of beer on the wall" >>>;
} else {
<<< "No more bottles of beer on the wall,", "no more bottles of beer." >>>;
<<< "Go the the store and buy some more,", "99 bottles of beer on the wall" >>>;
}
<<< "", "" >>>;
};
|
...because I'm not out drinking beer tonite. _________________ http://www.myspace.com/kruhft
http://kruhft.info |
|
Back to top
|
|
|
kruhft
Joined: Oct 20, 2006 Posts: 50 Location: Canada
Audio files: 5
|
Posted: Fri Oct 20, 2006 8:21 pm Post subject:
|
|
|
As for chuck as a language, it's not really all that exotic except for the addition of time as a type (which makes it very interesting for what it's designed for) and the chucking operator (=>), which is very context sensitive, a bit of a no-no in most language designs so far.
Personally, I use => only for chaining together ugens and filters and such; I keep screwing up variable assignments since they are backwards from what I'm used to (left to right, rather than right to left), but since chucking to a variable is just syntactic sugar for a function call, I tend to use the call explicitly. ie for a Pan2 pan:
0.5 => pan.pan; is the same as pan.pan(0.5);
I haven't dug too deeply into everything about chucks implementation and underlying features yet (warning: I'm a bit of a programming language theorist) but it seems pretty straight forward in it's design except for it's time dependence, which makes it great for music programming.
Basically, I like it, and quite a bit more than any other audio language I've tried so far. It makes sense, it works (heh) and I can actually do something with it other than just play around and give up in frustration. _________________ http://www.myspace.com/kruhft
http://kruhft.info |
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Fri Oct 20, 2006 8:53 pm Post subject:
|
|
|
Makes sense, yeah. I myself like the chuck operator; it's very context sensitive but it always deals with sending something to somewhere which makes a lot of intuitive sense if you're used to modular systems.
BTW, I think "broadcasting" and "signaling" events is quite unique as well but I might be wrong? _________________ Kassen |
|
Back to top
|
|
|
kruhft
Joined: Oct 20, 2006 Posts: 50 Location: Canada
Audio files: 5
|
Posted: Fri Oct 20, 2006 9:13 pm Post subject:
|
|
|
Kassen wrote: | Makes sense, yeah. I myself like the chuck operator; it's very context sensitive but it always deals with sending something to somewhere which makes a lot of intuitive sense if you're used to modular systems. |
Yes, it does in my head when I'm dealing with signals, but I keep getting annoyed with wanting to write osc0.freq = 220 and having to fix it all the time. I just changed the style and it then I stopped screwing up, thus making less frustrated, and more likely to write something
Quote: | BTW, I think "broadcasting" and "signaling" events is quite unique as well but I might be wrong? |
Broadcast and signal are unique to have in a language, but they are pretty standard from a threaded programming paradigm. Putting the threading into the syntax and runtime isn't very common for a language, or at least not to the level that chuck has (Erlang is probably the most multi-threaded oriented language around at the moment, but most have threading as an add on library instead of being built in, so far).
Chuck is interesting because it's a 'practical' implementation of a number of 'practical' things for it's problem domain; they might not be correct in a language theoretical sort of way, but, but they sure make solving a certain type of problem (writing music) quite a bit easier. _________________ http://www.myspace.com/kruhft
http://kruhft.info |
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Fri Oct 20, 2006 11:54 pm Post subject:
|
|
|
kruhft wrote: |
Yes, it does in my head when I'm dealing with signals, but I keep getting annoyed with wanting to write osc0.freq = 220 and having to fix it all the time. I just changed the style and it then I stopped screwing up, thus making less frustrated, and more likely to write something
|
It's definately unconventional but I like the clear distinction between going;
X is three (because I say so)
and
I wonder wether X might equal three?
When reading some languages I'm not familiar with it's often unclear to me which one is meant, at least at first sight while here it's always very clear. It can get especially confusing if somebody wants to express
Do this, but only if I can make X hold the value three*.
as compared to
Do this, but only if x is three.
Admittedly that sort of clarity is rather accedemic if it confuses you in practice but I like it.
*That exact expression would be rather unusual but let's keep it simple... _________________ Kassen |
|
Back to top
|
|
|
kruhft
Joined: Oct 20, 2006 Posts: 50 Location: Canada
Audio files: 5
|
Posted: Sat Oct 21, 2006 1:11 am Post subject:
|
|
|
Understandable and I see what you mean. It's been a very long time since I've mistyped = and == in my C coding, so I can't say I have the same problem. I was just writing something with chuck tonite and I might be getting a better hang of using => on variables; it's only been a few days, so I guess it took me a while to translate in my head.
I'm still not sure about the quality of the sound engine in Chuck though yet; it worked really well for the noise/breakcoreish track I just did, but I was having some severe noise and distortion problems on an ambient track and figuring out the volumes for parts was pretty hit and miss and were very unintuitive overall. I'm sure with practice it will get easier, but some things about the engine are a bit odd. I was planning on doing some engine/language hacking after using Chuck for a bit...I've already had a few ideas that could fix things up and help out a bit.
Any idea if the ChucK source can be gotten from CVS? I found the page on sourceforge but the repository is empty. I prefer to work on CVS versions just so I can hit any conflicts early rather than later...
Anyways, I really should be sleeping since I have to work in the morning. Damn coffee... _________________ http://www.myspace.com/kruhft
http://kruhft.info |
|
Back to top
|
|
|
majutsu
Joined: Jun 18, 2006 Posts: 151 Location: New York
Audio files: 1
|
Posted: Sat Oct 21, 2006 7:31 am Post subject:
|
|
|
lol
good posts
coffee is good. it is work that is bad.
i am studying python and c++ now. this is making looking at chuck even more interesting, as until previously, i had not dealt with any new oop's. _________________ All phenomena are atoms in association and dissociation. |
|
Back to top
|
|
|
kruhft
Joined: Oct 20, 2006 Posts: 50 Location: Canada
Audio files: 5
|
Posted: Sat Oct 21, 2006 12:47 pm Post subject:
|
|
|
majutsu wrote: | lol
good posts
coffee is good. it is work that is bad.
i am studying python and c++ now. this is making looking at chuck even more interesting, as until previously, i had not dealt with any new oop's. |
Yes, coffee is very good, except later at night. Python is fun and pretty easy to get a handle on; I'm a C junkie myself but have just started getting into C++ again after being told about 10 years ago that I should give up on it "since nobody is ever going to use it for anything real" as told to me by my employers at the time The current coolest language I've found is called Q, but that one takes a bit of time to wrap one's head around, but it's on my (very long) list of new things to learn to use. _________________ http://www.myspace.com/kruhft
http://kruhft.info |
|
Back to top
|
|
|
majutsu
Joined: Jun 18, 2006 Posts: 151 Location: New York
Audio files: 1
|
Posted: Sun Oct 22, 2006 11:46 am Post subject:
|
|
|
totally off-topic now, but ...
what are the prospects for sound in python and c++
if i see right, python can use pySound or MusicKit to do synthesis as well as script with PD
c++ has a few sound libraries, most importantly, the ever-famous STK
isn't the chuck virtual engine and i/o in c++ or am i wrong?
does python have an adequate sound library for synthesis? if so what is it? _________________ All phenomena are atoms in association and dissociation. |
|
Back to top
|
|
|
majutsu
Joined: Jun 18, 2006 Posts: 151 Location: New York
Audio files: 1
|
Posted: Sun Oct 22, 2006 6:16 pm Post subject:
|
|
|
or python scripts to interact with chuck . . . .
_________________ All phenomena are atoms in association and dissociation. |
|
Back to top
|
|
|
mosc
Site Admin
Joined: Jan 31, 2003 Posts: 18197 Location: Durham, NC
Audio files: 212
G2 patch files: 60
|
Posted: Sun Oct 22, 2006 7:14 pm Post subject:
|
|
|
The fact that ChucK has such a great command level interface, with built-in concurrence and synchronization, it could be integrated with many different languages as long as they can make system calls. I haven't gotten too much into ChucK yet, but I would hope that is is possible to set variables on the command line with args, but it would be easy to write ChucK files on the fly. Thirty years ago people would balk at that as being inefficient, but today opening files doesn't present efficiency issues. _________________ --Howard
my music and other stuff |
|
Back to top
|
|
|
spencer
Joined: Aug 16, 2006 Posts: 53 Location: northern california
|
Posted: Sun Oct 22, 2006 9:29 pm Post subject:
|
|
|
Throwing another option out there:
Using OpenSound Control (OSC), one can communicate between ChucK and any other programming language that has an OSC implementation (Max/MSP, Pd, SuperCollider, Python, Perl, Java, C++, etc.), passing arbitrary ints, floats, and strings between multiple programming environments. OSC has an open source C++ implementation and even has a command line interface.
http://www.cnmat.berkeley.edu/OpenSoundControl/ |
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Sun Oct 22, 2006 10:03 pm Post subject:
|
|
|
mosc wrote: | The fact that ChucK has such a great command level interface, with built-in concurrence and synchronization, it could be integrated with many different languages as long as they can make system calls. I haven't gotten too much into ChucK yet, but I would hope that is is possible to set variables on the command line with args, but it would be easy to write ChucK files on the fly. Thirty years ago people would balk at that as being inefficient, but today opening files doesn't present efficiency issues. |
You can edit ChucK variables from the command-line but you need to enter "chuck shell" (by going C:/>chuck --shell) and it's in a realy early and rough state.
Another way of doing it would be to make sure your code stores it's important variables as static data inside of public classes (meaning all instances of the class share the same data). That way you could machine-generate a file to change those values (then exit) and call it from the prompt. This wouldn't be that hard.
In my own experience the concurency thing makes ChucK very good at being in controll so I end up spending more time at making ChucK controll other synths then at making things controll ChucK, then feed ChucK myself from the keyboard and joypads. The concurency thing makes ChucK good at getting higher level commands and dealing with spitting out a larger (longer) musical gesture while I went on to input something new while it executes.
OSC would be more practical, I think, particularly because that would make it independant of being on the same machine.
ChucK, by the way, can send system calls and that's why some months ago I asked about calling the NM editor from the prompt, feeding it a PCH file with a slot parameter in the call.
Talking about efficiency and ChucK right now may not be the most cheerfull of subjects. Writing ChucK is often very efficient but running it is another matter... _________________ Kassen |
|
Back to top
|
|
|
kruhft
Joined: Oct 20, 2006 Posts: 50 Location: Canada
Audio files: 5
|
Posted: Mon Oct 23, 2006 6:32 am Post subject:
|
|
|
My 99 bottles of beer code was accepted to the site this morning:
http://www.99-bottles-of-beer.net/language-chuck-1309.html
I've been browsing the ChucK code in my time between jobs and it does look like it needs some work here or there, but it's pretty well written and structured, so once I get more familiar with it (and find some time) I hope to get in there to fix and add some things.
The language/engine is written in C++ and has some clever macro work to bind the C++ objects to the engine's runtime object system.
As for using python for audio and music, I'm sure there are libraries out there to help, but having a language like ChucK that is designed for it makes things so much easier. I've tried a number of ways of creating algorithmic music generating code and have always found that time gets in the way; I like the idea that in chuck everything is concurrent (or at least seems so) and it's easy to get things on beat without resorting to a bunch of calculations all over your code (to compensate for sample lengths and blocking when you play a note/sample). Like any good program, it does the grunt work for you so you can think at a higher level to solve your problem.
I hope that made sense. I haven't had my coffee yet. _________________ http://www.myspace.com/kruhft
http://kruhft.info |
|
Back to top
|
|
|
|