| Computer music benefits from both a computer science approach and a music-driven approach to the design of software sound synthesis systems.
I try to keep up with all the systems, at least enough to know what they are capable of, and as far as I can tell I have to agree with Victor, nothing else has the basic power of Csound. The music power is certainly why I use it!
I think however that there is real potential for something that would have the power of Csound and the elegance of ChucK or the musician-friendliness of Max or PD. Possibly SuperCollider could evolve in that direction.
I rather thank that if the LISP language had a widely accepted single implementation like Python and Java do, then Common Music/Common Lisp Music could become that system. But LISP is not "together" enough at this time (no, I'm not worried it would be too hard for musicians to learn). But, it's fast enough and certainly powerful enough. And these systems continue to evolve. CM in particular is way ahead of where it was just a few years ago. I hope to integrate Csound 5 directly with CM.
Another approach would be to take a large number of unit generators and opcodes written in C or C++ and embed them directly into an interpreted language with a just-in-time compiler. Both Python and Lua could definitely support this. It would then not be necessary to write a parser or invent a new language. From time to time I do some work on a system like this. I lean towards Lua becuase Lua JIT code runs faster than Python JIT (Psyco) code, and Lua is easier to distribute. The main stopping point is that the basic interface definitions and DSP graph implementation have to be exactly right -- every time I turn around and look at what Barry Vercoe did, it looks better and better.
Regards,
Mike
-----Original Message-----
>From: Victor Lazzarini
>Sent: Mar 24, 2006 1:19 PM
>To: csound@lists.bath.ac.uk
>Subject: [Csnd] ChucK?? (was Re: [Csnd] The future of computer music? (was Re: [Csnd] The future of winsound))
>
>But depending on what you are doing, dynamic voice allocation in
>Csound can be done by just sending (realtime or otherwise) events into it.
>
>Chuck does not even begin to touch the richness in sound synthesis and
>processing allowed by csound. In fact, as far as I can see it does not
>even compare to SuperCollider (or PD for that matter).
>
>In the battle of so-called 'elegance' and sound-production, I will always
>look for the latter. But then again that's the way I was schooled and
>don't expect anyone to feel that way (and that's why I use csound...)
>
>Victor
>
>At 18:09 24/03/2006, you wrote:
>>Victor Lazzarini wrote:
>>>yes, but that is way limited if compared to Csound.
>>
>>Depends on how you look at it.
>>
>>Chucks language is far more elegant and you can do extremely complicated
>>stuff in few lines of code. I needed dynamic voice allocation and
>>implemented it in a day in chuck. Part of this included writing a stack
>>(LIFO) class, which was piece of cake. I wouldn't wanna look at the
>>spaghetti that would be a csound implementation of a stack.
>>
>>That said I'm still using csound as my main synth, mainly because of
>>effeciency.
>>
>>--
>>peace, love & harmony
>>Atte
>>
>>http://www.atte.dk
>>--
>>Send bugs reports to this list.
>>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>
>Victor Lazzarini
>Music Technology Laboratory
>Music Department
>National University of Ireland, Maynooth
>
>--
>Send bugs reports to this list.
>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
|