| Author |
Message |
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
 Posted: Sun Oct 26, 2008 3:02 pm Post subject:
|
  |
|
| manaris wrote: |
Don't get me wrong. I was besides myself when I discovered ChucK and what one could easily do with it (e.g., hid). |
Yeah, that seems to be one of the major selling points that gets people hooked... I've actually started wondering why the developers of some of the more mainstream music packages don't implement that.
| Quote: |
But, unfortunately, that's my observation. Perhaps I am the exception to the rule. I was really excited about it, so were the students, until we started diving into some of the examples. The fact that ChucK follows a C++/Java like syntax is not helping. Hence, my posting above about Python. |
Ok. Well, I don't teach professionally but I do see a lot of people getting into it and blowing my mind with their picks for a first project, only to get something usable very quickly. I don't think C++/Java is such a bad pick as a foundation for syntax; like any other choice it comes with advantages and disadvantages; some things are very easy, other things are harder. I don't think anybody would seriously claim those two aren't very powerful languages, they are nearly universal in some fields. For CS students it's far from a bad idea to get to grips with that kind of syntax in a relatively friendly and fun environment like ChucK, I'd say.
It's true that all the brackets can get annoying to write and I have often cursed the type-system because it complained when I felt it was perfectly clear what I meant but at the same time it's also true that parser errors often point out errors in my reasoning. For me satisfying the parser takes a lot less time then debugging something that's wrong -but does compile- by ear.
| Quote: | Here are two examples of small (for me, but not my non-programmer students) issues with consistency:
Why '@=>' vs. '=>'? (Why not overload '=>' once more, and introduce a copy() operator?)
|
I'm not sure what Ge's reasoning was there but I'm actually in favour of the current situation. UGens are one case where "@=>" and "=>" may both be used with very different results (assignment v.s. connecting). I'd like to have the ability to overload the ChucK operator of object types I defined myself and if we'd overload it to indicate assignment we couldn't do that.
| Quote: | Another example:
SinOsc x => dac;
SinOsc y => dac;
440 => x.freq;
x.freq => y.freq; // error! x.freq is actually a function.
|
Hmmmm, I may agree here. Functions aren't objects in ChucK so they can't be send anywhere. Calling a function without brackets results in a reference to some sort of memory location which isn't any good for anything.
| Quote: | | (If hiding the fact that SinOsc.freq() is a function, why not overload it, so that when called without arguments it returns the current frequency? |
Actually, it does; x.freq() does return the frequency as a float, nearly all member functions of UGens are overloaded in that way. Without brackets it refers to the function itself, which -as I mentioned- isn't any good for anything (yet?). I would be quite interested in functions as objects in ChucK though I'm sure there would be repercussions I don't see right now.
| Quote: | | Also, hide in the documentation the fact that SinOsc.freq() is a function. |
I'm not sure why we would do that? that would make things much more complicated to explain once we will be able to define classes of type UGen. They are functions and I don't see any problem with them being functions, really.
| Quote: | Or even better... why doesn't '=>' bind the two frequencies together?)
|
I agree, that's what it should probably do. The main reason for not doing that right now is probably that this (assuming it would update every samp) would get spectacularly expensive without block processing
| Quote: |
Again, don't get me wrong - I really like ChucK for what it can do so easily. I was thinking perhaps that having Python bindings would allow one to create a more accessible API subset for beginners.
|
I agree with you on the function calls; we could resolve "forgetting the brackets" by pretending there was a pair of brackets without a parameter there as syntactic sugar but I feel that would come at the expense of being able to treat functions as something "object-like" in the future. I'm not sure that would be a good trade. Still; I too forget to type those brackets every once in a while.
| Quote: | | Thanks again for the welcome. I hope I have not lost all grace with my comments... |
No, not at all, of course not! Debate is healthy and I do agree there are some very interesting aspects to Frostburn's idea, not just for beginners but for more advanced usage as well. You do make some good points and there are some dubious holes in the ChucK syntax (fortunately nobody is claiming it's finished!) but it's not my experience that ChucK is hard to get into. I saw a rather nice example just today;
http://www.smack-dynamik.com/smack_dynamik/topic-10511-0-0.html
That's a forum topic on a party I played at Friday night. Somebody (Transistor Rhythm) was very interested in my homebrew sequencer and asked what I used for that when I briefly talked to him there. Now, Sunday, he's posting his first experiment on page 4. If we take into account that this party ran quite late so Saturday may have been half-filled with a bit of a hangover I'd say that's quite impressive as anecdotal evidence of how smooth it can be. I'll be the last to claim ChucK is without issues, actually I reported quite a few of them, but IMHO "killing them" is a bit strong. Then again; I have no idea of the background of your students, I could imagine there are more complicated factors in play here. Disagreeing is perfectly fine with me, BTW, as long as I have anything to say about it nobody is "losing grace" over posts like this; our time-starved dev's do listen to feedback so I feel it's better to err on the side of blurting things out and having some debate.
_________________
Kassen |
|
|
Back to top
|
|
 |
