I read: http://pygame.org/ http://www.speech.kth.se/snack/ http://www.visionegg.org/ for starts, HTH x -- chris(a)lo-res.org Postmodernism is german romanticism with better http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)

On 2004-06-03 14:54:56 +0000 Cournapeau David <cournape(a)enst.fr> wrote: www.squeak.org It's not Python {but there are bindings available {should you need them}}. ...Should take you a couple of hours. If you really have your heart set on python: http://pythoncard.sourceforge.net

Hi, This subject reminded me that some time ago, a friend of mine mentioned that he had read a message of James McCartney (SuperCollider) in which James talked about his decision of having implemented his own OO language for SC rather than reusing an existing, generic, OO language. I looked for this message but could not find it, so I wrote James directly, because I thought it might be an interesting addition to this thread. James gave me a very extensive reply, which I forward to the list. Maarten --------------------------------------------------------------------->8 Begin forwarded message: Date: Thu, 3 Jun 2004 15:34:01 -0700 From: james mccartney <asynth(a)audiosynth.com> To: mdeboer(a)iua.upf.es Subject: Re: supercollider vs generic OO languages I've included the original text file you are probably looking for below. Here's some current remarks.. First of all I'm not sure many folks had heard about Python and definitely not Ruby when I began writing SuperCollider in 1994. At that time Python was not the language it is now. So those languages weren't available as choices. Second, neither of those languages are meant for real time. SC has a real time garbage collector, constant time message lookup and various other features designed for real time operation. Python uses reference counting GC which has unbounded time cost when an object is freed. Third SC was written specifically for writing music and audio processes. The math system and behaviour of basic methods in the system were designed for this. I looked into what it might take to make the Ruby math system support building synthesis graphs the way that SC does, and it did not seem like an easy thing to do. I think that as languages SC is certainly comparable in strength to Python and Ruby. SC has the most flexible argument passing of any of them. Any or all arguments can be passed either positionally or by keyword to any function. Keyword arguments can occur in any order. Functions can be passed more or fewer arguments than defined. Unspecified arguments can have default values. Functions can be called with unspecified arguments bound dynamically in the caller's environment. Excess arguments can be collected in arrays. SC has closures and coroutines and is more consistent about their semantics than either Python or Ruby. SC's object model is based on Smalltalk but has also borrowed from Scheme, NewtonScript, J, Icon. SC has borrowed some syntax features from Ruby which happened to have co-evolved with a similar syntax. SC no longer has to run at interrupt level as it did on OS 9, but many of the issues for real time operation are the same. Rather than struggle with a language not designed for real time they should investigate using SuperCollider. It has been ported to linux. ---- SuperCollider 2.0 Why SuperCollider 2.0 ? SuperCollider version 2.0 is a new programming language. Why invent a new language and not use an existing language? Computer music composition is a specification problem. Both sound synthesis and the composition of sounds are complex problems and demand a language which is highly expressive in order to deal with that complexity. Real time signal processing is a problem demanding an efficient implementation with bounded time operations. There was no language combining the features I wanted and needed for doing digital music synthesis. The SuperCollider language is most like Smalltalk. Everything is an object. It has class objects, methods, dynamic typing, full closures, default arguments, variable length argument lists, multiple assignment, etc. The implementation provides fast, constant time method lookup, real time garbage collection, and stack allocation of most function contexts while maintaining full closure semantics. The SuperCollider virtual machine is designed so that it can be run at interrupt level. There was no other language readily available that was high level, real time and capable of running at interrupt level. SuperCollider version 1.0 was completely rewritten to make it both more expressive and more efficient. This required rethinking the implementation in light of the experience of the first version. It is my opinion that the new version has benefitted significantly from this rethink. It is not simply version 1.0 with more features. Why use a text based language rather than a graphical language? There are at least two answers to this. Dynamism: Most graphical synthesis environments use statically allocated unit generators. In SuperCollider, the user can create structures which spawn events dynamically and in a nested fashion. Patches can be built dynamically and parameterized not just by floating point numbers from a static score, but by other graphs of unit generators as well. Or you can construct patches algorithmically on the fly. This kind of fluidity is not possible in a language with statically allocated unit generators. Brevity: In SuperCollider, symmetries in a patch can be exploited by either multichannel expansion or programmatic patch building. For example, the following short program generates a patch of 49 unit generators. In a graphical program this might require a significant amount of time and space to wire up. Another advantage is that the size of the patch below can be easily expanded or contracted just by changing a few constants. ( { // 10 voices of a random sine percussion sound : s = Mix.ar(Array.fill(10, { Resonz.ar(Dust.ar(0.2, 50), 200 + 3000.0.rand, 0.003)}) ); // reverb predelay time : z = DelayN.ar(s, 0.048); // 7 length modulated comb delays in parallel : y = Mix.ar(Array.fill(7,{ CombL.ar(z, 0.1, LFNoise1.kr(0.1.rand, 0.04, 0.05), 15) })); // two parallel chains of 4 allpass delays (8 total) : 4.do({ y = AllpassN.ar(y, 0.050, [0.050.rand, 0.050.rand], 1) }); // add original sound to reverb and play it : s+(0.2*y) }.play )