manaris
Joined: Oct 24, 2008
Posts: 8
Location: Charleston, SC
|
| Posted: Mon Oct 27, 2008 7:05 am Post subject:
|
|
|
| Kassen wrote: |
That's a forum topic on a party I played at Friday night. Somebody (Transistor Rhythm) was very interested in my homebrew sequencer and asked what I used for that when I briefly talked to him there. Now, Sunday, he's posting his first experiment on page 4. If we take into account that this party ran quite late so Saturday may have been half-filled with a bit of a hangover I'd say that's quite impressive as anecdotal evidence of how smooth it can be. I'll be the last to claim ChucK is without issues, actually I reported quite a few of them, but IMHO "killing them" is a bit strong. Then again; I have no idea of the background of your students, I could imagine there are more complicated factors in play here. Disagreeing is perfectly fine with me, BTW, as long as I have anything to say about it nobody is "losing grace" over posts like this; our time-starved dev's do listen to feedback so I feel it's better to err on the side of blurting things out and having some debate. |
We are basically in agreement. The only thing worth mentioning is that we might have different definitions for "typical" non-programmer. Sometimes we confuse a convenience (statistical) sample with a random sample. (And I may be the guilty one here!)
For whatever it is worth, here is an interesting quote from Alan Kay's "The Early History of Smalltalk" paper):
| Quote: | | When teaching [programming] to 20 nonprogrammer adults, they were able to get through the initial material faster than children, but, just as it looked like an overwhelming success was at hand, they started to crash on problems that didn’t look to me to be much harder than the ones they had just been doing so well on. … E.g., make a little database system that would act like a card file or rolodex. They couldn’t even come close to programming it. Such a project was well below the mythical ‘two pages’ for end-users we were working with. After showing them the solution, I realized this little program contained 17(!) nonobvious ideas. And some of them were like the concept of the arch in building design: very hard to discover, if you don’t already know it. |
There are many arches in ChucK (even for me). That's perhaps part of why it is so powerful/beautiful/enabling.
I suspect there is truth to the statement that ChucK works well with non-programmers, but perhaps these non-programmers are otherwise highly-gifted intellectually (e.g., in the ~90th percentile, enrolled (or enrollable) in schools like Princeton, Yale, etc.). There are 150+ nationally accredited undergraduate CS programs in the US that enroll non-programmers not in the ~90th percentile.
An interesting example is MIT's Scratch. Scratch was originally developed to teach programming to 8-year olds. However, CS educators (from accredited programs in the US) use it to introduce programming to university freshmen. Another example is CMU's Alice.
Which brings us back to my comment about Python bindings... I do not expect Ge and colleagues to enter the pedagogy arena. But others who are already in it, might bring ChucK (or a subset of it) to a wider audience.
Of course, this begs the question what such a subset might contain... which brings us to HCI and task analysis (of typical users). Which is a different topic altogether. |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Mon Oct 27, 2008 8:29 am Post subject:
|
|
|
| manaris wrote: |
We are basically in agreement. The only thing worth mentioning is that we might have different definitions for "typical" non-programmer. Sometimes we confuse a convenience (statistical) sample with a random sample. (And I may be the guilty one here!)
|
Absolutely! It's hard to beat somebody who wants to program because it's fun to him, a teacher's credits don't have a thing on the endorphins released when doing something we find "fun" (though of course hopefully those will line up to at least some degree). We know that it is already a small sub-group of people that will start wondering "what are you running?" at a dance music performance and that the people who will go "I'd like to try that too" is a even smaller group... So yes, of course it's no miracle that he got quite far in a few hours but it's still a great sign to me that he *did* get that far.
| Quote: | For whatever it is worth, here is an interesting quote from Alan Kay's "The Early History of Smalltalk" paper):
| Quote: | | When teaching [programming] to 20 nonprogrammer adults, they were able to get through the initial material faster than children, but, just as it looked like an overwhelming success was at hand, they started to crash on problems that didn’t look to me to be much harder than the ones they had just been doing so well on. … E.g., make a little database system that would act like a card file or rolodex. They couldn’t even come close to programming it. Such a project was well below the mythical ‘two pages’ for end-users we were working with. After showing them the solution, I realized this little program contained 17(!) nonobvious ideas. And some of them were like the concept of the arch in building design: very hard to discover, if you don’t already know it. |
|
Yes, good point. I think this may be worse with Smalltalk because SmallTalk will demand having at least some background in formal logic up to and including recursion and that's the sort of thing that will need a bit of time to digest. Once the lambda's and stacks of recursion start flying most people will have bewildered looks for a while until they realise those things are actually a fairly natural match for they way they think in day to day life. If you like Smalltalk you could have a look at SuperCollider if you didn't already. It's more or less like ChucK in purpose but based on Smalltalk.
| Quote: | There are many arches in ChucK (even for me). That's perhaps part of why it is so powerful/beautiful/enabling.
|
I think so. Another thing we need to consider is that ChucK is a powerful instrument, a great tool for filling gaps in the studio, it a educational tool.... but it's also a creative work by Ge (and others) expressing ideas about music, about sound and thought. Even back when it wasn't yet my main instrument at merely a fun toy it was changing the way I thought about music and sound. I suppose that many things are like that; I have no issue at all with considering a physics textbook to be a work of art that expresses some ideas about the nature of the world. In a way this is natural but we do need to take it into account.
| Quote: | I suspect there is truth to the statement that ChucK works well with non-programmers, but perhaps these non-programmers are otherwise highly-gifted intellectually (e.g., in the ~90th percentile, enrolled (or enrollable) in schools like Princeton, Yale, etc.). There are 150+ nationally accredited undergraduate CS programs in the US that enroll non-programmers not in the ~90th percentile.
|
Sure, or perhaps the creatively curious with time to spare. If you don't have a certain level of thinking you probably won't be enrolling in CS classes at esteemed universities and it's probably safe to assume you won't start developing your own instrument(s) if you're not highly driven by your own thoughts about music. At the risk of sounding elitist; there simply are large groups of people that don't have either the need or the desire to program. We do need to face that there is a "target market" for ChucK, probably consisting of students and the creatively adventurous and that we are aiming to lower the tresshold in that specific context.
I have, BTW, no idea of Transistor Rhythm's background but on average I'm pleased that that forum does tend to attract relatively intelligent people.
| Quote: |
Which brings us back to my comment about Python bindings... I do not expect Ge and colleagues to enter the pedagogy arena. But others who are already in it, might bring ChucK (or a subset of it) to a wider audience. |
I'm not sure you realise that most of the Dev's are actually working as teachers and professors. Ge is a assistant professor at Stanford these days, Perry Cook probably needs little introduction in the world of computer music. Plork ( http://plork.cs.princeton.edu/ ) may be a musical band but it's also a teaching method and at the same time it's a research project into educational techniques. If you have specific notes from your own educational practice about ChucK you should definitely contact Ge personally because I suspect he'll be very interested.
| Quote: | | Of course, this begs the question what such a subset might contain... which brings us to HCI and task analysis (of typical users). Which is a different topic altogether. |
If you didn't already you may want to have a look at Ge's thesis; http://www.cs.princeton.edu/~gewang/thesis.html Particularly the section starting at page 118 which deals speciffically with teaching ChucK / using ChucK to teach.
I should probably also mention that I'm a musician, one who dropped out of studying artificial intelligence and so I still stick to a relatively cerebral approach at times but still a musician; I'm writing to you from a bedroom studio, not a university room :¬).
_________________
Kassen |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Mon Oct 27, 2008 8:34 am Post subject:
|
|
|
BTW, Frostburn, I can split this topic if you'd like your topic to just be about your project; educational usage might be a separate issue. The thing is; I can split but not merge so I'm only doing that if we can all agree on what would be best. Personally I don't mind a bit of "topic drifting", I prefer to focus on a naturally flowing dialogue over "sorting everything into little boxes".
_________________
Kassen |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Mon Oct 27, 2008 9:37 am Post subject:
|
|
|
| manaris wrote: | I do not expect Ge and colleagues to enter the pedagogy arena. But others who are already in it, might bring ChucK (or a subset of it) to a wider audience.
|
Sorry, I think I misunderstood this. I originally took this to mean that you didn't expect Ge, Perry (and crew) to start teaching so I thought "something is going very wrong here, communication-wise", but then I noticed that on your page you are already linking to Plork.
I think you are using the word "pedagogy" here to speciffically refer to teaching to children as opposed to young(ish) adults, right?
_________________
Kassen |
|
|
Back to top
|
|
|
manaris
Joined: Oct 24, 2008
Posts: 8
Location: Charleston, SC
|
| Posted: Mon Oct 27, 2008 11:11 am Post subject:
|
|
|
| Kassen wrote: | | manaris wrote: | I do not expect Ge and colleagues to enter the pedagogy arena. But others who are already in it, might bring ChucK (or a subset of it) to a wider audience.
|
Sorry, I think I misunderstood this. I originally took this to mean that you didn't expect Ge, Perry (and crew) to start teaching so I thought "something is going very wrong here, communication-wise", but then I noticed that on your page you are already linking to Plork.
I think you are using the word "pedagogy" here to speciffically refer to teaching to children as opposed to young(ish) adults, right? |
No, no. You are fine. There is an on-going push among CS university educators to redefine how we teach CS1 (Intro to CS), etc. The forum I had in mind is ACM's SIGCSE.
I will read Ge's thesis, because, you are right, it has many things that I need to familiarize myself with. Thanks for suggesting it.
Earlier I was writing from my own studio/creative space... but, alas, now I am in my university room. 
Thanks for the attention and helpful comments. |
|
|
Back to top
|
|
|
manaris
Joined: Oct 24, 2008
Posts: 8
Location: Charleston, SC
|
| Posted: Mon Oct 27, 2008 3:38 pm Post subject:
|
|
|
| manaris wrote: | | I will read Ge's thesis, because, you are right, it has many things that I need to familiarize myself with. Thanks for suggesting it. |
Wow! This is an impressive, all-around piece of work. And pretty recent (Sep. 2008)! |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Mon Oct 27, 2008 6:25 pm Post subject:
|
|
|
Ah, I see. Well, if I can offer my uneducated perspective; I think that if you give children a pile of blocks they'll go build bridges (this is really quite amazing). I firmly believe that people are naturally curious and creative and that the most healthy way of teaching (where possible) is to stimulate that. Memorising a list of member functions to the HID object is boring, playing noises from your mouse or joypad is fun and if you are having fun you may not even notice you have accidentally already become familiar with the HID object. I think that's exactly what Ge is aiming for with PLORK, etc, and it's how I learned to ChucK. The sole reason I indent in a consistent way and write comments is that I learned the hard way that the alternative is less fun in the long run and would keep from building larger bridges. I'm getting the feeling that the ChucK dev's aren't so much "stepping in the arena" as they are simply going ahead and trying something new and exciting, I very much approve of that. I have little idea of what's happening in this arena but I did look at what projects were turned in by PLORK members and those are really quite interesting. You can't expect a new programmer to write like a seasoned pro but on the other hand I didn't expect them to try to tackle the sort of problem they are taking on right now with considerable success, that may be much more interesting.
Anyway, yes, Ge's thesis is great, it's like the manifest that was missing, it actually documents some things in a better way then the manual does;
| Code: | repeat(8)
{
//this gets looped over
}
|
...doesn't get documented in the manual but it's in the thesis (I was very honoured to be asked to proof read it and so forced to notice details like that). More importantly and more interestingly; the thesis explains a lot of the vision behind it all. IMHO a lot of it could (and probably should) go straight into the manual because a overall perspective is very helpful in explaining *why* all those separate elements are where they are.
That's not to say everything is perfect (far from it!), fortunately being very critical of ChucK does turn out to be a great way to get things fixed and befriend Ge, I think you should keep up giving these comments. It's win/win; you could be mistaken and learn something or you may have spotted a real issue and so contribute to fixes.
I'd like to thank you in return for your attention and comments but really; there would be little use in a forum without attention and comments. It's a bit mysterious to me why those aren't the standard everywhere but fortunately we seem to be very lucky here.
_________________
Kassen |
|
|
Back to top
|
|
|
Inventor
Stream Operator
Joined: Oct 13, 2007
Posts: 6221
Location: near Austin, Tx, USA
Audio files: 270
|
| Posted: Mon Oct 27, 2008 6:34 pm Post subject:
|
|
|
| Kassen wrote: | | I'd like to thank you in return for your attention and comments but really; there would be little use in a forum without attention and comments. It's a bit mysterious to me why those aren't the standard everywhere but fortunately we seem to be very lucky here. |
That's because we have such thoughtful folks as yourself, Kas.
_________________
"Let's make noise for peace." - Kijjaz |
|
|
Back to top
|
|
|
manaris
Joined: Oct 24, 2008
Posts: 8
Location: Charleston, SC
|
| Posted: Tue Oct 28, 2008 6:35 pm Post subject:
|
|
|
| Kassen wrote: | | I think that if you give children a pile of blocks they'll go build bridges (this is really quite amazing). I firmly believe that people are naturally curious and creative and that the most healthy way of teaching (where possible) is to stimulate that. Memorising a list of member functions to the HID object is boring, playing noises from your mouse or joypad is fun and if you are having fun you may not even notice you have accidentally already become familiar with the HID object. |
You are right. I have taken (and probably given ) classes were memorization was the main objective. It is only when people start applying, analyzing, and synthesizing that things really click. So, yes, your point is a great one.
| Kassen wrote: | | Anyway, yes, Ge's thesis is great, it's like the manifest that was missing, it actually documents some things in a better way then the manual does; ... IMHO a lot of it could (and probably should) go straight into the manual because a overall perspective is very helpful in explaining *why* all those separate elements are where they are. |
I agree.
| Kassen wrote: | | fortunately being very critical of ChucK does turn out to be a great way to get things fixed and befriend Ge, I think you should keep up giving these comments. It's win/win; you could be mistaken and learn something or you may have spotted a real issue and so contribute to fixes. |
Will do that. Thank you. (Frostburn, sorry for "polluting" your thread ) |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Tue Oct 28, 2008 7:44 pm Post subject:
|
|
|
| manaris wrote: |
You are right. I have taken (and probably given ) classes were memorization was the main objective. It is only when people start applying, analyzing, and synthesizing that things really click. |
Of course, but the history of modern education isn't a 100% pleasant one (the Prussian system, etc)... and indeed sometimes memorisation may be needed. Did you see this; http://wiki.cs.princeton.edu/forums.html/PLOrk_spring2008#Assignments ? Some of that made me wonder; "She's asking WHAT?!!! Of people who may never have coded before?" but then I realise we are dealing with people who signed up of their own free will, who are all armed with Google, who are probably quite intelligent and who will have a strong urge (like all people) to express themselves and then it seems perfectly sensible, if a bit daring.
| Quote: |
Will do that. Thank you. (Frostburn, sorry for "polluting" your thread ) |
Personally (but mr. Burn should have his say as well) I don't think there is any pollution. If his ideas wouldn't trigger debate he may as well not publish them.
Full steam, straight ahead, I say! :¬)
_________________
Kassen |
|
|
Back to top
|
|
|
manaris
Joined: Oct 24, 2008
Posts: 8
Location: Charleston, SC
|
| Posted: Wed Oct 29, 2008 6:21 am Post subject:
|
|
|
| Kassen wrote: | | Did you see this; http://wiki.cs.princeton.edu/forums.html/PLOrk_spring2008#Assignments ? Some of that made me wonder; "She's asking WHAT?!!! Of people who may never have coded before?" but then I realise we are dealing with people who signed up of their own free will, who are all armed with Google, who are probably quite intelligent and who will have a strong urge (like all people) to express themselves and then it seems perfectly sensible, if a bit daring. |
No I had not seen this. This is very helpful. I will study it in detail. Many thanks!
| Kassen wrote: |
Personally (but mr. Burn should have his say as well) I don't think there is any pollution. If his ideas wouldn't trigger debate he may as well not publish them.
Full steam, straight ahead, I say! :¬) |
OK, then... here's a crazy thought:
Have you seen this Python tutorial - "Instant Python (for programmers)"?
Also, have you seen this open/free textbook - "How to Think Like a Computer Scientist - In Python?"
 Wouldn't be wonderful if some creative people joined forces (read "intellect", "passion", "energy", etc.) and put together a book like "How to Think Like a Computer Musician - In Python?"
I am thinking that with mr. burn's Python code base, the expertise of certain people on this forum, etc., etc., this would be a most wonderful project to bring computer music and computational thinking to the masses.
Like I said, a crazy thought... (and now it's probably time for me to go back to my university room and be quiet ). |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Wed Oct 29, 2008 8:38 am Post subject:
|
|
|
I'll have a look at those, I don't know enough about Python to say anything about some of the more in-depth suggestions that have been made.
Some random notes;
*If you'd like to work with Python and music you may be interested in the API for Ableton Live that uses it. There is some info to start with here; http://www.remix.net/wiki/AbletonLive
*For any book about "how to be a computer musician" we would need to establish exactly what a "computer musician" is. Computers have this tendency to blur the distinction between composer, sound engineer and musician (sometimes directer, etc as well). I like computer assisted composition, maybe even full out algorithmic composition but I also like controlling sounds in a more traditional and direct "instrumentalist" way. Clearly there can be plenty of overlap between those as well. Those can be very different things and if we are talking about languages it may make sense to wonder whether we may not need different languages for different things... perhaps for different people with different ways of thinking as well.
_________________
Kassen |
|
|
Back to top
|
|
|
manaris
Joined: Oct 24, 2008
Posts: 8
Location: Charleston, SC
|
| Posted: Thu Oct 30, 2008 5:54 am Post subject:
|
|
|
| Kassen wrote: | | I'll have a look at those, I don't know enough about Python to say anything about some of the more in-depth suggestions that have been made. |
If and when you find time, consider playing with the first tutorial. 20 mins or so should be enough - copy-n-paste the examples into the interpreter. You may discover that you already know Python. People report a 5-10 times increase in productivity. Fun, fun, fun!
| Kassen wrote: | | For any book about "how to be a computer musician" we would need to establish exactly what a "computer musician" is. Computers have this tendency to blur the distinction between composer, sound engineer and musician (sometimes directer, etc as well). I like computer assisted composition, maybe even full out algorithmic composition but I also like controlling sounds in a more traditional and direct "instrumentalist" way. |
Great point. These sound like different chapters in this hypothetical textbook. They are great "head fakes" for elegant computational ideas. Starting with the simpler and moving to the more elegant. But then again, who has time for such an undertaking... |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Thu Oct 30, 2008 9:47 am Post subject:
|
|
|
Yeah, I'll have a serious look. I'm interested in Python even if I do think that -at times- brackets can be a advantage instead of a burden. I just don't think that doing DSP in straight Python would be such a great idea and unlike our friend James Dewdrop (a SC programmer who occasionally posts here on matters like these) I do feel it's a clear advantage to be able to do DSP and music in the same language, in the same file and -if need be- on the same level.
Right now a big topic in ChucK is garbage collection; this is important to me because no GC means recursion is a risky option (even more risky then normally). This limits our options, I do feel that recursion can form a analogy for many musical processes. In that way the language (or system) we elect to use should line up with our thoughts. While I would read the kind of book you suggested I'm personally more interested in a general book about programming and musical structures. Such a book could use Python... or it could use pseudo code, it might also use a mixture of different languages to illustrate the underlying ideas, perhaps it could be written by different authors.
I'm not sure such a book exists. I commented on this idea a few times on the toplap ( http://toplap.org/forums.html/Main_Page ) mailing list. This list is full of people who express their musical ideas in programs directly, as a way of performing on stage, but there seems to be very little concious notion of *how* we go from musical ideas to code... of what properties code would have to be pleasant to listen to. One might argue that this is a lost battle as tastes differ so widely but in reality we do know quite a bit about what people find interesting to hear. There is a certain balance between the expected and the surprising, for example. There are themes (in whatever sense, this could be a returning timbre) and there are things we can say about what we can do to a theme and still find it recognisable as a variation.
Code, I find, is very confrontational. You need to say everything you mean to say (and no more) and you need to be exact in your expression. Peer-review of papers is one thing but parsers and compilers are quite another, IMHO, They are there to have no mercy at all on reasoning errors or unfounded assumptions, never mind typo's. For that reason I think a -as complete as possible- look at music from a computer science perspective could be very interesting indeed. You can ask who has time for that.... I'd also ask whether we have any chance at all of completing it (I'm not even sure we could even answer that question) but even attempting a part of such a project does sound like a very worthwhile idea to me.
Are we off-topic and into the proverbial fire yet? :¬)
_________________
Kassen |
|
|
Back to top
|
|
|
Acoustic Interloper
Joined: Jul 07, 2007
Posts: 2081
Location: Berks County, PA
Audio files: 90
|
| Posted: Thu Nov 27, 2008 11:37 am Post subject:
|
|
|
Ah, looks like I have a thread to catch up on, maybe during the winter "break," although the break will be mostly catching up on work, it seems.
Having left industry after 30 years to go into cs undergrad and master's teaching at a state university -- i've done this part time off and on for the last 22 years -- i will probably get some students involved with chuck in time. But, i have some issues with chuck, mostly having to do with implementation rather than syntax or language constructs. I am looking at advanced undergrad and grad application, or perhaps a dual course with the music dept, not introductory programming pedagogy, by the way.
There are a couple reasons that i have renewed interest in a PyChuck like toolset. One is that a friend whose taste I trust, looked at making Chuck work in a 64 bit Linux environment, and found some design / implementation hacks that put him off. I haven't looked and don't presume to judge, although I do trust his taste.
My own motivation is wanting to have a means to glue music (MIDI and audio) data streams together on an embedded hardware platform, probably with hardware DSPs, but more significantly, without any of these latency ridden Windoze/OSX/Linux operating systems. Just a bare bones real-time monitor, and a cross compiler / toolset for gluing together signal processing libraries into dataflows. In fact, probably an interpreter on the run time platform as well, not in the real-time critical path, but there to do on-the-fly signal path gluing. I suppose there could be a small footprint Linux processor on the board -- why not? -- that mostly connects signal flow libraries in the non-Linux-signal-flow processors.
Obviously, Chuck would be a candidate, but this would presumably be a new Chuck compiler, since it would have to distribute signal flows across multiple DSPs.
Why ChucK? Well, maybe for reuse of resulting music code, but that's not my prime motivator. I want low latency and ease of use for me as a musician, and a research vehicle.
I think putting a Python interpreter that can string together signal flows would be a more flexible, modular choice. i guess I want a test bed for experiments, and not necessarily a language. Besides, Python does have lots of nice features.
Python could readily connect to a signal flow architecture like Gstreamer. Gstreamer is about right conceptually, although there is a lot of parochial GNU Glib library crap in there to make C look like an O-O language (sort of), that (to me) just makes for more doc reading and work. I'm not sure reuse of GStreamer is worth the cost in acclimation. But, the architectural idea seems right to me.
EDIT: Looks like a Python-Gstreamer API has been going on for the last 4.5 years, not much documentation or indication of maturity, though. Probably pretty green.
Gotta go get ready for Thanksgiving dinner. I've have to comb the thread later. Interesting thread.
_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks. |
|
|
Back to top
|
|
|
Frostburn
Joined: Dec 12, 2007
Posts: 255
Location: Finland
Audio files: 9
|
|
|
Back to top
|
|
|
Frostburn
Joined: Dec 12, 2007
Posts: 255
Location: Finland
Audio files: 9
|
| Posted: Wed Dec 10, 2008 3:07 pm Post subject:
|
|
|
I just finished reading the discussion you had there while I was away.
Great ideas there guys. :) I don't mind the thread-highjack. If it's about music, Python or a ChucKy way of doing things I'm glad to be part of the discussion.
An easy-to-pick-up python-like audio programming environment seems to have an audience out there :). And writing a book about it and the ideology behind it as manaris suggested would really be a blast.
There are still miles to go to reach such goals and I'm not sure if PyChucK as a Python module even has the potency to fully get to it. The issues it's having with real-time and thread safety are quite nasty at the moment. However the number of useful and mature Python modules is great and the interplay they could have with a modular audio processors is full of promise. I hear modules like PyGame doing guite nicely in spite of their real timy nature so I'll keep trying once my time and energy are free of their current obligations.
Other direction I might pursue is what I'd call "ChucKpy", an effort to embed Python into ChucK as it stands today. The ChucK source however seems a bit hacky so I'm not confident if I can understand it well enough...
Yet another way to go would be writing an audio processing engine based around JACK for good real-time performance and implementing the "glue" with embedded Python talking in a ChucKian accent. It would in any case be much lighter than a Python module and the syntax nor the features wouldn't be restricted to "pure Python only".
_________________
To boldly go where no man has bothered to go before. |
|
|
Back to top
|
|
|
telstarmagikistferrari
Joined: Jun 16, 2008
Posts: 280
Location: Indianapolis, Indiana
Audio files: 43
|
| Posted: Thu Dec 11, 2008 4:36 pm Post subject:
|
|
|
great thread, thanks everyone for the discussion. beyond my level of sophistication in parts, but very educational in others.
good reading. it's stuff like this that makes the internet so powerful (to a musician, artist, scholar,friend such as myself). |
|
|
Back to top
|
|
|
Acoustic Interloper
Joined: Jul 07, 2007
Posts: 2081
Location: Berks County, PA
Audio files: 90
|
| Posted: Sat Jan 24, 2009 1:08 pm Post subject:
|
|
|
| manaris wrote: | | You know, being able to access even a subset of ChucK through Python syntax (either embedding Python within ChucK or the other way around) would be really useful. I am thinking of a CS1-level class in Computer music -- having access to the gentleness of Python syntax for any music making framework would be SO motivating to students. (The ChucK syntax is killing them.) A wonderful service to the community, IMHO, even if partial. |
Finally got around to catching up on this thread. If OSC packets via UDP datagrams between ChucK and Python are sufficient for your needs, there's discussion from last summer on this thread, and some code posted on August 11, 2008, on page 6 of that thread. OSC/UDP within a single machine is plenty responsive for what I'm doing with Python <-> ChucK. There are also examples of Supercollider (thanks to James) and Max/MSP connected to ChucK.
I've submitted a paper to NIME 2009 on the Python chess-to-music program (with acknowledgements to contributors to the above thread), that I'll post either after it's been published by NIME, or rejected by them 
_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks. |
|
|
Back to top
|
|
|
|
Forum index » DIY Hardware and Software » ChucK programming language
FAQ
Calendar
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Chat Room
