Csound and other synthesis systems

Csound and other synthesis systems

Date	1999-06-16 13:26
From	Michael Gogins
Subject	Csound and other synthesis systems
	Again I mount my soapbox to rant about desired changes in Csound. Before you say I just talk about them but don't do them, take note that I have done some of them in AXCsound/JCsound, which are open source. This particular rant is occasioned by my audition of Buzz and Generator. Buzz, for those of you who don't follow software synthesis on the Web, is a "tracker" synthesizer, and is free. Generator is a commercial modular software synthesizer, and costs money. Both programs run on Windows. Other programs of note that I don't talk about here are SuperCollider and GrainWave. Buzz is a software synthesizer for tracker files. The tracker files are similar to MIDI files except that they can contain embedded sound samples. It appears to be an idiosyncratic binary file format. I don't know where it comes from (but I will find out). Buzz can be found at http://www.buzz2.com. Buzz has a simple but effective graphical user interface for (a) editing sequences, (b) editing loops for sequences, (c) cataloging samples, and last but not least, (d) wiring unit generators together. The unit generators (called "machines" generically or "generators" and "effects" for signal sources and signal processors) are Windows DLLs, plugins in other words, and can be written by anybody with the latest Microsoft compilers; they have a fairly simple design. Buzz automatically generates their simple-minded little GUIs for them. Buzz has an active community including developers of plugins as well as composers of songs, with a number of Web sites, you can get CDs containing tracker files and machines, and the thing actually sounds pretty good (it uses DirectX sound drivers and can accept soundfile input and write soundfile output as well as play in real time). There is no realtime MIDI note on performance (although there are realtime MIDI control messages) and no external API for programmatic control. Buzz's DSP capabilities have now gotten as far as the Karplus-Strong plucked string and some pretty extensive filtering, chorusing, delaying, and reverberating. Generator is a software emulation of analog patch-cord synthesizers. It is a very high quality product. It does low-latency real-time performance with MIDI note on control, can read and write input and output soundfiles, and has extensive facilities for user wiring of unit generators with a fancy, fancy GUI that emulates a Moog-style modular synthesizer. Generator's DSP facilities are very roughly comparable to Buzz's. Generator is VERY good at making interactive patches (not as powerful as Max/MSP, but much easier to "get" and use). Generator is planned to be able to act as a VST or ActiveX plugin. Currently, Csound offers substantially more musical capabilities than either of these products, which probably are fairly representative of the current state of the art, but it is looking increasingly creaky in the software engineering department. Csound is particarly strong in score format, time/frequency analysis and resynthesis, and physical modeling. Csound would quickly fall to the rear of the class if (a) Buzz got note on control and a simpler input file format, or (b) Generator got plugin unit generators and a more flexible input file format. At that point, people like me would scarf up Csound's unit generators and add them to a synthesizer framework that is more functional and easier to use, resulting in a best of breed musical instrument. Csound could be put firmly back at the leading edge of the state of the art if: Csound gets plugin unit generators and function tables with a SIMPLE, I mean REALLY simple, API. Csound gets double-precision signal processing (Buzz and Generator use floats). Csound gets low-latency MIDI and audio input and output that works more or less the same on its major platforms. Csound gets an at least semi-snazzy GUI including unit generator wiring. Csound gets an external API for programmatic control. Csound can act as a VST plugin. These features could be provided at moderate effort by: Making Csound into the DSP kernel of a Java software synthesizer. Evaluating JavaSound for all audio and MIDI input and output. Currently JavaSound lacks MIDI input but some independent developers are working on it. Adapting Russell Pinkston's PatchWork program (16 bit Windows program) to Java as a unit generator wiring form. The VST part is easy. What is needed here is a reasonable compromise between the power and amenability for experimentation of a bare-bones piece of academic UNIX software, and a user-friendly GUI and user-extensible plugin architecture, with realtime performance AND non-realtime soundfile rendering. This is the wonderful musical instrument that is evolving before our very eyes (and ears), and Csound already contains all the necessary guts for the thing. Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05205; 16 Jun 99 13:42 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uF1c-0001bD-00 for jpff@maths.bath.ac.uk; Wed, 16 Jun 1999 13:42:41 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id FAA01922 for music-dsp-outgoing; Wed, 16 Jun 1999 05:26:56 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from smtp0.mindspring.com (smtp0.mindspring.com [207.69.200.30]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id FAA01917 for ; Wed, 16 Jun 1999 05:26:54 -0700 (PDT) Received: from Realizer (user-2ive0lp.dialup.mindspring.com [165.247.2.185]) by smtp0.mindspring.com (8.8.5/8.8.5) with SMTP id IAA20595; Wed, 16 Jun 1999 08:26:43 -0400 (EDT) Message-ID: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> From: Michael Gogins To: music-dsp , CSOUND Subject: Csound and other synthesis systems Date: Wed, 16 Jun 1999 08:26:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu Again I mount my soapbox to rant about desired changes in Csound. Before you say I just talk about them but don't do them, take note that I have done some of them in AXCsound/JCsound, which are open source. This particular rant is occasioned by my audition of Buzz and Generator. Buzz, for those of you who don't follow software synthesis on the Web, is a "tracker" synthesizer, and is free. Generator is a commercial modular software synthesizer, and costs money. Both programs run on Windows. Other programs of note that I don't talk about here are SuperCollider and GrainWave. Buzz is a software synthesizer for tracker files. The tracker files are similar to MIDI files except that they can contain embedded sound samples. It appears to be an idiosyncratic binary file format. I don't know where it comes from (but I will find out). Buzz can be found at http://www.buzz2.com. Buzz has a simple but effective graphical user interface for (a) editing sequences, (b) editing loops for sequences, (c) cataloging samples, and last but not least, (d) wiring unit generators together. The unit generators (called "machines" generically or "generators" and "effects" for signal sources and signal processors) are Windows DLLs, plugins in other words, and can be written by anybody with the latest Microsoft compilers; they have a fairly simple design. Buzz automatically generates their simple-minded little GUIs for them. Buzz has an active community including developers of plugins as well as composers of songs, with a number of Web sites, you can get CDs containing tracker files and machines, and the thing actually sounds pretty good (it uses DirectX sound drivers and can accept soundfile input and write soundfile output as well as play in real time). There is no realtime MIDI note on performance (although there are realtime MIDI control messages) and no external API for programmatic control. Buzz's DSP capabilities have now gotten as far as the Karplus-Strong plucked string and some pretty extensive filtering, chorusing, delaying, and reverberating. Generator is a software emulation of analog patch-cord synthesizers. It is a very high quality product. It does low-latency real-time performance with MIDI note on control, can read and write input and output soundfiles, and has extensive facilities for user wiring of unit generators with a fancy, fancy GUI that emulates a Moog-style modular synthesizer. Generator's DSP facilities are very roughly comparable to Buzz's. Generator is VERY good at making interactive patches (not as powerful as Max/MSP, but much easier to "get" and use). Generator is planned to be able to act as a VST or ActiveX plugin. Currently, Csound offers substantially more musical capabilities than either of these products, which probably are fairly representative of the current state of the art, but it is looking increasingly creaky in the software engineering department. Csound is particarly strong in score format, time/frequency analysis and resynthesis, and physical modeling. Csound would quickly fall to the rear of the class if (a) Buzz got note on control and a simpler input file format, or (b) Generator got plugin unit generators and a more flexible input file format. At that point, people like me would scarf up Csound's unit generators and add them to a synthesizer framework that is more functional and easier to use, resulting in a best of breed musical instrument. Csound could be put firmly back at the leading edge of the state of the art if: Csound gets plugin unit generators and function tables with a SIMPLE, I mean REALLY simple, API. Csound gets double-precision signal processing (Buzz and Generator use floats). Csound gets low-latency MIDI and audio input and output that works more or less the same on its major platforms. Csound gets an at least semi-snazzy GUI including unit generator wiring. Csound gets an external API for programmatic control. Csound can act as a VST plugin. These features could be provided at moderate effort by: Making Csound into the DSP kernel of a Java software synthesizer. Evaluating JavaSound for all audio and MIDI input and output. Currently JavaSound lacks MIDI input but some independent developers are working on it. Adapting Russell Pinkston's PatchWork program (16 bit Windows program) to Java as a unit generator wiring form. The VST part is easy. What is needed here is a reasonable compromise between the power and amenability for experimentation of a bare-bones piece of academic UNIX software, and a user-friendly GUI and user-extensible plugin architecture, with realtime performance AND non-realtime soundfile rendering. This is the wonderful musical instrument that is evolving before our very eyes (and ears), and Csound already contains all the necessary guts for the thing. dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05328; 16 Jun 99 14:42 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uFxH-0007Oi-00 for jpff@maths.bath.ac.uk; Wed, 16 Jun 1999 14:42:15 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (OAA14388); Wed, 16 Jun 1999 14:32:55 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Wed, 16 Jun 1999 14:32:31 +0100 Received: from root@smtp-out-004.wanadoo.fr [193.252.19.87] by hermes via ESMTP (OAA06059); Wed, 16 Jun 1999 14:32:29 +0100 (BST) Received: from bmpl1-2-97.abo.wanadoo.fr [193.250.226.97] by wanadoo.fr for Paris Wed, 16 Jun 1999 15:32:30 +0200 (MET DST) Message-ID: <3767C406.2254ACDB@exbang.com> Date: Wed, 16 Jun 1999 15:34:35 +0000 From: Michel Jullian Reply-To: mj@exbang.com X-Mailer: Mozilla 4.04 (Macintosh; I; PPC) MIME-Version: 1.0 To: Michael Gogins CC: music-dsp , CSOUND Subject: Re: Csound and other synthesis systems References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Michael Gogins wrote: > Csound could be put firmly back at the leading edge of the state of the art > if: > > Csound gets plugin unit generators and function tables with a SIMPLE, I mean > REALLY simple, API. > Csound gets double-precision signal processing (Buzz and Generator use > floats). > Csound gets low-latency MIDI and audio input and output that works more or > less the same on its major platforms. > Csound gets an at least semi-snazzy GUI including unit generator wiring. > Csound gets an external API for programmatic control. > Csound can act as a VST plugin. This last point is _very_ good idea (the other points too). The VST 2 sdk, featuring full midi control of plugin synths (AFAIK it's the only plugin architecture with this feature) and a multiplatform GUI API, is due out any day now (watch out for it on steinberg's vst devs list ). Furthermore it is open not only to plugin developers but also to host developers, which should help it become a standard. What would be really nice would be if csound could "compile" orcs as vst plugins, somehow, instead of (or as well as) acting as a vst plugin. -- Greetings, Michel ......................................................................... Michel Jullian Directeur General email mj@exbang.com Exbang Industries S.A. Mas Chauvain route de Villeneuve tel +33(0) 499 529 878 Maurin 34970 Lattes France fax +33(0) 499 529 879 ......................................................................... Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05352; 16 Jun 99 14:53 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uG7c-0007Oz-00 for jpff@maths.bath.ac.uk; Wed, 16 Jun 1999 14:52:56 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id GAA02972 for music-dsp-outgoing; Wed, 16 Jun 1999 06:32:39 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from wanadoo.fr (root@smtp-out-004.wanadoo.fr [193.252.19.87]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id GAA02968 for ; Wed, 16 Jun 1999 06:32:37 -0700 (PDT) Received: from bmpl1-2-97.abo.wanadoo.fr [193.250.226.97] by wanadoo.fr for Paris Wed, 16 Jun 1999 15:32:30 +0200 (MET DST) Message-ID: <3767C406.2254ACDB@exbang.com> Date: Wed, 16 Jun 1999 15:34:35 +0000 From: Michel Jullian X-Mailer: Mozilla 4.04 (Macintosh; I; PPC) MIME-Version: 1.0 To: Michael Gogins CC: music-dsp , CSOUND Subject: Re: Csound and other synthesis systems References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu Michael Gogins wrote: > Csound could be put firmly back at the leading edge of the state of the art > if: > > Csound gets plugin unit generators and function tables with a SIMPLE, I mean > REALLY simple, API. > Csound gets double-precision signal processing (Buzz and Generator use > floats). > Csound gets low-latency MIDI and audio input and output that works more or > less the same on its major platforms. > Csound gets an at least semi-snazzy GUI including unit generator wiring. > Csound gets an external API for programmatic control. > Csound can act as a VST plugin. This last point is _very_ good idea (the other points too). The VST 2 sdk, featuring full midi control of plugin synths (AFAIK it's the only plugin architecture with this feature) and a multiplatform GUI API, is due out any day now (watch out for it on steinberg's vst devs list ). Furthermore it is open not only to plugin developers but also to host developers, which should help it become a standard. What would be really nice would be if csound could "compile" orcs as vst plugins, somehow, instead of (or as well as) acting as a vst plugin. -- Greetings, Michel ......................................................................... Michel Jullian Directeur General email mj@exbang.com Exbang Industries S.A. Mas Chauvain route de Villeneuve tel +33(0) 499 529 878 Maurin 34970 Lattes France fax +33(0) 499 529 879 ......................................................................... dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05407; 16 Jun 99 15:19 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uGXM-0007Px-00 for jpff@maths.bath.ac.uk; Wed, 16 Jun 1999 15:19:32 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (PAA15789); Wed, 16 Jun 1999 15:11:18 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Wed, 16 Jun 1999 15:11:04 +0100 Received: from root@smtp-out-005.wanadoo.fr [193.252.19.88] by hermes via ESMTP (PAA12608); Wed, 16 Jun 1999 15:11:02 +0100 (BST) Received: from bmpl1-1-203.abo.wanadoo.fr [193.250.98.203] by wanadoo.fr for Paris Wed, 16 Jun 1999 16:10:59 +0200 (MET DST) Message-ID: <3767CC76.141BF852@exbang.com> Date: Wed, 16 Jun 1999 16:10:36 +0000 From: Michel Jullian Reply-To: mj@exbang.com X-Mailer: Mozilla 4.04 (Macintosh; I; PPC) MIME-Version: 1.0 To: Jim Stevenson , music-dsp list , csound list Subject: Re: Csound and other synthesis systems References: <199906161344.GAA28889@eos.arc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Jim Stevenson wrote: > > Many of these suggestions would restrict csound to gui at best, and to > windows gui at worst. > > Please do not lock out those of us who prefer or need commands to program! Of course not. Allowing UG wiring via a GUI doesnt mean proscribing text editing of orcs : GUI and text could just be 2 ways to edit an orc file, IMO. As for the platform-specificity of the GUI, the author of these suggestions Michael Gogins suggested coding it in Java. Why not, a GUI doesnt have to be very fast. -- Greetings, Michel ......................................................................... Michel Jullian Directeur General email mj@exbang.com Exbang Industries S.A. Mas Chauvain route de Villeneuve tel +33(0) 499 529 878 Maurin 34970 Lattes France fax +33(0) 499 529 879 ......................................................................... Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05427; 16 Jun 99 15:24 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uGbt-0007QK-00 for jpff@maths.bath.ac.uk; Wed, 16 Jun 1999 15:24:13 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (PAA11779); Wed, 16 Jun 1999 15:20:13 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Wed, 16 Jun 1999 15:19:49 +0100 Received: from root@renoir.op.net [209.152.193.4] by hermes via ESMTP (PAA10378); Wed, 16 Jun 1999 15:19:46 +0100 (BST) Received: from someip.ppp.op.net (d-bm2-0d.ppp.op.net [209.152.194.45]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id KAA05406 for ; Wed, 16 Jun 1999 10:19:48 -0400 (EDT) Message-Id: <199906161419.KAA05406@renoir.op.net> To: csound@maths.ex.ac.uk Subject: Re: [quasimodo] version 0.1.6 released In-reply-to: Your message of "Tue, 15 Jun 1999 23:08:32 +0200." <3766C0D0.C0F98A98@intercom.es> Date: Wed, 16 Jun 1999 10:28:06 -0400 From: Paul Barton-Davis Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Josep M Comajuncosas wrote: [ Re Quasimodo ] >Hey that seems an interesting idea, but I'd rather suggest to >concentrate on improving the efficiency of existing software rather >than porting it to another (not multiplatform?) implementation. I'm >too used to Csound to learn another language to do approximately the >same thing. I don't think you understand. Quasimodo "is" Csound. It uses the same language. It uses the same opcode source code (with some minor tweaks). It uses the same score file language. It so happens that it can also support other languages too, but thats not relevant to your point. There isn't a reasonable way to "improve" Csound to run as a multithreaded application without tearing it to pieces (call Analog Devices if you want to talk to them about what thats like). If its not multithreaded, it can't ever have a decent UI and run in real time. It also can't use multi-processor systems effectively, and such systems are now very competitively priced (e.g. my dual PII-450 with the 9GB of the fastest SCSI disks around, CD-RW, 21" monitor, Jaz drive and SCSI tape drive cost less than my wife's 300MHz G3 powerbook). As for multiplatform, Quasimodo already runs on more platforms than any Windows or Mac program. It just doesn't run on Windows or Mac platforms. Thats because (1) those operating systems are proprietary and I don't write software for proprietary operating systems and (2) those operating systems don't offer all the services needed by a sophisticated real time multithreaded application. If the Csound source code offered a more incremental way to move to the kind of architecture that a program like Quasimodo needs, I would not have reimplemented the language(s), but it doesn't. You can make tweaks here and there, but its fundamentally limited by the assumptions that Vercoe made when he started, and by the coding approach used since then. --p Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05435; 16 Jun 99 15:27 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uGeg-0007Qd-00 for jpff@maths.bath.ac.uk; Wed, 16 Jun 1999 15:27:07 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id HAA03949 for music-dsp-outgoing; Wed, 16 Jun 1999 07:11:15 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from wanadoo.fr (root@smtp-out-005.wanadoo.fr [193.252.19.88]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id HAA03929 for ; Wed, 16 Jun 1999 07:11:09 -0700 (PDT) Received: from bmpl1-1-203.abo.wanadoo.fr [193.250.98.203] by wanadoo.fr for Paris Wed, 16 Jun 1999 16:10:59 +0200 (MET DST) Message-ID: <3767CC76.141BF852@exbang.com> Date: Wed, 16 Jun 1999 16:10:36 +0000 From: Michel Jullian X-Mailer: Mozilla 4.04 (Macintosh; I; PPC) MIME-Version: 1.0 To: Jim Stevenson , music-dsp list , csound list Subject: Re: Csound and other synthesis systems References: <199906161344.GAA28889@eos.arc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu Jim Stevenson wrote: > > Many of these suggestions would restrict csound to gui at best, and to > windows gui at worst. > > Please do not lock out those of us who prefer or need commands to program! Of course not. Allowing UG wiring via a GUI doesnt mean proscribing text editing of orcs : GUI and text could just be 2 ways to edit an orc file, IMO. As for the platform-specificity of the GUI, the author of these suggestions Michael Gogins suggested coding it in Java. Why not, a GUI doesnt have to be very fast. -- Greetings, Michel ......................................................................... Michel Jullian Directeur General email mj@exbang.com Exbang Industries S.A. Mas Chauvain route de Villeneuve tel +33(0) 499 529 878 Maurin 34970 Lattes France fax +33(0) 499 529 879 ......................................................................... dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05454; 16 Jun 99 15:32 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uGk3-0007RA-00 for jpff@maths.bath.ac.uk; Wed, 16 Jun 1999 15:32:39 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (PAA04050); Wed, 16 Jun 1999 15:27:51 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Wed, 16 Jun 1999 15:27:19 +0100 Received: from jaguars-int.cableinet.net [193.38.113.9] by hermes via SMTP (PAA07182); Wed, 16 Jun 1999 15:27:17 +0100 (BST) Received: (qmail 22118 invoked from network); 16 Jun 1999 14:23:16 -0000 Received: from unknown (HELO cableinet.co.uk) (194.117.146.59) by jaguars with SMTP; 16 Jun 1999 14:23:16 -0000 Message-ID: <3767C392.AD59CDAC@cableinet.co.uk> Date: Wed, 16 Jun 1999 15:32:34 +0000 From: rdbr03035 Organization: Composers Desktop Project X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 CC: music-dsp , CSOUND Subject: Re: Csound and other synthesis systems References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C406.2254ACDB@exbang.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk I agree that, taken direfctly in the conext of newer softsynths, Csound can look 'creaky', and it is indeed a tempting thought to revamp the whole thing to exploit the best of modern GUI/Plugin techniques. I have long thought about doing this myself 'as an exercise'. However, one vital aspect of Csound it it's extremely wide cross-platform character; and indeed it's core functionality as a console program has advantages for visually-impaired users. I don't think this could be done piece-meal. Basically, one would have to take the score and orc syntax and create a new engine from scratch, with multiple thread, dynamic libraries, and all the superstructure of a modern GUI-based application. Set against this is SAOL, which is ~fully~ public domain, and which is open for adaptation in any number of ways, has a more up-to-date language, and even has a means of compiling into a stand-alone application, thanks to 'cfront'. The legacy of SAOL scores is also arguably less significant, so compatibility at the command-line level is scarcely an issue. After all, SAOL is expected to be embedded in set-top boxes ere long! In the end, it depends how stronly the moral imperative that Csound ~should~ be at the 'leading edge' as a functioning softsynth, in the terms described. As it stands, it is a treasure-trove of dsp ideas, of unique educational value, a feature that I value highly. The issue then is one of modernity v fragmentation (unless it can be done exclusively using Java and/or TCL/TK), an issue which simply does not arise for SAOL. Csound ~is~ it's source code, but that is not strictly true of SAOL - 'saolc' is merely an example implementation. If we treat the score and orc syntax similarly, as a specification (as we can reasonably do), there is no reason why some new program cannot be written which implements it in a more modern form. The sticking point is then the title (in the legal sense), as my understanding is that ultimately this still belongs to MIT and Barry Vercoe. Richard Dobson Michel Jullian wrote: > > Michael Gogins wrote: > > > Csound could be put firmly back at the leading edge of the state of the art > > if: > > > > Csound gets plugin unit generators and function tables with a SIMPLE, I mean > > REALLY simple, API. > > Csound gets double-precision signal processing (Buzz and Generator use > > floats). > > Csound gets low-latency MIDI and audio input and output that works more or > > less the same on its major platforms. > > Csound gets an at least semi-snazzy GUI including unit generator wiring. > > Csound gets an external API for programmatic control. > > Csound can act as a VST plugin. > > This last point is _very_ good idea (the other points too). The VST 2 sdk, > featuring full midi control of plugin synths (AFAIK it's the only plugin > architecture with this feature) and a multiplatform GUI API, is due out any > day now (watch out for it on steinberg's vst devs list > ). Furthermore it is open not only to plugin > developers but also to host developers, which should help it become a standard. > > What would be really nice would be if csound could "compile" orcs as vst > plugins, somehow, instead of (or as well as) acting as a vst plugin. > > -- > Greetings, > Michel > ......................................................................... > Michel Jullian Directeur General email mj@exbang.com > Exbang Industries S.A. > Mas Chauvain route de Villeneuve tel +33(0) 499 529 878 > Maurin 34970 Lattes France fax +33(0) 499 529 879 > ......................................................................... Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05470; 16 Jun 99 15:37 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uGoH-0001hZ-00 for jpff@maths.bath.ac.uk; Wed, 16 Jun 1999 15:37:01 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (PAA09275); Wed, 16 Jun 1999 15:32:51 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Wed, 16 Jun 1999 15:32:33 +0100 Received: from root@renoir.op.net [209.152.193.4] by hermes via ESMTP (PAA05800); Wed, 16 Jun 1999 15:32:30 +0100 (BST) Received: from someip.ppp.op.net (d-bm2-0d.ppp.op.net [209.152.194.45]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id KAA06644 for ; Wed, 16 Jun 1999 10:32:36 -0400 (EDT) Message-Id: <199906161432.KAA06644@renoir.op.net> To: csound@maths.ex.ac.uk Subject: Re: Csound and other synthesis systems In-reply-to: Your message of "Wed, 16 Jun 1999 08:26:42 EDT." Date: Wed, 16 Jun 1999 10:40:54 -0400 From: Paul Barton-Davis Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Michael Gogins writes: >Csound could be put firmly back at the leading edge of the state of the art >if: > >Csound gets plugin unit generators and function tables with a SIMPLE, I mean >REALLY simple, API. this already exists for unit generators. I don't understand how you could want a simpler interface than the one they have already. Someone, I think it was you, actually allowed the Windows version to dynamically load opcodes. What more are you thinking of ? as for function tables, they are close, but the routines in Csound rely so totally on global variables that a plugin API for generators can't easily be concocted. I was suprised how much I had to rewrite of the table stuff for Quasimodo. But the way function tables are used within opcodes, for example, doesn't suffer from these problems. >Csound gets double-precision signal processing (Buzz and Generator use >floats). this has been discussed to death already. >Csound gets low-latency MIDI and audio input and output that works more or >less the same on its major platforms. this is a function of the platforms. the Linux version, for example, has approx 1ms latency for MIDI and audio input you ask it the right questions. the idea that Csound should try to take these matters into its own hands is terrifying. >Csound gets an at least semi-snazzy GUI including unit generator wiring. What cross-platform GUI kit do you propose for this ? Let me guess, it begins with a "J", right ? >Csound can act as a VST plugin. I could care less :) But I understand the interest in this. >What is needed here is a reasonable compromise between the power and >amenability for experimentation of a bare-bones piece of academic UNIX >software, and a user-friendly GUI and user-extensible plugin architecture, >with realtime performance AND non-realtime soundfile rendering. This is the >wonderful musical instrument that is evolving before our very eyes (and >ears), and Csound already contains all the necessary guts for the thing. Michael - I'm in full agreement with you, with the major exception that I have no interest in seeing Csound subsumed into a Java environment. I think that you see Java as a way to go truly cross-platform, which is admirable; I see Java as a way to limit the possibilites and hurt performance. I also don't share your interest in Windows and Mac platforms, for reasons I've outlined elsewhere, and so you have a set of goals with respect to things like VST that I don't share. However, for reasons I also outlined in a previous message, I don't believe that Csound as it is currently written is the right place to begin from. The opcodes are pure gold, but the rest of the scaffolding that holds them together is not what we should be working with. Thats at least part of why I wrote/am writing Quasimodo. --p Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05546; 16 Jun 99 16:13 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uHN2-0007So-00 for jpff@maths.bath.ac.uk; Wed, 16 Jun 1999 16:12:56 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (QAA10620); Wed, 16 Jun 1999 16:07:38 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Wed, 16 Jun 1999 16:07:26 +0100 Received: from neptune.lyrick.com [38.227.100.46] by hermes via ESMTP (QAA08892); Wed, 16 Jun 1999 16:07:25 +0100 (BST) Received: by neptune.lyrick.com with Internet Mail Service (5.5.2448.0) id ; Wed, 16 Jun 1999 10:07:33 -0500 Message-ID: <283AABB8FD0DD21187C200A0C995F5DEECAFEB@neptune.lyrick.com> From: David Boothe To: 'MiS' , csound@maths.ex.ac.uk Subject: RE: tablew business Date: Wed, 16 Jun 1999 10:07:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BEB809.F59310A8" Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BEB809.F59310A8 Content-Type: text/plain; charset="iso-8859-1" Initialize an empty table in the score with GEN02. Then use tablew to write to that table. Now, I've never used tablew myself, but if I were to try it, that is how I would start. -David. > -----Original Message----- > From: MiS [mailto:mseta@yahoo.com] > Sent: Wednesday, June 16, 1999 12:45 AM > To: csound@maths.ex.ac.uk > Subject: tablew business > > > He, > > According to the manual tablew is supposed to write continuously to a > table (I want to to do it at a-rate). I would like to recycle that > table using sndwarp. > > since tablew needs to write to an existing table is there a > GEN routine > that should be used ? > > I don't seem to be successful. An example would be appreciated. > > Michal. > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > ------_=_NextPart_001_01BEB809.F59310A8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: tablew business Initialize an empty table in the score with GEN02. = Then use tablew to write to that table. Now, I've never used tablew = myself, but if I were to try it, that is how I would start. -David. > -----Original Message----- > From: MiS [mailto:mseta@yahoo.com] > Sent: Wednesday, June 16, 1999 12:45 AM > To: csound@maths.ex.ac.uk > Subject: tablew business > > > He, > > According to the manual tablew is supposed to = write continuously to a > table (I want to to do it at a-rate). I = would like to recycle that > table using sndwarp. > > since tablew needs to write to an existing = table is there a > GEN routine > that should be used ? > > I don't seem to be successful. An example = would be appreciated. > > Michal. > = _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > ------_=_NextPart_001_01BEB809.F59310A8-- Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05572; 16 Jun 99 16:31 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uHf3-0001kh-00 for jpff@maths.bath.ac.uk; Wed, 16 Jun 1999 16:31:33 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (QAA17673); Wed, 16 Jun 1999 16:26:04 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Wed, 16 Jun 1999 16:25:50 +0100 Received: from root@renoir.op.net [209.152.193.4] by hermes via ESMTP (QAA15911); Wed, 16 Jun 1999 16:25:48 +0100 (BST) Received: from someip.ppp.op.net (d-bm2-0d.ppp.op.net [209.152.194.45]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id LAA12726 for ; Wed, 16 Jun 1999 11:25:54 -0400 (EDT) Message-Id: <199906161525.LAA12726@renoir.op.net> To: csound@maths.ex.ac.uk Subject: Re: Csound and other synthesis systems In-reply-to: Your message of "Wed, 16 Jun 1999 15:32:34 -0000." <3767C392.AD59CDAC@cableinet.co.uk> Date: Wed, 16 Jun 1999 11:34:13 -0400 From: Paul Barton-Davis Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk >I don't think this could be done piece-meal. Basically, one would have >to take the score and orc syntax and create a new engine from scratch, >with multiple thread, dynamic libraries, and all the superstructure of a >modern GUI-based application. I sound like a stuck record, but ... exactly what you describe can be found at http://www.op.net/~pbd/quasimodo :) It uses POSIX P.1003 threads for portability, and a (fast) GUI toolkit (GTK+) that has been ported to all major POSIX-like operating systems and recently to Windows as well. >Set against this is SAOL, which is ~fully~ public domain, and which is >open for adaptation in any number of ways, has a more up-to-date >language, and even has a means of compiling into a stand-alone >application, thanks to 'cfront'. The legacy of SAOL scores is also >arguably less significant, so compatibility at the command-line level is >scarcely an issue. After all, SAOL is expected to be embedded in set-top >boxes ere long! you refer to its adoption as part of MPEG-4. there are still some pretty theoretical substantial issues to deal with before MPEG-4 becomes a reality in set top boxes. In particular, there is no method at this time for MPEG-4 coding of existing music, other than its implicit use of non-MPEG-4 methods. >using Java and/or TCL/TK), an issue which simply does not arise for >SAOL. Csound ~is~ it's source code, but that is not strictly true of >SAOL - 'saolc' is merely an example implementation. and, as Eric has freely pointed out, not a particularly fast one. In my spare moments, such as they are, I have been working on merging the SAOL yacc grammar into Quasimodo, so that it will support SAOL as well. Its not terribly hard to do, given that I already have two languages parsers there already. >If we treat the score and orc syntax similarly, as a specification (as >we can reasonably do), there is no reason why some new program cannot be >written which implements it in a more modern form. Which is precisely what Nicola tried to do when he began work on his Yacc parser for Csound orchestras, and precisely what I finished as part of Quasimodo. Its worth noting that you cannot parse Csound orchestras without a complete list of known opcodes - a serious limitation of its Music N inheritance. I got close to getting away without the list, but some orc's by Russel Pinkston and Hans Mikelson soon blew that idea out the window. I have also done some work on the yacc grammar for scores, and it supports basic scores, but not more complex features such as ramping, np, pp etc. I also have no plans to ever add the macro systems to the parsers. There are much better macro processors out there like m4 that can be used to do the same thing (although they can't do floating point expression evaluation, but this should be part of Csound itself, not its macro language). --p Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05672; 16 Jun 99 17:02 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uI8u-0001m0-00 for jpff@maths.bath.ac.uk; Wed, 16 Jun 1999 17:02:24 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (QAA13649); Wed, 16 Jun 1999 16:58:34 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Wed, 16 Jun 1999 16:58:20 +0100 Received: from [139.130.48.118] by hermes via ESMTP (QAA04521); Wed, 16 Jun 1999 16:58:16 +0100 (BST) Received: from firstpr.com.au (wira.firstpr.com.au [203.36.57.201]) by gair.firstpr.com.au (8.8.7/8.8.7) with ESMTP id CAA12839; Thu, 17 Jun 1999 02:03:57 +1000 Message-ID: <3767C895.4B7F857A@firstpr.com.au> Date: Thu, 17 Jun 1999 01:53:57 +1000 From: Robin Whittle Organization: First Principles & Real World Interfaces X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: music-dsp@shoko.calarts.edu CC: CSOUND Subject: Re: Csound and other synthesis systems References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Michael Gogins mounted his soapbox on the limitations of Csound. He seemed to be focused on a Windows-based patchable-synthesiser view of software synthesis. Here's the view from my particular soapbox. There is much more to software synthesis and Csound than being like a Moog modular on MIDI, but such a thing would certainly be a marvel and would be widely used, including by me! There are those of us who do not want to run things on Windows if we can help it. (I find Windows a seriously unreliable and frustrating operating system, despite its creature comforts which I know and love. I have no interest in owning a Mac - too expensive and weird.) We want open-source free software which runs on an open-source operating system - most obviously Linux. We want all the compilers etc. to be open-source too. See these sites for more on "free" and "open-source" software: http://www.fsf.org/philosophy/philosophy.html http://www.opensource.org With a sufficiently motivated user community, the tools evolve well and are typically the best available at any price. This way, unless the code base is badly writen, we can modify and extend the programs as we choose, and feed those improvements back into the mainstream versions of that program. This is what has been done with Csound in recent years (with John Fitch doing a lot of the work), but there are limits beyond which it cannot be improved or changed. Don't even think about any significant changes to the Csound code base. Many who have looked closely at it have come away shaking their heads. It works at what it does. In many respects it is an elegant and unbeatably fast system. Parts of it can be tweaked. However it is not sufficiently well structured or well documented to allow any major conceptual change in its operation - internally or in terms of score, orchestra file, or unit-generator sructure. Although the unit-generator concept is a highly object oriented approach, the code itself is written in plain C (originally not ANSI C) to low standards of internal documentation. Csound's copyright is more restrictive than the the full GPL open-source arrangement which is being adopted for many of the most significant software projects today. The only attempt I am aware of to produce a Csound-compatible real-time graphic and MIDI controlled software synthesis system is Paul Barton-Davis' so-far solitary work on Quasimodo: http://www.op.net/~pbd/quasimodo/ It is early days yet. I did get a sound out of it two days ago - real-time GUI control of instrument parameters. This can be done via MIDI too, and it can output MIDI and input sound too . . . Paul is making rapid progress. We have just established a mailing list for those who are interested. It is a "hackers only" source code release - you have to compile it yourself, and there is a list of things you need to install beforehand. Quasimodo does not run on Windows or Mac and probably never will. It is a multi-threaded application ready for symmetrical mulitprocessing dual CPU machines (enabling the DSP stuff to run on one CPU and the user interface to run on another). It uses the latest techniques in C++ programming, including STL (Standard Container Library). My initial impression is that the structure is sound and the code-writing and documentation values are high. There seem to be types of people who are interested in investing the immense effort required to develop a usable software synthesis language / GUI real-time-synth: 1 - People like Paul Barton-Davis, a few other people and probably me who would only consider doing this in a purely open-source arrangement, and therefore not to sell the program on the shrink-wrap market. We rely on collaboration and other sources of funds. 2 - Those who are prepared to develop their own products alone, in Windows or Mac environments, and sell them to the masses who currently typically prefer these types of computer. These people need to raise capital, work alone, keep their source code secret and be concerned about musicians pirating their software. Their environment for software is not so flash in many respects. They are generally dependent on commercial compilers. Is the Mac ready for multiple CPUs? Windows NT supposedly is - but it is a crash-prone as Win98. They can only occasionally release updates to their software, while open-source people can release updates without any significant cost, delay or impediment. Only two of Michael's suggestions seem practical to me: > Csound gets low-latency MIDI and audio input and output that works > more or less the same on its major platforms. Hasn't this already been achieved by Gabriel Maldonado and John Fitch in the standard version of Csound? What latency problems are there? Csound is very tighly coded in its central loops. Maybe Windows ActiveX (I don't really know what this is) can provide sufficiently finely-diced and reliable CPU resources to make it run reliably with short buffers. > Adapting Russell Pinkston's PatchWork program (16 bit Windows > program) to Java as a unit generator wiring form. I guess such a patching system can be done in any language - but I would much rather write orchestra code than muck around with a GUI on that level! Patching instruments together, as Quasimodo does, with the GUI interface for each instrument defined it its part of the orchestra file . . . . yes I think can be very useful. Personally I think the Csound orchestra and score language should be left behind. If I was writing a system from scratch it would not use any special language at all - it would be a special framework for writing C++ to get on with real-time sound synthesis and all I/O and GUI things you might like to hang of that. It would do non-real-time work as well, and the same principles would probably apply to generating video images too. The C++ core elements would interface to things in other languages, for instance novel score languages or whatever you liked to create. I have a name for it: Topsy. I don't expect to start on it for some years to come - because I am involved in other things, and the knowlege I would require is immense: C++, STL, CORBA, GTK, SMP, P-Threads, not to mention some more DSP theory . . . . So I suggest looking at Quasimodo (and hence at Linux), or going against the flow on Windows and Mac and attempting an open-source project there. For those who make bold proposals about super-charging Csound itself with major changes to its functionality . . . did you ever see the movie "Repo Man"? Remember what happened shortly after the policeman is told "No . . . you don't want to look in the trunk!"? - Robin =============================================================== Robin Whittle rw@firstpr.com.au http://www.firstpr.com.au Heidelberg Heights, Melbourne, Australia First Principles Research and expression: Consulting and technical writing. Music. Internet music marketing. Telecommunications. Consumer advocacy in telecommunications, especially privacy. M-F relationships. Kinetic sculpture. Real World Electronics and software for music including: Interfaces Devil Fish mods for the TB-303, Akai sampler memory and Csound synthesis software. =============================================================== Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05761; 16 Jun 99 17:33 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uId7-0007Vk-00 for jpff@maths.bath.ac.uk; Wed, 16 Jun 1999 17:33:37 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (RAA02333); Wed, 16 Jun 1999 17:30:03 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Wed, 16 Jun 1999 17:29:48 +0100 Received: from front5.grolier.fr [194.158.96.55] by hermes via ESMTP (RAA14762); Wed, 16 Jun 1999 17:29:47 +0100 (BST) Received: from club-internet.fr (ppp-112-73.villette.club-internet.fr [194.158.112.73]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id SAA03866 for ; Wed, 16 Jun 1999 18:29:56 +0200 (MET DST) Message-ID: <3767D24F.3B8CFD95@club-internet.fr> Date: Wed, 16 Jun 1999 18:35:28 +0200 From: KH Reply-To: karmha@club-internet.fr X-Mailer: Mozilla 4.04 (Macintosh; I; PPC) MIME-Version: 1.0 To: "csound@maths.ex.ac.uk" Subject: Re: problem rescaling Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Hi Mikhail I tried out oscil1i with the same result... I think it must be the score, will try to fix it up with the most excellent "OpenMusic"! Ciao Karim Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05769; 16 Jun 99 17:36 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uIdy-0001na-00 for jpff@maths.bath.ac.uk; Wed, 16 Jun 1999 17:36:04 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id IAA05912 for music-dsp-outgoing; Wed, 16 Jun 1999 08:57:41 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from gair.firstpr.com.au ([139.130.48.118]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id IAA05905 for ; Wed, 16 Jun 1999 08:57:23 -0700 (PDT) Received: from firstpr.com.au (wira.firstpr.com.au [203.36.57.201]) by gair.firstpr.com.au (8.8.7/8.8.7) with ESMTP id CAA12839; Thu, 17 Jun 1999 02:03:57 +1000 Message-ID: <3767C895.4B7F857A@firstpr.com.au> Date: Thu, 17 Jun 1999 01:53:57 +1000 From: Robin Whittle Organization: First Principles & Real World Interfaces X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: music-dsp@shoko.calarts.edu CC: CSOUND Subject: Re: Csound and other synthesis systems References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu Michael Gogins mounted his soapbox on the limitations of Csound. He seemed to be focused on a Windows-based patchable-synthesiser view of software synthesis. Here's the view from my particular soapbox. There is much more to software synthesis and Csound than being like a Moog modular on MIDI, but such a thing would certainly be a marvel and would be widely used, including by me! There are those of us who do not want to run things on Windows if we can help it. (I find Windows a seriously unreliable and frustrating operating system, despite its creature comforts which I know and love. I have no interest in owning a Mac - too expensive and weird.) We want open-source free software which runs on an open-source operating system - most obviously Linux. We want all the compilers etc. to be open-source too. See these sites for more on "free" and "open-source" software: http://www.fsf.org/philosophy/philosophy.html http://www.opensource.org With a sufficiently motivated user community, the tools evolve well and are typically the best available at any price. This way, unless the code base is badly writen, we can modify and extend the programs as we choose, and feed those improvements back into the mainstream versions of that program. This is what has been done with Csound in recent years (with John Fitch doing a lot of the work), but there are limits beyond which it cannot be improved or changed. Don't even think about any significant changes to the Csound code base. Many who have looked closely at it have come away shaking their heads. It works at what it does. In many respects it is an elegant and unbeatably fast system. Parts of it can be tweaked. However it is not sufficiently well structured or well documented to allow any major conceptual change in its operation - internally or in terms of score, orchestra file, or unit-generator sructure. Although the unit-generator concept is a highly object oriented approach, the code itself is written in plain C (originally not ANSI C) to low standards of internal documentation. Csound's copyright is more restrictive than the the full GPL open-source arrangement which is being adopted for many of the most significant software projects today. The only attempt I am aware of to produce a Csound-compatible real-time graphic and MIDI controlled software synthesis system is Paul Barton-Davis' so-far solitary work on Quasimodo: http://www.op.net/~pbd/quasimodo/ It is early days yet. I did get a sound out of it two days ago - real-time GUI control of instrument parameters. This can be done via MIDI too, and it can output MIDI and input sound too . . . Paul is making rapid progress. We have just established a mailing list for those who are interested. It is a "hackers only" source code release - you have to compile it yourself, and there is a list of things you need to install beforehand. Quasimodo does not run on Windows or Mac and probably never will. It is a multi-threaded application ready for symmetrical mulitprocessing dual CPU machines (enabling the DSP stuff to run on one CPU and the user interface to run on another). It uses the latest techniques in C++ programming, including STL (Standard Container Library). My initial impression is that the structure is sound and the code-writing and documentation values are high. There seem to be types of people who are interested in investing the immense effort required to develop a usable software synthesis language / GUI real-time-synth: 1 - People like Paul Barton-Davis, a few other people and probably me who would only consider doing this in a purely open-source arrangement, and therefore not to sell the program on the shrink-wrap market. We rely on collaboration and other sources of funds. 2 - Those who are prepared to develop their own products alone, in Windows or Mac environments, and sell them to the masses who currently typically prefer these types of computer. These people need to raise capital, work alone, keep their source code secret and be concerned about musicians pirating their software. Their environment for software is not so flash in many respects. They are generally dependent on commercial compilers. Is the Mac ready for multiple CPUs? Windows NT supposedly is - but it is a crash-prone as Win98. They can only occasionally release updates to their software, while open-source people can release updates without any significant cost, delay or impediment. Only two of Michael's suggestions seem practical to me: > Csound gets low-latency MIDI and audio input and output that works > more or less the same on its major platforms. Hasn't this already been achieved by Gabriel Maldonado and John Fitch in the standard version of Csound? What latency problems are there? Csound is very tighly coded in its central loops. Maybe Windows ActiveX (I don't really know what this is) can provide sufficiently finely-diced and reliable CPU resources to make it run reliably with short buffers. > Adapting Russell Pinkston's PatchWork program (16 bit Windows > program) to Java as a unit generator wiring form. I guess such a patching system can be done in any language - but I would much rather write orchestra code than muck around with a GUI on that level! Patching instruments together, as Quasimodo does, with the GUI interface for each instrument defined it its part of the orchestra file . . . . yes I think can be very useful. Personally I think the Csound orchestra and score language should be left behind. If I was writing a system from scratch it would not use any special language at all - it would be a special framework for writing C++ to get on with real-time sound synthesis and all I/O and GUI things you might like to hang of that. It would do non-real-time work as well, and the same principles would probably apply to generating video images too. The C++ core elements would interface to things in other languages, for instance novel score languages or whatever you liked to create. I have a name for it: Topsy. I don't expect to start on it for some years to come - because I am involved in other things, and the knowlege I would require is immense: C++, STL, CORBA, GTK, SMP, P-Threads, not to mention some more DSP theory . . . . So I suggest looking at Quasimodo (and hence at Linux), or going against the flow on Windows and Mac and attempting an open-source project there. For those who make bold proposals about super-charging Csound itself with major changes to its functionality . . . did you ever see the movie "Repo Man"? Remember what happened shortly after the policeman is told "No . . . you don't want to look in the trunk!"? - Robin =============================================================== Robin Whittle rw@firstpr.com.au http://www.firstpr.com.au Heidelberg Heights, Melbourne, Australia First Principles Research and expression: Consulting and technical writing. Music. Internet music marketing. Telecommunications. Consumer advocacy in telecommunications, especially privacy. M-F relationships. Kinetic sculpture. Real World Electronics and software for music including: Interfaces Devil Fish mods for the TB-303, Akai sampler memory and Csound synthesis software. =============================================================== dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05940; 16 Jun 99 18:45 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uJkV-0007XO-00 for jpff@maths.bath.ac.uk; Wed, 16 Jun 1999 18:45:20 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id NAA11467 for music-dsp-outgoing; Tue, 15 Jun 1999 13:45:20 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from renoir.op.net (renoir.op.net [209.152.193.4]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id NAA11459 for ; Tue, 15 Jun 1999 13:45:08 -0700 (PDT) Received: from op.net (d-bm2-1d.ppp.op.net [209.152.194.61]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id QAA25100; Tue, 15 Jun 1999 16:44:17 -0400 (EDT) Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id QAA02163; Tue, 15 Jun 1999 16:52:24 -0400 Date: Tue, 15 Jun 1999 16:52:24 -0400 Message-Id: <199906152052.QAA02163@op.net> From: Paul Barton-Davis To: csound-unix-dev@ilogic.com.au, csound@maths.ex.ac.uk, music-dsp@shoko.calarts.edu Subject: [quasimodo] quasimodo development mailing list now running Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu To subscribe, send me your email address. The forum is not moderated, but membership is. --pbd dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa05969; 16 Jun 99 18:57 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uJwG-0007Xm-00 for jpff@maths.bath.ac.uk; Wed, 16 Jun 1999 18:57:28 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (SAA04218); Wed, 16 Jun 1999 18:52:41 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Wed, 16 Jun 1999 18:52:30 +0100 Received: from ares.flash.net [209.30.0.41] by hermes via ESMTP (SAA01784); Wed, 16 Jun 1999 18:52:28 +0100 (BST) Received: from bigfoot.com (p234-122.atnt1.dialup.ftw1.flash.net [209.30.234.122]) by ares.flash.net (8.9.3/8.9.3) with ESMTP id MAA21867; Wed, 16 Jun 1999 12:51:36 -0500 (CDT) Message-ID: <3767E49F.E1679F6B@bigfoot.com> Date: Wed, 16 Jun 1999 12:53:35 -0500 From: pete moss Organization: pete moss GmbH X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Robin Whittle CC: music-dsp@shoko.calarts.edu, CSOUND Subject: Re: Csound and other synthesis systems References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C895.4B7F857A@firstpr.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk isnt that what cmusic does? except with c, (no ++). :P Robin Whittle wrote: > Personally I think the Csound orchestra and score language should be > left behind. If I was writing a system from scratch it would not use > any special language at all - it would be a special framework for > writing C++ to get on with real-time sound synthesis and all I/O and > GUI things you might like to hang of that. It would do non-real-time > work as well, and the same principles would probably apply to > generating video images too. The C++ core elements would interface to > things in other languages, for instance novel score languages or > whatever you liked to create. Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06113; 16 Jun 99 19:18 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uKGE-0001r9-00 for jpff@maths.bath.ac.uk; Wed, 16 Jun 1999 19:18:06 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id KAA09923 for music-dsp-outgoing; Wed, 16 Jun 1999 10:52:39 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from ares.flash.net (ares.flash.net [209.30.0.41]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id KAA09918 for ; Wed, 16 Jun 1999 10:52:36 -0700 (PDT) Received: from bigfoot.com (p234-122.atnt1.dialup.ftw1.flash.net [209.30.234.122]) by ares.flash.net (8.9.3/8.9.3) with ESMTP id MAA21867; Wed, 16 Jun 1999 12:51:36 -0500 (CDT) Message-ID: <3767E49F.E1679F6B@bigfoot.com> Date: Wed, 16 Jun 1999 12:53:35 -0500 From: pete moss Organization: pete moss GmbH X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Robin Whittle CC: music-dsp@shoko.calarts.edu, CSOUND Subject: Re: Csound and other synthesis systems References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C895.4B7F857A@firstpr.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu isnt that what cmusic does? except with c, (no ++). :P Robin Whittle wrote: > Personally I think the Csound orchestra and score language should be > left behind. If I was writing a system from scratch it would not use > any special language at all - it would be a special framework for > writing C++ to get on with real-time sound synthesis and all I/O and > GUI things you might like to hang of that. It would do non-real-time > work as well, and the same principles would probably apply to > generating video images too. The C++ core elements would interface to > things in other languages, for instance novel score languages or > whatever you liked to create. dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06385; 16 Jun 99 20:47 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uLeY-0007aV-00 for jpff@maths.bath.ac.uk; Wed, 16 Jun 1999 20:47:18 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id MAA12155 for music-dsp-outgoing; Wed, 16 Jun 1999 12:26:40 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id MAA12148 for ; Wed, 16 Jun 1999 12:26:38 -0700 (PDT) Received: from [24.93.53.130] ([24.93.53.130]) by Mail.austin.rr.com with Microsoft SMTPSVC(5.5.1875.185.18); Wed, 16 Jun 1999 14:23:39 -0500 X-Sender: asynth@mail.io.com Message-Id: In-Reply-To: <3767C895.4B7F857A@firstpr.com.au> References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Jun 1999 14:29:27 -0600 To: music-dsp@shoko.calarts.edu From: James McCartney Subject: Re: Csound and other synthesis systems Cc: CSOUND Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu At 9:53 AM -0600 6/16/99, Robin Whittle wrote: >I guess such a patching system can be done in any language - but I >would much rather write orchestra code than muck around with a GUI on >that level! Patching instruments together, as Quasimodo does, with >the GUI interface for each instrument defined it its part of the >orchestra file . . . . yes I think can be very useful. > > >Personally I think the Csound orchestra and score language should be >left behind. If I was writing a system from scratch it would not use >any special language at all - it would be a special framework for >writing C++ to get on with real-time sound synthesis and all I/O and >GUI things you might like to hang of that. Computer music software can be a lot more than just a synth engine of statically allocated ugens attached to a GUI. This framework is just too limiting compared to what is possible. If this is the vision of what is ideal then I think you have not brainstormed enough about what the real interesting problems are. There is a lot more I want to "hang on" my DSP engine than a GUI. Once you get your ideal system how will you attach interesting behaviours to it? Using C++ to write intelligent players or gesture mappings, or list processing score manipulation would be very painful. I think many people do not still grok the kind of things you can do with a dynamic system like SC or Kyma which is why so many of the same kind of system keep coming out: GUI+DSP but no brains. In SC, you can write an algorithmic process to build your patch in real time, e.g. mapping velocity to how complex a patch you build. Values in your score can themselves be patches that plug into your instrument input. For example you could have a note in your score be a patch of ugens. Then that voice's patch will get built with that sub-patch plugged into its input instead of just a float value. Instruments can spawn sub patches recursively to any depth. etc.. That is why I think having a language is important. There is only so much you can do with a static framework. Static frameworks are not much better than just having cheap sound hardware. A powerful language gives you a lot more ability to do what computers can be good at which is manipulating abstractions. And C++ is just not a very highly abstract language. --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06514; 16 Jun 99 21:40 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uMUA-0001uI-00 for jpff@maths.bath.ac.uk; Wed, 16 Jun 1999 21:40:38 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (VAA06460); Wed, 16 Jun 1999 21:37:02 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Wed, 16 Jun 1999 21:36:50 +0100 Received: from mtv@pavo-1.U.Arizona.EDU [128.196.137.195] by hermes via ESMTP (VAA08913); Wed, 16 Jun 1999 21:36:49 +0100 (BST) Received: from localhost (mtv@localhost) by pavo.U.Arizona.EDU (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id NAA04541; Wed, 16 Jun 1999 13:36:45 -0700 (MST) Date: Wed, 16 Jun 1999 13:36:45 -0700 (MST) From: Mark T Vigorito To: Michael Gogins cc: music-dsp , CSOUND Subject: Re: Csound and other synthesis systems In-Reply-To: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk On Wed, 16 Jun 1999, Michael Gogins wrote: [...] > Csound can act as a VST plugin. > [...] > The VST part is easy. > I am very interested in this (I use Samplitude Studio). What else needs to be done? I was under the impression that your AXCsound was already a step in that direction... Cheers, Mark Vigorito mtv@u.arizona.edu Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06587; 16 Jun 99 22:24 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uNAG-0001vI-00 for jpff@maths.bath.ac.uk; Wed, 16 Jun 1999 22:24:08 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (WAA10890); Wed, 16 Jun 1999 22:20:15 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Wed, 16 Jun 1999 22:20:03 +0100 Received: from mtiwmhc01.worldnet.att.net [204.127.131.36] by hermes via ESMTP (WAA13799); Wed, 16 Jun 1999 22:20:02 +0100 (BST) Received: from worldnet.att.net ([12.76.97.89]) by mtiwmhc01.worldnet.att.net (InterMail v03.02.07.07 118-134) with ESMTP id <19990616211941.WJOM12284@worldnet.att.net>; Wed, 16 Jun 1999 21:19:41 +0000 Message-ID: <37681550.1ACE5367@worldnet.att.net> Date: Wed, 16 Jun 1999 17:21:22 -0400 From: Kirsh Family Reply-To: kirsh@worldnet.att.net Organization: Kirsh Family X-Mailer: Mozilla 4.5 (Macintosh; U; PPC) X-Accept-Language: en-US MIME-Version: 1.0 To: karmha@club-internet.fr, csound@maths.ex.ac.uk Subject: Re: problem rescaling. References: <3766E171.BD6C72BD@club-internet.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk KH wrote: > > Yes it's me again... > > Well apparently the problem is not with loscil, but simply with the > first instrument. > try to run this with rescaling: > ... For what it's worth, I ran both scores with the orchestra included in the email, and they all worked fine for me. I'm running Mac Csound 3.5.1 on an 8500/120 with MacOS 8.1. I've got 8818K allocated to Perf and ~600MB of free disk. My buffers are set to the maximum size: blocksize & audio output both set to 32768. I'm rescaling floats to 16-bit ints and using AIFF headers. David Kirsh Gahanna, Ohio Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06708; 16 Jun 99 23:32 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uOE4-0007dd-00 for jpff@maths.bath.ac.uk; Wed, 16 Jun 1999 23:32:08 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (XAA14610); Wed, 16 Jun 1999 23:28:31 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Wed, 16 Jun 1999 23:28:19 +0100 Received: from front6.grolier.fr [194.158.96.56] by hermes via ESMTP (XAA01543); Wed, 16 Jun 1999 23:28:18 +0100 (BST) Received: from club-internet.fr (ppp-160-225.villette.club-internet.fr [195.36.160.225]) by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA08093 for ; Thu, 17 Jun 1999 00:28:27 +0200 (MET DST) Message-ID: <3768263C.F1E8C282@club-internet.fr> Date: Thu, 17 Jun 1999 00:33:34 +0200 From: KH Reply-To: karmha@club-internet.fr X-Mailer: Mozilla 4.04 (Macintosh; I; PPC) MIME-Version: 1.0 To: "csound@maths.ex.ac.uk" Subject: No more problem rescaling Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Well I finally found out the problem! It has nothing to do directly with Csound, ouffff... It's a hard disk problem apparently. I think my external drive didn't agree with rescaling stuff... although most of the time it works well! So i tried my internal drive and everything went ok! (SCSI problem? drive problem who knows??) Well thanks to everybody who helped out. PS: the score is not a masterpiece, it's only a part from a part of an additif stuff. And sorry for those who asked for the samples, i can't send them first because i don't want to annoy everyone, 2) they are 3 mega each, and i have a slow line out here! Maybe next time, will send you something worth computing! Thanks again, and happy Csounding Karim Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06759; 16 Jun 99 23:54 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uOZb-0007e2-00 for jpff@maths.bath.ac.uk; Wed, 16 Jun 1999 23:54:23 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id HAA04529 for music-dsp-outgoing; Wed, 16 Jun 1999 07:29:37 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id HAA04525 for ; Wed, 16 Jun 1999 07:29:36 -0700 (PDT) Received: from [24.93.53.130] ([24.93.53.130]) by Mail.austin.rr.com with Microsoft SMTPSVC(5.5.1875.185.18); Wed, 16 Jun 1999 09:26:37 -0500 X-Sender: asynth@mail.io.com Message-Id: In-Reply-To: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Jun 1999 09:32:24 -0600 To: music-dsp@shoko.calarts.edu, CSOUND From: James McCartney Subject: Re: Csound and other synthesis systems Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu At 6:26 AM -0600 6/16/99, Michael Gogins wrote: >Other >programs of note that I don't talk about here are SuperCollider and >GrainWave. OK, but... >What is needed here is a reasonable compromise between the power and >amenability for experimentation of a bare-bones piece of academic UNIX >software, and a user-friendly GUI and user-extensible plugin architecture, >with realtime performance AND non-realtime soundfile rendering. This is the >wonderful musical instrument that is evolving before our very eyes (and >ears), and Csound already contains all the necessary guts for the thing. If expressive power is what you want then why go with Csound? Csound : assembly language :: SuperCollider : Smalltalk (OK this is crossposted to the Csound list so I can see those flames rolling in.. 8-0 ) Seriously, I would be interested in any serious proposals for collaboration on a port of SuperCollider to Linux. I think a SuperCollider + GTK on Linux would be very cool. SuperCollider was written from the beginning to be used in real time. All operations were conceived and written with that in mind. For example variable delay lines of any maximum length can be allocated and used immediately without needing to be zeroed out first. (SC can do non real time just fine too.) Right now SC is closed source, however I have been considering opening the source to the language virtual machine. Plugins of UGens and language primitives are both possible. SC was designed for easy plugging in of language primitives. The virtual machine should be easily portable, there is no Mac specific code in there. -- SuperCollider is a dynamically typed, real time garbage collected, fully object oriented language like Smalltalk with support for true closures, coroutines, positional or keyword arguments, variable length argument lists, default argument values, etc. It has a class library of 341 classes including a full set of Collection classes like Dictionary, Set, SortedList, etc. There are currently over 200 unit generators. -- --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06765; 16 Jun 99 23:54 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uOZz-0007e4-00 for jpff@maths.bath.ac.uk; Wed, 16 Jun 1999 23:54:47 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id HAA04361 for music-dsp-outgoing; Wed, 16 Jun 1999 07:27:37 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from jaguars.cableinet.net (jaguars-int.cableinet.net [193.38.113.9]) by shoko.calarts.edu (8.9.3/8.9.3) with SMTP id HAA04357 for ; Wed, 16 Jun 1999 07:27:35 -0700 (PDT) Received: (qmail 22118 invoked from network); 16 Jun 1999 14:23:16 -0000 Received: from unknown (HELO cableinet.co.uk) (194.117.146.59) by jaguars with SMTP; 16 Jun 1999 14:23:16 -0000 Message-ID: <3767C392.AD59CDAC@cableinet.co.uk> Date: Wed, 16 Jun 1999 15:32:34 +0000 From: rdbr03035 Organization: Composers Desktop Project X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 CC: music-dsp , CSOUND Subject: Re: Csound and other synthesis systems References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C406.2254ACDB@exbang.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu I agree that, taken direfctly in the conext of newer softsynths, Csound can look 'creaky', and it is indeed a tempting thought to revamp the whole thing to exploit the best of modern GUI/Plugin techniques. I have long thought about doing this myself 'as an exercise'. However, one vital aspect of Csound it it's extremely wide cross-platform character; and indeed it's core functionality as a console program has advantages for visually-impaired users. I don't think this could be done piece-meal. Basically, one would have to take the score and orc syntax and create a new engine from scratch, with multiple thread, dynamic libraries, and all the superstructure of a modern GUI-based application. Set against this is SAOL, which is ~fully~ public domain, and which is open for adaptation in any number of ways, has a more up-to-date language, and even has a means of compiling into a stand-alone application, thanks to 'cfront'. The legacy of SAOL scores is also arguably less significant, so compatibility at the command-line level is scarcely an issue. After all, SAOL is expected to be embedded in set-top boxes ere long! In the end, it depends how stronly the moral imperative that Csound ~should~ be at the 'leading edge' as a functioning softsynth, in the terms described. As it stands, it is a treasure-trove of dsp ideas, of unique educational value, a feature that I value highly. The issue then is one of modernity v fragmentation (unless it can be done exclusively using Java and/or TCL/TK), an issue which simply does not arise for SAOL. Csound ~is~ it's source code, but that is not strictly true of SAOL - 'saolc' is merely an example implementation. If we treat the score and orc syntax similarly, as a specification (as we can reasonably do), there is no reason why some new program cannot be written which implements it in a more modern form. The sticking point is then the title (in the legal sense), as my understanding is that ultimately this still belongs to MIT and Barry Vercoe. Richard Dobson Michel Jullian wrote: > > Michael Gogins wrote: > > > Csound could be put firmly back at the leading edge of the state of the art > > if: > > > > Csound gets plugin unit generators and function tables with a SIMPLE, I mean > > REALLY simple, API. > > Csound gets double-precision signal processing (Buzz and Generator use > > floats). > > Csound gets low-latency MIDI and audio input and output that works more or > > less the same on its major platforms. > > Csound gets an at least semi-snazzy GUI including unit generator wiring. > > Csound gets an external API for programmatic control. > > Csound can act as a VST plugin. > > This last point is _very_ good idea (the other points too). The VST 2 sdk, > featuring full midi control of plugin synths (AFAIK it's the only plugin > architecture with this feature) and a multiplatform GUI API, is due out any > day now (watch out for it on steinberg's vst devs list > ). Furthermore it is open not only to plugin > developers but also to host developers, which should help it become a standard. > > What would be really nice would be if csound could "compile" orcs as vst > plugins, somehow, instead of (or as well as) acting as a vst plugin. > > -- > Greetings, > Michel > ......................................................................... > Michel Jullian Directeur General email mj@exbang.com > Exbang Industries S.A. > Mas Chauvain route de Villeneuve tel +33(0) 499 529 878 > Maurin 34970 Lattes France fax +33(0) 499 529 879 > ......................................................................... dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06795; 17 Jun 99 0:07 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uOmW-0001xw-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 00:07:45 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (AAA10675); Thu, 17 Jun 1999 00:03:19 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 00:03:07 +0100 Received: from smtp2.mindspring.com [207.69.200.32] by hermes via ESMTP (AAA01689); Thu, 17 Jun 1999 00:03:06 +0100 (BST) Received: from Realizer (user-2ive1m3.dialup.mindspring.com [165.247.6.195]) by smtp2.mindspring.com (8.8.5/8.8.5) with SMTP id TAA01376; Wed, 16 Jun 1999 19:03:10 -0400 (EDT) Message-ID: <002501beb84c$78a42080$79d496c0@Realizer.ngt.sungard.com> From: Michael Gogins To: rdbr03035 Cc: music-dsp , CSOUND Subject: Re: Csound and other synthesis systems Date: Wed, 16 Jun 1999 19:03:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk I'm glad to have your response, but let me clear up some misconceptions. I'm calling for Csound to become an engine built in COMPLETELY cross-platform, lowest-common-denominator, plain old C. Only runtime library calls, no system calls. There is an abstract interface for each of (1) MIDI in, (2) MIDI out, (3) audio in, (4) audio out, (5) plugin function tables, (6) plugin unit generators, and then (7) VST service for clients, and finally (8) programmatic control. All graphical goodies are done in Java and use the abstract interfaces to get at the kernel. If JavaSound is good enough, all the abstract interfaces above except (5), (6), (7), and (8) are service provider interfaces for JavaSound - we don't have to implement the other side of those interfaces at all. Threading issues can be dealt with by ignoring them, for the most part; the Java host can spawn a new thread to render a Csound job, but the engine need only be single-threaded as it now is. I would repeat my rant as something to do for SAOL - if an efficient complete implementation existed. Csound exists, and it's DEEP. -----Original Message----- From: rdbr03035 Cc: music-dsp ; CSOUND Date: Wednesday, June 16, 1999 10:32 AM Subject: Re: Csound and other synthesis systems >I agree that, taken direfctly in the conext of newer softsynths, Csound >can look 'creaky', and it is indeed a tempting thought to revamp the >whole thing to exploit the best of modern GUI/Plugin techniques. I have >long thought about doing this myself 'as an exercise'. However, one >vital aspect of Csound it it's extremely wide cross-platform character; >and indeed it's core functionality as a console program has advantages >for visually-impaired users. > >I don't think this could be done piece-meal. Basically, one would have >to take the score and orc syntax and create a new engine from scratch, >with multiple thread, dynamic libraries, and all the superstructure of a >modern GUI-based application. > >Set against this is SAOL, which is ~fully~ public domain, and which is >open for adaptation in any number of ways, has a more up-to-date >language, and even has a means of compiling into a stand-alone >application, thanks to 'cfront'. The legacy of SAOL scores is also >arguably less significant, so compatibility at the command-line level is >scarcely an issue. After all, SAOL is expected to be embedded in set-top >boxes ere long! > >In the end, it depends how stronly the moral imperative that Csound >~should~ be at the 'leading edge' as a functioning softsynth, in the >terms described. As it stands, it is a treasure-trove of dsp ideas, of >unique educational value, a feature that I value highly. The issue then >is one of modernity v fragmentation (unless it can be done exclusively >using Java and/or TCL/TK), an issue which simply does not arise for >SAOL. Csound ~is~ it's source code, but that is not strictly true of >SAOL - 'saolc' is merely an example implementation. > >If we treat the score and orc syntax similarly, as a specification (as >we can reasonably do), there is no reason why some new program cannot be >written which implements it in a more modern form. The sticking point is >then the title (in the legal sense), as my understanding is that >ultimately this still belongs to MIT and Barry Vercoe. > > >Richard Dobson > > >Michel Jullian wrote: >> >> Michael Gogins wrote: >> >> > Csound could be put firmly back at the leading edge of the state of the art >> > if: >> > >> > Csound gets plugin unit generators and function tables with a SIMPLE, I mean >> > REALLY simple, API. >> > Csound gets double-precision signal processing (Buzz and Generator use >> > floats). >> > Csound gets low-latency MIDI and audio input and output that works more or >> > less the same on its major platforms. >> > Csound gets an at least semi-snazzy GUI including unit generator wiring. >> > Csound gets an external API for programmatic control. >> > Csound can act as a VST plugin. >> >> This last point is _very_ good idea (the other points too). The VST 2 sdk, >> featuring full midi control of plugin synths (AFAIK it's the only plugin >> architecture with this feature) and a multiplatform GUI API, is due out any >> day now (watch out for it on steinberg's vst devs list >> ). Furthermore it is open not only to plugin >> developers but also to host developers, which should help it become a standard. >> >> What would be really nice would be if csound could "compile" orcs as vst >> plugins, somehow, instead of (or as well as) acting as a vst plugin. >> >> -- >> Greetings, >> Michel >> ......................................................................... >> Michel Jullian Directeur General email mj@exbang.com >> Exbang Industries S.A. >> Mas Chauvain route de Villeneuve tel +33(0) 499 529 878 >> Maurin 34970 Lattes France fax +33(0) 499 529 879 >> ......................................................................... Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06819; 17 Jun 99 0:13 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uOsT-0007fj-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 00:13:53 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (AAA06934); Thu, 17 Jun 1999 00:10:16 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 00:10:04 +0100 Received: from smtp2.mindspring.com [207.69.200.32] by hermes via ESMTP (AAA10959); Thu, 17 Jun 1999 00:10:03 +0100 (BST) Received: from Realizer (user-2ive1m3.dialup.mindspring.com [165.247.6.195]) by smtp2.mindspring.com (8.8.5/8.8.5) with SMTP id TAA24428; Wed, 16 Jun 1999 19:09:56 -0400 (EDT) Message-ID: <004001beb84d$6adfd880$79d496c0@Realizer.ngt.sungard.com> From: Michael Gogins To: Robin Whittle , music-dsp@shoko.calarts.edu MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos Cc: CSOUND Subject: Re: Csound and other synthesis systems Date: Wed, 16 Jun 1999 19:10:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk I'm afraid you missed one major thrust of my message. I am in fact quite concerned about multi-platform capability. My system Silence runs on both Windows and Linux (thanks to Dave Pnillips). If Csound is a "pure ANSI C runtime library" engine and implements Java native methods, and the Csound GUI and extras are all done in Java, then the whole system is cross-platform without much, if indeed any, extra work at all. -----Original Message----- From: Robin Whittle To: music-dsp@shoko.calarts.edu Cc: CSOUND Date: Wednesday, June 16, 1999 12:01 PM Subject: Re: Csound and other synthesis systems >Michael Gogins mounted his soapbox on the limitations of Csound. He >seemed to be focused on a Windows-based patchable-synthesiser view of >software synthesis. > >Here's the view from my particular soapbox. > >There is much more to software synthesis and Csound than being like a >Moog modular on MIDI, but such a thing would certainly be a marvel and >would be widely used, including by me! > >There are those of us who do not want to run things on Windows if we >can help it. (I find Windows a seriously unreliable and frustrating >operating system, despite its creature comforts which I know and >love. I have no interest in owning a Mac - too expensive and weird.) >We want open-source free software which runs on an open-source >operating system - most obviously Linux. We want all the compilers >etc. to be open-source too. > Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06831; 17 Jun 99 0:15 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uOts-0007fq-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 00:15:20 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (AAA18327); Thu, 17 Jun 1999 00:11:48 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 00:11:35 +0100 Received: from smtp2.mindspring.com [207.69.200.32] by hermes via ESMTP (AAA00562); Thu, 17 Jun 1999 00:11:34 +0100 (BST) Received: from Realizer (user-2ive1m3.dialup.mindspring.com [165.247.6.195]) by smtp2.mindspring.com (8.8.5/8.8.5) with SMTP id TAA15342; Wed, 16 Jun 1999 19:11:34 -0400 (EDT) Message-ID: <005201beb84d$a46dbb80$79d496c0@Realizer.ngt.sungard.com> From: Michael Gogins To: pete moss , Robin Whittle Cc: music-dsp@shoko.calarts.edu, CSOUND MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos Subject: Re: Csound and other synthesis systems Date: Wed, 16 Jun 1999 19:12:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Correct me if I'm wrong - but doesn't cmusic have many fewer unit generators than Csound and no real-time MIDI input or audio output? -----Original Message----- From: pete moss To: Robin Whittle Cc: music-dsp@shoko.calarts.edu ; CSOUND Date: Wednesday, June 16, 1999 1:54 PM Subject: Re: Csound and other synthesis systems >isnt that what cmusic does? except with c, (no ++). > >:P > > >Robin Whittle wrote: >> Personally I think the Csound orchestra and score language should be >> left behind. If I was writing a system from scratch it would not use >> any special language at all - it would be a special framework for >> writing C++ to get on with real-time sound synthesis and all I/O and >> GUI things you might like to hang of that. It would do non-real-time >> work as well, and the same principles would probably apply to >> generating video images too. The C++ core elements would interface to >> things in other languages, for instance novel score languages or >> whatever you liked to create. Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06841; 17 Jun 99 0:17 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uOw2-0007fs-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 00:17:36 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id QAA03663 for music-dsp-outgoing; Wed, 16 Jun 1999 16:03:17 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from smtp2.mindspring.com (smtp2.mindspring.com [207.69.200.32]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id QAA03659 for ; Wed, 16 Jun 1999 16:03:15 -0700 (PDT) Received: from Realizer (user-2ive1m3.dialup.mindspring.com [165.247.6.195]) by smtp2.mindspring.com (8.8.5/8.8.5) with SMTP id TAA01376; Wed, 16 Jun 1999 19:03:10 -0400 (EDT) Message-ID: <002501beb84c$78a42080$79d496c0@Realizer.ngt.sungard.com> From: Michael Gogins To: rdbr03035 Cc: music-dsp , CSOUND Subject: Re: Csound and other synthesis systems Date: Wed, 16 Jun 1999 19:03:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu I'm glad to have your response, but let me clear up some misconceptions. I'm calling for Csound to become an engine built in COMPLETELY cross-platform, lowest-common-denominator, plain old C. Only runtime library calls, no system calls. There is an abstract interface for each of (1) MIDI in, (2) MIDI out, (3) audio in, (4) audio out, (5) plugin function tables, (6) plugin unit generators, and then (7) VST service for clients, and finally (8) programmatic control. All graphical goodies are done in Java and use the abstract interfaces to get at the kernel. If JavaSound is good enough, all the abstract interfaces above except (5), (6), (7), and (8) are service provider interfaces for JavaSound - we don't have to implement the other side of those interfaces at all. Threading issues can be dealt with by ignoring them, for the most part; the Java host can spawn a new thread to render a Csound job, but the engine need only be single-threaded as it now is. I would repeat my rant as something to do for SAOL - if an efficient complete implementation existed. Csound exists, and it's DEEP. -----Original Message----- From: rdbr03035 Cc: music-dsp ; CSOUND Date: Wednesday, June 16, 1999 10:32 AM Subject: Re: Csound and other synthesis systems >I agree that, taken direfctly in the conext of newer softsynths, Csound >can look 'creaky', and it is indeed a tempting thought to revamp the >whole thing to exploit the best of modern GUI/Plugin techniques. I have >long thought about doing this myself 'as an exercise'. However, one >vital aspect of Csound it it's extremely wide cross-platform character; >and indeed it's core functionality as a console program has advantages >for visually-impaired users. > >I don't think this could be done piece-meal. Basically, one would have >to take the score and orc syntax and create a new engine from scratch, >with multiple thread, dynamic libraries, and all the superstructure of a >modern GUI-based application. > >Set against this is SAOL, which is ~fully~ public domain, and which is >open for adaptation in any number of ways, has a more up-to-date >language, and even has a means of compiling into a stand-alone >application, thanks to 'cfront'. The legacy of SAOL scores is also >arguably less significant, so compatibility at the command-line level is >scarcely an issue. After all, SAOL is expected to be embedded in set-top >boxes ere long! > >In the end, it depends how stronly the moral imperative that Csound >~should~ be at the 'leading edge' as a functioning softsynth, in the >terms described. As it stands, it is a treasure-trove of dsp ideas, of >unique educational value, a feature that I value highly. The issue then >is one of modernity v fragmentation (unless it can be done exclusively >using Java and/or TCL/TK), an issue which simply does not arise for >SAOL. Csound ~is~ it's source code, but that is not strictly true of >SAOL - 'saolc' is merely an example implementation. > >If we treat the score and orc syntax similarly, as a specification (as >we can reasonably do), there is no reason why some new program cannot be >written which implements it in a more modern form. The sticking point is >then the title (in the legal sense), as my understanding is that >ultimately this still belongs to MIT and Barry Vercoe. > > >Richard Dobson > > >Michel Jullian wrote: >> >> Michael Gogins wrote: >> >> > Csound could be put firmly back at the leading edge of the state of the art >> > if: >> > >> > Csound gets plugin unit generators and function tables with a SIMPLE, I mean >> > REALLY simple, API. >> > Csound gets double-precision signal processing (Buzz and Generator use >> > floats). >> > Csound gets low-latency MIDI and audio input and output that works more or >> > less the same on its major platforms. >> > Csound gets an at least semi-snazzy GUI including unit generator wiring. >> > Csound gets an external API for programmatic control. >> > Csound can act as a VST plugin. >> >> This last point is _very_ good idea (the other points too). The VST 2 sdk, >> featuring full midi control of plugin synths (AFAIK it's the only plugin >> architecture with this feature) and a multiplatform GUI API, is due out any >> day now (watch out for it on steinberg's vst devs list >> ). Furthermore it is open not only to plugin >> developers but also to host developers, which should help it become a standard. >> >> What would be really nice would be if csound could "compile" orcs as vst >> plugins, somehow, instead of (or as well as) acting as a vst plugin. >> >> -- >> Greetings, >> Michel >> ......................................................................... >> Michel Jullian Directeur General email mj@exbang.com >> Exbang Industries S.A. >> Mas Chauvain route de Villeneuve tel +33(0) 499 529 878 >> Maurin 34970 Lattes France fax +33(0) 499 529 879 >> ......................................................................... dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06850; 17 Jun 99 0:22 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uP1A-0007fz-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 00:22:52 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (AAA16215); Thu, 17 Jun 1999 00:19:16 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 00:19:05 +0100 Received: from smtp2.mindspring.com [207.69.200.32] by hermes via ESMTP (AAA04400); Thu, 17 Jun 1999 00:19:04 +0100 (BST) Received: from Realizer (user-2ive1m3.dialup.mindspring.com [165.247.6.195]) by smtp2.mindspring.com (8.8.5/8.8.5) with SMTP id TAA11507; Wed, 16 Jun 1999 19:19:11 -0400 (EDT) Message-ID: <008401beb84e$b4be8fe0$79d496c0@Realizer.ngt.sungard.com> From: Michael Gogins To: music-dsp@shoko.calarts.edu MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos Cc: CSOUND Subject: Re: Csound and other synthesis systems Date: Wed, 16 Jun 1999 19:19:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Thanks for your response to this discussion. I remember your exhibition of SuperCollider at the last ICMC and was quite impressed. I would love if it SuperCollider: (a) ran on Windows (b) had plugin unit generators (or words in its language - is that even possible?) (c) had an external API (d) ran on Windows -----Original Message----- From: James McCartney To: music-dsp@shoko.calarts.edu Cc: CSOUND Date: Wednesday, June 16, 1999 3:56 PM Subject: Re: Csound and other synthesis systems >At 9:53 AM -0600 6/16/99, Robin Whittle wrote: > >>I guess such a patching system can be done in any language - but I >>would much rather write orchestra code than muck around with a GUI on >>that level! Patching instruments together, as Quasimodo does, with >>the GUI interface for each instrument defined it its part of the >>orchestra file . . . . yes I think can be very useful. >> >> >>Personally I think the Csound orchestra and score language should be >>left behind. If I was writing a system from scratch it would not use >>any special language at all - it would be a special framework for >>writing C++ to get on with real-time sound synthesis and all I/O and >>GUI things you might like to hang of that. > >Computer music software can be a lot more than just a synth engine >of statically allocated ugens attached to a GUI. This framework is >just too limiting compared to what is possible. >If this is the vision of what is ideal then I think you have not brainstormed >enough about what the real interesting problems are. >There is a lot more I want to "hang on" my DSP engine than a GUI. >Once you get your ideal system how will you attach interesting behaviours >to it? Using C++ to write intelligent players or gesture mappings, or >list processing score manipulation would be very painful. > >I think many people do not still grok the kind of things you can do >with a dynamic system like SC or Kyma which is why so many of the same >kind of system keep coming out: GUI+DSP but no brains. >In SC, you can write an algorithmic process to build your patch in real >time, e.g. mapping velocity to how complex a patch you build. >Values in your score can themselves be patches that plug into your >instrument input. For example you could have a note in your score >be a patch of ugens. Then that voice's patch will get built with that >sub-patch plugged into its input instead of just a float value. >Instruments can spawn sub patches recursively to any depth. etc.. > >That is why I think having a language is important. There is only >so much you can do with a static framework. Static frameworks are not >much better than just having cheap sound hardware. A powerful language >gives you a lot more ability to do what computers can be good at which >is manipulating abstractions. And C++ is just not a very highly abstract >language. > > > --- james mccartney james@audiosynth.com http://www.audiosynth.com >If you have a PowerMac check out SuperCollider2, a real time synth program: > > > > > > >dupswapdrop: the music-dsp mailing list and website >http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html > Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06859; 17 Jun 99 0:25 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uP3H-0007g1-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 00:25:03 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id QAA03892 for music-dsp-outgoing; Wed, 16 Jun 1999 16:10:14 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from smtp2.mindspring.com (smtp2.mindspring.com [207.69.200.32]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id QAA03878 for ; Wed, 16 Jun 1999 16:10:12 -0700 (PDT) Received: from Realizer (user-2ive1m3.dialup.mindspring.com [165.247.6.195]) by smtp2.mindspring.com (8.8.5/8.8.5) with SMTP id TAA24428; Wed, 16 Jun 1999 19:09:56 -0400 (EDT) Message-ID: <004001beb84d$6adfd880$79d496c0@Realizer.ngt.sungard.com> From: Michael Gogins To: Robin Whittle , music-dsp@shoko.calarts.edu MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos Cc: CSOUND Subject: Re: Csound and other synthesis systems Date: Wed, 16 Jun 1999 19:10:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu I'm afraid you missed one major thrust of my message. I am in fact quite concerned about multi-platform capability. My system Silence runs on both Windows and Linux (thanks to Dave Pnillips). If Csound is a "pure ANSI C runtime library" engine and implements Java native methods, and the Csound GUI and extras are all done in Java, then the whole system is cross-platform without much, if indeed any, extra work at all. -----Original Message----- From: Robin Whittle To: music-dsp@shoko.calarts.edu Cc: CSOUND Date: Wednesday, June 16, 1999 12:01 PM Subject: Re: Csound and other synthesis systems >Michael Gogins mounted his soapbox on the limitations of Csound. He >seemed to be focused on a Windows-based patchable-synthesiser view of >software synthesis. > >Here's the view from my particular soapbox. > >There is much more to software synthesis and Csound than being like a >Moog modular on MIDI, but such a thing would certainly be a marvel and >would be widely used, including by me! > >There are those of us who do not want to run things on Windows if we >can help it. (I find Windows a seriously unreliable and frustrating >operating system, despite its creature comforts which I know and >love. I have no interest in owning a Mac - too expensive and weird.) >We want open-source free software which runs on an open-source >operating system - most obviously Linux. We want all the compilers >etc. to be open-source too. > dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06866; 17 Jun 99 0:26 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uP57-0007g3-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 00:26:57 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id QAA03952 for music-dsp-outgoing; Wed, 16 Jun 1999 16:11:45 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from smtp2.mindspring.com (smtp2.mindspring.com [207.69.200.32]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id QAA03948 for ; Wed, 16 Jun 1999 16:11:43 -0700 (PDT) Received: from Realizer (user-2ive1m3.dialup.mindspring.com [165.247.6.195]) by smtp2.mindspring.com (8.8.5/8.8.5) with SMTP id TAA15342; Wed, 16 Jun 1999 19:11:34 -0400 (EDT) Message-ID: <005201beb84d$a46dbb80$79d496c0@Realizer.ngt.sungard.com> From: Michael Gogins To: pete moss , Robin Whittle Cc: music-dsp@shoko.calarts.edu, CSOUND MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos Subject: Re: Csound and other synthesis systems Date: Wed, 16 Jun 1999 19:12:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu Correct me if I'm wrong - but doesn't cmusic have many fewer unit generators than Csound and no real-time MIDI input or audio output? -----Original Message----- From: pete moss To: Robin Whittle Cc: music-dsp@shoko.calarts.edu ; CSOUND Date: Wednesday, June 16, 1999 1:54 PM Subject: Re: Csound and other synthesis systems >isnt that what cmusic does? except with c, (no ++). > >:P > > >Robin Whittle wrote: >> Personally I think the Csound orchestra and score language should be >> left behind. If I was writing a system from scratch it would not use >> any special language at all - it would be a special framework for >> writing C++ to get on with real-time sound synthesis and all I/O and >> GUI things you might like to hang of that. It would do non-real-time >> work as well, and the same principles would probably apply to >> generating video images too. The C++ core elements would interface to >> things in other languages, for instance novel score languages or >> whatever you liked to create. dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06892; 17 Jun 99 0:30 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uP8s-0007g7-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 00:30:51 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id QAA04083 for music-dsp-outgoing; Wed, 16 Jun 1999 16:19:15 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from smtp2.mindspring.com (smtp2.mindspring.com [207.69.200.32]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id QAA04079 for ; Wed, 16 Jun 1999 16:19:13 -0700 (PDT) Received: from Realizer (user-2ive1m3.dialup.mindspring.com [165.247.6.195]) by smtp2.mindspring.com (8.8.5/8.8.5) with SMTP id TAA11507; Wed, 16 Jun 1999 19:19:11 -0400 (EDT) Message-ID: <008401beb84e$b4be8fe0$79d496c0@Realizer.ngt.sungard.com> From: Michael Gogins To: music-dsp@shoko.calarts.edu MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos Cc: CSOUND Subject: Re: Csound and other synthesis systems Date: Wed, 16 Jun 1999 19:19:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu Thanks for your response to this discussion. I remember your exhibition of SuperCollider at the last ICMC and was quite impressed. I would love if it SuperCollider: (a) ran on Windows (b) had plugin unit generators (or words in its language - is that even possible?) (c) had an external API (d) ran on Windows -----Original Message----- From: James McCartney To: music-dsp@shoko.calarts.edu Cc: CSOUND Date: Wednesday, June 16, 1999 3:56 PM Subject: Re: Csound and other synthesis systems >At 9:53 AM -0600 6/16/99, Robin Whittle wrote: > >>I guess such a patching system can be done in any language - but I >>would much rather write orchestra code than muck around with a GUI on >>that level! Patching instruments together, as Quasimodo does, with >>the GUI interface for each instrument defined it its part of the >>orchestra file . . . . yes I think can be very useful. >> >> >>Personally I think the Csound orchestra and score language should be >>left behind. If I was writing a system from scratch it would not use >>any special language at all - it would be a special framework for >>writing C++ to get on with real-time sound synthesis and all I/O and >>GUI things you might like to hang of that. > >Computer music software can be a lot more than just a synth engine >of statically allocated ugens attached to a GUI. This framework is >just too limiting compared to what is possible. >If this is the vision of what is ideal then I think you have not brainstormed >enough about what the real interesting problems are. >There is a lot more I want to "hang on" my DSP engine than a GUI. >Once you get your ideal system how will you attach interesting behaviours >to it? Using C++ to write intelligent players or gesture mappings, or >list processing score manipulation would be very painful. > >I think many people do not still grok the kind of things you can do >with a dynamic system like SC or Kyma which is why so many of the same >kind of system keep coming out: GUI+DSP but no brains. >In SC, you can write an algorithmic process to build your patch in real >time, e.g. mapping velocity to how complex a patch you build. >Values in your score can themselves be patches that plug into your >instrument input. For example you could have a note in your score >be a patch of ugens. Then that voice's patch will get built with that >sub-patch plugged into its input instead of just a float value. >Instruments can spawn sub patches recursively to any depth. etc.. > >That is why I think having a language is important. There is only >so much you can do with a static framework. Static frameworks are not >much better than just having cheap sound hardware. A powerful language >gives you a lot more ability to do what computers can be good at which >is manipulating abstractions. And C++ is just not a very highly abstract >language. > > > --- james mccartney james@audiosynth.com http://www.audiosynth.com >If you have a PowerMac check out SuperCollider2, a real time synth program: > > > > > > >dupswapdrop: the music-dsp mailing list and website >http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html > dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa06905; 17 Jun 99 0:33 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uPB8-0007gE-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 00:33:10 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (AAA03507); Thu, 17 Jun 1999 00:29:38 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 00:29:27 +0100 Received: from out2.ibm.net [165.87.194.229] by hermes via ESMTP (AAA13866); Thu, 17 Jun 1999 00:29:26 +0100 (BST) Received: from ibm.net (slip-32-100-209-38.dc.us.ibm.net [32.100.209.38]) by out2.ibm.net (8.8.5/8.6.9) with ESMTP id XAA199600; Wed, 16 Jun 1999 23:29:16 GMT Message-ID: <37683468.A7A3088A@ibm.net> Date: Wed, 16 Jun 1999 19:34:00 -0400 From: "Job M. van Zuijlen" Reply-To: zuijlen@ibm.net Organization: electona X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: music-dsp , CSOUND Subject: Re: Csound and other synthesis systems References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C406.2254ACDB@exbang.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk If we're talking plug-ins, I would like the approach to be a little bit more general than Steinberg's VST. I do not and do not want to use Steinberg products, so VST support would be of no interest to me. Job van Zuijlen Michel Jullian wrote: > > Michael Gogins wrote: > > > Csound can act as a VST plugin. > > This last point is _very_ good idea (the other points too). The VST 2 sdk, > featuring full midi control of plugin synths (AFAIK it's the only plugin > architecture with this feature) and a multiplatform GUI API, is due out any > day now (watch out for it on steinberg's vst devs list > ). Furthermore it is open not only to plugin > developers but also to host developers, which should help it become a standard. > > What would be really nice would be if csound could "compile" orcs as vst > plugins, somehow, instead of (or as well as) acting as a vst plugin. > Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07109; 17 Jun 99 2:46 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uRFu-00024d-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 02:46:15 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (CAA12394); Thu, 17 Jun 1999 02:42:37 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 02:42:26 +0100 Received: from ares.flash.net [209.30.0.41] by hermes via ESMTP (CAA15114); Thu, 17 Jun 1999 02:42:25 +0100 (BST) Received: from bigfoot.com (p225-78.atnt4.dialup.ftw1.flash.net [209.30.225.78]) by ares.flash.net (8.9.3/8.9.3) with ESMTP id UAA19865; Wed, 16 Jun 1999 20:42:27 -0500 (CDT) Message-ID: <37685309.4F25A09D@bigfoot.com> Date: Wed, 16 Jun 1999 20:44:41 -0500 From: pete moss Organization: pete moss GmbH X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: music-dsp@shoko.calarts.edu CC: CSOUND Subject: Re: Csound and other synthesis systems References: <005201beb84d$a46dbb80$79d496c0@Realizer.ngt.sungard.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk i dont know. aal i do know is that it offers the framework similar to what robin was saying. i have never actually used it, cause i got csound! :P Michael Gogins wrote: > > Correct me if I'm wrong - but doesn't cmusic have many fewer unit generators > than Csound and no real-time MIDI input or audio output? > > -----Original Message----- > From: pete moss > To: Robin Whittle > Cc: music-dsp@shoko.calarts.edu ; CSOUND > > Date: Wednesday, June 16, 1999 1:54 PM > Subject: Re: Csound and other synthesis systems > > >isnt that what cmusic does? except with c, (no ++). > > > >:P > > > > > >Robin Whittle wrote: > >> Personally I think the Csound orchestra and score language should be > >> left behind. If I was writing a system from scratch it would not use > >> any special language at all - it would be a special framework for > >> writing C++ to get on with real-time sound synthesis and all I/O and > >> GUI things you might like to hang of that. It would do non-real-time > >> work as well, and the same principles would probably apply to > >> generating video images too. The C++ core elements would interface to > >> things in other languages, for instance novel score languages or > >> whatever you liked to create. > > dupswapdrop: the music-dsp mailing list and website > http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07121; 17 Jun 99 2:53 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uRMf-00024i-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 02:53:14 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id SAA08848 for music-dsp-outgoing; Wed, 16 Jun 1999 18:42:36 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from ares.flash.net (ares.flash.net [209.30.0.41]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id SAA08844 for ; Wed, 16 Jun 1999 18:42:34 -0700 (PDT) Received: from bigfoot.com (p225-78.atnt4.dialup.ftw1.flash.net [209.30.225.78]) by ares.flash.net (8.9.3/8.9.3) with ESMTP id UAA19865; Wed, 16 Jun 1999 20:42:27 -0500 (CDT) Message-ID: <37685309.4F25A09D@bigfoot.com> Date: Wed, 16 Jun 1999 20:44:41 -0500 From: pete moss Organization: pete moss GmbH X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: music-dsp@shoko.calarts.edu CC: CSOUND Subject: Re: Csound and other synthesis systems References: <005201beb84d$a46dbb80$79d496c0@Realizer.ngt.sungard.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu i dont know. aal i do know is that it offers the framework similar to what robin was saying. i have never actually used it, cause i got csound! :P Michael Gogins wrote: > > Correct me if I'm wrong - but doesn't cmusic have many fewer unit generators > than Csound and no real-time MIDI input or audio output? > > -----Original Message----- > From: pete moss > To: Robin Whittle > Cc: music-dsp@shoko.calarts.edu ; CSOUND > > Date: Wednesday, June 16, 1999 1:54 PM > Subject: Re: Csound and other synthesis systems > > >isnt that what cmusic does? except with c, (no ++). > > > >:P > > > > > >Robin Whittle wrote: > >> Personally I think the Csound orchestra and score language should be > >> left behind. If I was writing a system from scratch it would not use > >> any special language at all - it would be a special framework for > >> writing C++ to get on with real-time sound synthesis and all I/O and > >> GUI things you might like to hang of that. It would do non-real-time > >> work as well, and the same principles would probably apply to > >> generating video images too. The C++ core elements would interface to > >> things in other languages, for instance novel score languages or > >> whatever you liked to create. > > dupswapdrop: the music-dsp mailing list and website > http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07128; 17 Jun 99 2:54 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uRO8-00024o-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 02:54:44 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (CAA03576); Thu, 17 Jun 1999 02:51:14 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 02:51:03 +0100 Received: from smtp0.mindspring.com [207.69.200.30] by hermes via ESMTP (CAA01739); Thu, 17 Jun 1999 02:51:02 +0100 (BST) Received: from Realizer (user-2ive0am.dialup.mindspring.com [165.247.1.86]) by smtp0.mindspring.com (8.8.5/8.8.5) with SMTP id VAA27896; Wed, 16 Jun 1999 21:51:06 -0400 (EDT) Message-ID: <000801beb863$ecfb0720$79d496c0@Realizer.ngt.sungard.com> From: Michael Gogins To: music-dsp@shoko.calarts.edu, CSOUND MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos Subject: Re: Csound and other synthesis systems Date: Wed, 16 Jun 1999 21:51:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk I would seriously consider (at this point I feel I would be quite eager) to collaborate with you on a port of SuperCollider -- not to Linux specifically, but to Java. In other words, the SuperCollider virtual machine would be implement native methods in a Java class. If JavaSound proves usable, then porting to Java would be porting to Windows and Solaris for certain, to Linux almost certainly, and probably to the Mac as well. Other objectives: Open Source (not a fixed unalterable requirement) Plugin unit generators and language primitives with some rather extensive consultation and discussion and comparison of existing designs (Csound, Buzz, VST round two, DirectShow) Is there any way that the SuperCollider language would lend itself to implementation of those so-popular unit generator wiring forms? Now that I have played with Generator a little, I rather like them. -----Original Message----- From: James McCartney To: music-dsp@shoko.calarts.edu ; CSOUND Date: Wednesday, June 16, 1999 7:00 PM Subject: Re: Csound and other synthesis systems >At 6:26 AM -0600 6/16/99, Michael Gogins wrote: > >>Other >>programs of note that I don't talk about here are SuperCollider and >>GrainWave. > >OK, but... > >>What is needed here is a reasonable compromise between the power and >>amenability for experimentation of a bare-bones piece of academic UNIX >>software, and a user-friendly GUI and user-extensible plugin architecture, >>with realtime performance AND non-realtime soundfile rendering. This is the >>wonderful musical instrument that is evolving before our very eyes (and >>ears), and Csound already contains all the necessary guts for the thing. > >If expressive power is what you want then why go with Csound? > >Csound : assembly language :: SuperCollider : Smalltalk > >(OK this is crossposted to the Csound list so I can see those >flames rolling in.. 8-0 ) > >Seriously, I would be interested in any serious proposals for >collaboration on a port of SuperCollider to Linux. >I think a SuperCollider + GTK on Linux would be very cool. > >SuperCollider was written from the beginning to be used in real time. >All operations were conceived and written with that in mind. For example >variable delay lines of any maximum length can be allocated and used >immediately without needing to be zeroed out first. (SC can do non >real time just fine too.) > >Right now SC is closed source, however I have been considering >opening the source to the language virtual machine. >Plugins of UGens and language primitives are both possible. >SC was designed for easy plugging in of language primitives. >The virtual machine should be easily portable, there is no >Mac specific code in there. > >-- > >SuperCollider is a dynamically typed, real time garbage collected, >fully object oriented language like Smalltalk with support for true closures, >coroutines, positional or keyword arguments, variable length argument >lists, default argument values, etc. >It has a class library of 341 classes including a full set >of Collection classes like Dictionary, Set, SortedList, etc. >There are currently over 200 unit generators. > >-- > > > --- james mccartney james@audiosynth.com http://www.audiosynth.com >If you have a PowerMac check out SuperCollider2, a real time synth program: > > > > > > >dupswapdrop: the music-dsp mailing list and website >http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html > Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07152; 17 Jun 99 3:01 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uRUA-0007mU-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 03:00:58 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id SAA09044 for music-dsp-outgoing; Wed, 16 Jun 1999 18:51:13 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from smtp0.mindspring.com (smtp0.mindspring.com [207.69.200.30]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id SAA09040 for ; Wed, 16 Jun 1999 18:51:08 -0700 (PDT) Received: from Realizer (user-2ive0am.dialup.mindspring.com [165.247.1.86]) by smtp0.mindspring.com (8.8.5/8.8.5) with SMTP id VAA27896; Wed, 16 Jun 1999 21:51:06 -0400 (EDT) Message-ID: <000801beb863$ecfb0720$79d496c0@Realizer.ngt.sungard.com> From: Michael Gogins To: music-dsp@shoko.calarts.edu, CSOUND MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos Subject: Re: Csound and other synthesis systems Date: Wed, 16 Jun 1999 21:51:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu I would seriously consider (at this point I feel I would be quite eager) to collaborate with you on a port of SuperCollider -- not to Linux specifically, but to Java. In other words, the SuperCollider virtual machine would be implement native methods in a Java class. If JavaSound proves usable, then porting to Java would be porting to Windows and Solaris for certain, to Linux almost certainly, and probably to the Mac as well. Other objectives: Open Source (not a fixed unalterable requirement) Plugin unit generators and language primitives with some rather extensive consultation and discussion and comparison of existing designs (Csound, Buzz, VST round two, DirectShow) Is there any way that the SuperCollider language would lend itself to implementation of those so-popular unit generator wiring forms? Now that I have played with Generator a little, I rather like them. -----Original Message----- From: James McCartney To: music-dsp@shoko.calarts.edu ; CSOUND Date: Wednesday, June 16, 1999 7:00 PM Subject: Re: Csound and other synthesis systems >At 6:26 AM -0600 6/16/99, Michael Gogins wrote: > >>Other >>programs of note that I don't talk about here are SuperCollider and >>GrainWave. > >OK, but... > >>What is needed here is a reasonable compromise between the power and >>amenability for experimentation of a bare-bones piece of academic UNIX >>software, and a user-friendly GUI and user-extensible plugin architecture, >>with realtime performance AND non-realtime soundfile rendering. This is the >>wonderful musical instrument that is evolving before our very eyes (and >>ears), and Csound already contains all the necessary guts for the thing. > >If expressive power is what you want then why go with Csound? > >Csound : assembly language :: SuperCollider : Smalltalk > >(OK this is crossposted to the Csound list so I can see those >flames rolling in.. 8-0 ) > >Seriously, I would be interested in any serious proposals for >collaboration on a port of SuperCollider to Linux. >I think a SuperCollider + GTK on Linux would be very cool. > >SuperCollider was written from the beginning to be used in real time. >All operations were conceived and written with that in mind. For example >variable delay lines of any maximum length can be allocated and used >immediately without needing to be zeroed out first. (SC can do non >real time just fine too.) > >Right now SC is closed source, however I have been considering >opening the source to the language virtual machine. >Plugins of UGens and language primitives are both possible. >SC was designed for easy plugging in of language primitives. >The virtual machine should be easily portable, there is no >Mac specific code in there. > >-- > >SuperCollider is a dynamically typed, real time garbage collected, >fully object oriented language like Smalltalk with support for true closures, >coroutines, positional or keyword arguments, variable length argument >lists, default argument values, etc. >It has a class library of 341 classes including a full set >of Collection classes like Dictionary, Set, SortedList, etc. >There are currently over 200 unit generators. > >-- > > > --- james mccartney james@audiosynth.com http://www.audiosynth.com >If you have a PowerMac check out SuperCollider2, a real time synth program: > > > > > > >dupswapdrop: the music-dsp mailing list and website >http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html > dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07205; 17 Jun 99 3:17 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uRkE-000257-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 03:17:34 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (DAA11425); Thu, 17 Jun 1999 03:13:56 +0100 (BST) Received: from sunny.ex.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 03:13:45 +0100 Received: from root@renoir.op.net [209.152.193.4] by sunny via ESMTP (DAA08595); Thu, 17 Jun 1999 03:13:54 +0100 (BST) Received: from someip.ppp.op.net (d-bm2-05.ppp.op.net [209.152.194.37]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id WAA10493; Wed, 16 Jun 1999 22:12:31 -0400 (EDT) Message-Id: <199906170212.WAA10493@renoir.op.net> To: music-dsp@shoko.calarts.edu Cc: csound@maths.ex.ac.uk Subject: Re: Csound and other synthesis systems Date: Wed, 16 Jun 1999 22:20:57 -0400 From: Paul Barton-Davis Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk James McCartney writes: >SuperCollider is a dynamically typed, real time garbage collected, >fully object oriented language like Smalltalk with support for true closures, >coroutines, positional or keyword arguments, variable length argument >lists, default argument values, etc. >It has a class library of 341 classes including a full set >of Collection classes like Dictionary, Set, SortedList, etc. >There are currently over 200 unit generators. While I share your conviction neither Csound nor C++ are the right language to write complex algorithmic processes/patches/whatever, that doesn't mean that I think that the same language should be used for both those complex algorithmic processes and the specification of what is essentially a DSP program. There is no justification for a DSP program to contain concepts such as a Dictionary or a SortedList; on the other hand, there is no justification for a sophisticated algorithmic language to be constrained by the execution model embodied in a DSP program. Furthermore, I don't want to have to be stuck with only a single language to program a DSP with - Csound is bad enough, and I don't believe that any other language is perfect for this. What's really important is not the visible language but the inner parse tree that is used to represent DSP programs written in any language. Quasimodo has the basic structure to support multiple DSP languages by compiling them all down to the same internal form, and these different languages are themselves intended to be "plugins". But to return to my point: I don't want a dynamically typed, real time garbage collected, fully object oriented language to write DSP code in. I do want such a language to write higher level abstractions in, and possibly to have it automatically generate DSP code. From what I could read of SuperCollider, this separation doesn't exist. This is not necessarily so bad if one can use the language simply. But its important to take a lesson from the history of Csound: things that are cool and useful ultimately end up as opcodes, not as things written in Csound's orc language. This means that many cool "modules" consist of very little more than a couple of opcode calls. I also don't understand anything of what you said about note on velocity controlling the complexity of a patch. I think you must be describing something rather different than what I think of as a patch, which is essentially the specification of what things are connected together. The best I can imagine is that velocity is used to essentially choose one of a particular set of possible interconnections before any actual sound is generated, but there is no particular reason for this to be part of the language, and in fact, its a lot less flexible than doing this switching visually, via a velocity zone map that acts as a switch to route note information to a particular patch. This can be modified without editing a program, and in theory, the velocity can be patched through something else (e.g. a limiter, or an expander, or whatever) before being used by the zone map. Modular synthesis did have a point to it :) --p Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07229; 17 Jun 99 3:21 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uRnk-00025D-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 03:21:12 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id TAA09295 for music-dsp-outgoing; Wed, 16 Jun 1999 19:12:36 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from renoir.op.net (root@renoir.op.net [209.152.193.4]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id TAA09290 for ; Wed, 16 Jun 1999 19:12:34 -0700 (PDT) Received: from someip.ppp.op.net (d-bm2-05.ppp.op.net [209.152.194.37]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id WAA10493; Wed, 16 Jun 1999 22:12:31 -0400 (EDT) Message-Id: <199906170212.WAA10493@renoir.op.net> To: music-dsp@shoko.calarts.edu Cc: csound@maths.ex.ac.uk Subject: Re: Csound and other synthesis systems Date: Wed, 16 Jun 1999 22:20:57 -0400 From: Paul Barton-Davis Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu James McCartney writes: >SuperCollider is a dynamically typed, real time garbage collected, >fully object oriented language like Smalltalk with support for true closures, >coroutines, positional or keyword arguments, variable length argument >lists, default argument values, etc. >It has a class library of 341 classes including a full set >of Collection classes like Dictionary, Set, SortedList, etc. >There are currently over 200 unit generators. While I share your conviction neither Csound nor C++ are the right language to write complex algorithmic processes/patches/whatever, that doesn't mean that I think that the same language should be used for both those complex algorithmic processes and the specification of what is essentially a DSP program. There is no justification for a DSP program to contain concepts such as a Dictionary or a SortedList; on the other hand, there is no justification for a sophisticated algorithmic language to be constrained by the execution model embodied in a DSP program. Furthermore, I don't want to have to be stuck with only a single language to program a DSP with - Csound is bad enough, and I don't believe that any other language is perfect for this. What's really important is not the visible language but the inner parse tree that is used to represent DSP programs written in any language. Quasimodo has the basic structure to support multiple DSP languages by compiling them all down to the same internal form, and these different languages are themselves intended to be "plugins". But to return to my point: I don't want a dynamically typed, real time garbage collected, fully object oriented language to write DSP code in. I do want such a language to write higher level abstractions in, and possibly to have it automatically generate DSP code. From what I could read of SuperCollider, this separation doesn't exist. This is not necessarily so bad if one can use the language simply. But its important to take a lesson from the history of Csound: things that are cool and useful ultimately end up as opcodes, not as things written in Csound's orc language. This means that many cool "modules" consist of very little more than a couple of opcode calls. I also don't understand anything of what you said about note on velocity controlling the complexity of a patch. I think you must be describing something rather different than what I think of as a patch, which is essentially the specification of what things are connected together. The best I can imagine is that velocity is used to essentially choose one of a particular set of possible interconnections before any actual sound is generated, but there is no particular reason for this to be part of the language, and in fact, its a lot less flexible than doing this switching visually, via a velocity zone map that acts as a switch to route note information to a particular patch. This can be modified without editing a program, and in theory, the velocity can be patched through something else (e.g. a limiter, or an expander, or whatever) before being used by the zone map. Modular synthesis did have a point to it :) --p dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07257; 17 Jun 99 3:36 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uS2T-00025c-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 03:36:25 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (DAA15998); Thu, 17 Jun 1999 03:32:44 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 03:32:33 +0100 Received: from first1.lnk.telstra.net [139.130.48.118] by hermes via ESMTP (DAA15111); Thu, 17 Jun 1999 03:32:29 +0100 (BST) Received: from firstpr.com.au (wira.firstpr.com.au [203.36.57.201]) by gair.firstpr.com.au (8.8.7/8.8.7) with ESMTP id MAA14396; Thu, 17 Jun 1999 12:39:48 +1000 Message-ID: <37685D9D.1FE8EE04@firstpr.com.au> Date: Thu, 17 Jun 1999 12:29:49 +1000 From: Robin Whittle Organization: First Principles & Real World Interfaces X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: pete moss CC: music-dsp@shoko.calarts.edu, CSOUND Subject: cmusic Was: Csound and other synthesis systems References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C895.4B7F857A@firstpr.com.au> <3767E49F.E1679F6B@bigfoot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Pete Moss pointed out that what I described as my long term plan (a framework for C++ to support realtime synthesis) is akin to cmusic. I think this is true. This post looks at what I understand about cmusic and how it only produces a single sample of audio per ugen call, compared to Csound which produces ksmps samples, and so can be very much faster. Looking at Dave Philip's marvellous link-farm on software synthesis: http://www.bright.net/~dlphilp/linux_soundapps.html leads me to Tim Thompson's venerable PLUM page on music languages, which should be at: http://www.nosuch.com/plum but this file is absent at present. (I emailed Tim.) Searching for "cmusic" is tricky, but I found something from 1994 at: ftp://ccrma-ftp.stanford.edu/pub/cmusic/ I also found some descriptive text at: http://www.gsu.edu/webfs01/mus/musrst/public_html/cara/courses/ Csound_Users_Seminar/acoustic.html which states that cmusic was written in 1980 by F. R. (Dick) Moore. Like Csound, cmusic's lineage is traceable to Music V. Please correct me if I am wrong, but it is my understanding that both Music V and cmusic call the code for a unit-generator, and that code produces just one sample of audio output. Csound's distinguishing characteristic is that it has a variable "ksmps" which tells the unit generator how many samples to calculate. ksmps can be 1, but then Csound runs rather slowly, as would Music V and cmusic. Generally ksmps is 5 to 25 or so - and so the overhead of running the central loops and calling unit generator functions is spread over the production of many more audio samples. Csound therefore has "k" and "a" rate signals, with the orchestra file determining the ksmps rato between them. This makes for some ugly complications trying to maintain and translate between two separate kinds of variable, but it makes Csound run *lots* faster. This is particularly true in "draft" mode where you set ksmps rather high to test the composition out, albeit with lousy sound quality. When the composition is complete, then set ksmps to 2 or 3 and leave the computer cooking overnight to produce the final rendering. Speed is absolutely crucial in this field, since computers are still slow compared to the rich analogue world of zillion-path reverberation which we know and love. I remember trying to understand cmusic a few years ago, but I never got very far. Perhaps it was because I discovered it could not run as fast as Csound. Does anyone have more information about cmusic? Generally with other software synthesis programs I have looked, I lost interest when I found that either they did not support ksmps samples per call (this includes most programs and Kyma/Capybara http://www.symbolicsound.com ), or they start with a particular high-level model of what constitutes "music" which doesn't suit me. Kyma looks amazing and is certainly an inspiration, but it runs on specialised hardware, uses integers rather than floats and has a limited memory capacity per CPU. - Robin =============================================================== Robin Whittle rw@firstpr.com.au http://www.firstpr.com.au Heidelberg Heights, Melbourne, Australia First Principles Research and expression: Consulting and technical writing. Music. Internet music marketing. Telecommunications. Consumer advocacy in telecommunications, especially privacy. M-F relationships. Kinetic sculpture. Real World Electronics and software for music including: Interfaces Devil Fish mods for the TB-303, Akai sampler memory and Csound synthesis software. =============================================================== Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07267; 17 Jun 99 3:43 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uS8z-00025g-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 03:43:09 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id TAA09710 for music-dsp-outgoing; Wed, 16 Jun 1999 19:32:36 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from gair.firstpr.com.au (first1.lnk.telstra.net [139.130.48.118]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id TAA09706 for ; Wed, 16 Jun 1999 19:32:33 -0700 (PDT) Received: from firstpr.com.au (wira.firstpr.com.au [203.36.57.201]) by gair.firstpr.com.au (8.8.7/8.8.7) with ESMTP id MAA14396; Thu, 17 Jun 1999 12:39:48 +1000 Message-ID: <37685D9D.1FE8EE04@firstpr.com.au> Date: Thu, 17 Jun 1999 12:29:49 +1000 From: Robin Whittle Organization: First Principles & Real World Interfaces X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: pete moss CC: music-dsp@shoko.calarts.edu, CSOUND Subject: cmusic Was: Csound and other synthesis systems References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C895.4B7F857A@firstpr.com.au> <3767E49F.E1679F6B@bigfoot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu Pete Moss pointed out that what I described as my long term plan (a framework for C++ to support realtime synthesis) is akin to cmusic. I think this is true. This post looks at what I understand about cmusic and how it only produces a single sample of audio per ugen call, compared to Csound which produces ksmps samples, and so can be very much faster. Looking at Dave Philip's marvellous link-farm on software synthesis: http://www.bright.net/~dlphilp/linux_soundapps.html leads me to Tim Thompson's venerable PLUM page on music languages, which should be at: http://www.nosuch.com/plum but this file is absent at present. (I emailed Tim.) Searching for "cmusic" is tricky, but I found something from 1994 at: ftp://ccrma-ftp.stanford.edu/pub/cmusic/ I also found some descriptive text at: http://www.gsu.edu/webfs01/mus/musrst/public_html/cara/courses/ Csound_Users_Seminar/acoustic.html which states that cmusic was written in 1980 by F. R. (Dick) Moore. Like Csound, cmusic's lineage is traceable to Music V. Please correct me if I am wrong, but it is my understanding that both Music V and cmusic call the code for a unit-generator, and that code produces just one sample of audio output. Csound's distinguishing characteristic is that it has a variable "ksmps" which tells the unit generator how many samples to calculate. ksmps can be 1, but then Csound runs rather slowly, as would Music V and cmusic. Generally ksmps is 5 to 25 or so - and so the overhead of running the central loops and calling unit generator functions is spread over the production of many more audio samples. Csound therefore has "k" and "a" rate signals, with the orchestra file determining the ksmps rato between them. This makes for some ugly complications trying to maintain and translate between two separate kinds of variable, but it makes Csound run *lots* faster. This is particularly true in "draft" mode where you set ksmps rather high to test the composition out, albeit with lousy sound quality. When the composition is complete, then set ksmps to 2 or 3 and leave the computer cooking overnight to produce the final rendering. Speed is absolutely crucial in this field, since computers are still slow compared to the rich analogue world of zillion-path reverberation which we know and love. I remember trying to understand cmusic a few years ago, but I never got very far. Perhaps it was because I discovered it could not run as fast as Csound. Does anyone have more information about cmusic? Generally with other software synthesis programs I have looked, I lost interest when I found that either they did not support ksmps samples per call (this includes most programs and Kyma/Capybara http://www.symbolicsound.com ), or they start with a particular high-level model of what constitutes "music" which doesn't suit me. Kyma looks amazing and is certainly an inspiration, but it runs on specialised hardware, uses integers rather than floats and has a limited memory capacity per CPU. - Robin =============================================================== Robin Whittle rw@firstpr.com.au http://www.firstpr.com.au Heidelberg Heights, Melbourne, Australia First Principles Research and expression: Consulting and technical writing. Music. Internet music marketing. Telecommunications. Consumer advocacy in telecommunications, especially privacy. M-F relationships. Kinetic sculpture. Real World Electronics and software for music including: Interfaces Devil Fish mods for the TB-303, Akai sampler memory and Csound synthesis software. =============================================================== dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07319; 17 Jun 99 4:23 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uSlb-0007oV-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 04:23:03 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (EAA13647); Thu, 17 Jun 1999 04:19:36 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 04:19:25 +0100 Received: from rothko.bestweb.net [209.94.100.160] by hermes via ESMTP (EAA12005); Thu, 17 Jun 1999 04:19:24 +0100 (BST) Received: from goodguy (dialin-17.poughkeepsie.bestweb.net [209.94.109.51]) by rothko.bestweb.net (8.9.1a/8.9.0) with SMTP id XAA10378; Wed, 16 Jun 1999 23:16:50 -0400 (EDT) Message-ID: <37684988.4433C3BC@westnet.com> Date: Thu, 17 Jun 1999 01:04:08 +0000 From: Larry Troxler X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.31 i586) MIME-Version: 1.0 To: Robin Whittle CC: pete moss , music-dsp@shoko.calarts.edu, CSOUND Subject: ksmps Was: Re: cmusic Was: Csound and other synthesis systems References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C895.4B7F857A@firstpr.com.au> <3767E49F.E1679F6B@bigfoot.com> <37685D9D.1FE8EE04@firstpr.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk > Please correct me if I am wrong, but it is my understanding that both > Music V and cmusic call the code for a unit-generator, and that code > produces just one sample of audio output. Csound's distinguishing > characteristic is that it has a variable "ksmps" which tells the unit > generator how many samples to calculate. ksmps can be 1, but then > Csound runs rather slowly, as would Music V and cmusic. Generally > ksmps is 5 to 25 or so - and so the overhead of running the central > loops and calling unit generator functions is spread over the > production of many more audio samples. > > Csound therefore has "k" and "a" rate signals, with the orchestra file > determining the ksmps rato between them. This makes for some ugly > complications trying to maintain and translate between two separate > kinds of variable, but it makes Csound run *lots* faster. This is > particularly true in "draft" mode where you set ksmps rather high to > test the composition out, albeit with lousy sound quality. When the > composition is complete, then set ksmps to 2 or 3 and leave the > computer cooking overnight to produce the final rendering. > Now this ksmps != asmps issue is something that I've always wondered about, as far as performance. My first question, would be how many orcs and scores require ksmps == 1? Isn't it a lot? The times I worked with Csound, I often needed to set ksmps==1 to allow instruments that use audio feedback to work properly. I don't mean cases where it just wouldn't sound as good. I mean rather, any case where you use feeback, in which case things won't work at all, unless you forget about multiple ksmps per audio frame. Perhaps however, I am not enough Csound-aware to know of all the work-arounds in certain situations to avoid having to use ksamps==1. But it seems that any instruement in a composition that uses audio feedback will require ksmps=1 to realize the entire composition! (unless of course, Make or something similar is used, togethre with audio mixer scripts, in which case Csound can be invoked on a per-part basis, with the parts mixed together afterward) I am actually quite surprised that use ksamps>1 results in "*lots" faster efficiency! Is this true for processors with tiny cache only (this would make sense - run a tight, small loop in each ugen, which will run entirely in cache) , or does it somehow also result in improvements for situations where the entire audio chain can be cached? But to get to my point - assuming that there are indeed a lot of cases where you need ksmps==1, then doesn't this result in some serious innefficiency for this common case? Don't all the audio ugens need to use a loop to process all thee samples in one ksmps-size buffer? And for the common case where ksmps==1, you would think that this would be horribly slow compare to an implementation where the ugens would not loop, but simply process one sample (or better yet, Csound would generate C code to implement each instrument - ala CLM) What am I missing here? Is it just accepted that Csound isn't exactly built for speed, but is enticing to use because of its large opcode seleection? Larry Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07329; 17 Jun 99 4:28 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uSql-00027E-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 04:28:24 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id UAA10451 for music-dsp-outgoing; Wed, 16 Jun 1999 20:19:25 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from rothko.bestweb.net (rothko.bestweb.net [209.94.100.160]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id UAA10447 for ; Wed, 16 Jun 1999 20:19:23 -0700 (PDT) Received: from goodguy (dialin-17.poughkeepsie.bestweb.net [209.94.109.51]) by rothko.bestweb.net (8.9.1a/8.9.0) with SMTP id XAA10378; Wed, 16 Jun 1999 23:16:50 -0400 (EDT) Message-ID: <37684988.4433C3BC@westnet.com> Date: Thu, 17 Jun 1999 01:04:08 +0000 From: Larry Troxler X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.31 i586) MIME-Version: 1.0 To: Robin Whittle CC: pete moss , music-dsp@shoko.calarts.edu, CSOUND Subject: ksmps Was: Re: cmusic Was: Csound and other synthesis systems References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C895.4B7F857A@firstpr.com.au> <3767E49F.E1679F6B@bigfoot.com> <37685D9D.1FE8EE04@firstpr.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu > Please correct me if I am wrong, but it is my understanding that both > Music V and cmusic call the code for a unit-generator, and that code > produces just one sample of audio output. Csound's distinguishing > characteristic is that it has a variable "ksmps" which tells the unit > generator how many samples to calculate. ksmps can be 1, but then > Csound runs rather slowly, as would Music V and cmusic. Generally > ksmps is 5 to 25 or so - and so the overhead of running the central > loops and calling unit generator functions is spread over the > production of many more audio samples. > > Csound therefore has "k" and "a" rate signals, with the orchestra file > determining the ksmps rato between them. This makes for some ugly > complications trying to maintain and translate between two separate > kinds of variable, but it makes Csound run lots* faster. This is > particularly true in "draft" mode where you set ksmps rather high to > test the composition out, albeit with lousy sound quality. When the > composition is complete, then set ksmps to 2 or 3 and leave the > computer cooking overnight to produce the final rendering. > Now this ksmps != asmps issue is something that I've always wondered about, as far as performance. My first question, would be how many orcs and scores require ksmps == 1? Isn't it a lot? The times I worked with Csound, I often needed to set ksmps==1 to allow instruments that use audio feedback to work properly. I don't mean cases where it just wouldn't sound as good. I mean rather, any case where you use feeback, in which case things won't work at all, unless you forget about multiple ksmps per audio frame. Perhaps however, I am not enough Csound-aware to know of all the work-arounds in certain situations to avoid having to use ksamps==1. But it seems that any instruement in a composition that uses audio feedback will require ksmps=1 to realize the entire composition! (unless of course, Make or something similar is used, togethre with audio mixer scripts, in which case Csound can be invoked on a per-part basis, with the parts mixed together afterward) I am actually quite surprised that use ksamps>1 results in "*lots" faster efficiency! Is this true for processors with tiny cache only (this would make sense - run a tight, small loop in each ugen, which will run entirely in cache) , or does it somehow also result in improvements for situations where the entire audio chain can be cached? But to get to my point - assuming that there are indeed a lot of cases where you need ksmps==1, then doesn't this result in some serious innefficiency for this common case? Don't all the audio ugens need to use a loop to process all thee samples in one ksmps-size buffer? And for the common case where ksmps==1, you would think that this would be horribly slow compare to an implementation where the ugens would not loop, but simply process one sample (or better yet, Csound would generate C code to implement each instrument - ala CLM) What am I missing here? Is it just accepted that Csound isn't exactly built for speed, but is enticing to use because of its large opcode seleection? Larry dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07360; 17 Jun 99 4:45 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uT7T-0007ob-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 04:45:40 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (EAA16008); Thu, 17 Jun 1999 04:42:11 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 04:42:00 +0100 Received: from out4.ibm.net [165.87.194.239] by hermes via ESMTP (EAA01574); Thu, 17 Jun 1999 04:41:59 +0100 (BST) Received: from ibm.net (slip-32-101-77-186.dc.us.ibm.net [32.101.77.186]) by out4.ibm.net (8.8.5/8.6.9) with ESMTP id DAA88992; Thu, 17 Jun 1999 03:41:42 GMT Message-ID: <37686F90.589D06EF@ibm.net> Date: Wed, 16 Jun 1999 23:46:24 -0400 From: "Job M. van Zuijlen" Reply-To: zuijlen@ibm.net Organization: electona X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Robin Whittle CC: music-dsp@shoko.calarts.edu, CSOUND Subject: Re: cmusic Was: Csound and other synthesis systems References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C895.4B7F857A@firstpr.com.au> <3767E49F.E1679F6B@bigfoot.com> <37685D9D.1FE8EE04@firstpr.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk There is a book by F. Richard Moore called "Elements of Computer Music", which includes information about cmusic. The book is published by Prentice Hall in 1990 (ISBN 0-13-252552-6). I bought in 1990, I don't know if it's still available. One impression I have from cmusic is that it doesn't have an active user community in the sense that Csound has one, and that it doesn't really evolve at the moment. A reason for me to ignore it. The book is interesting though, in particular for people who want to implement their own stuff. Job van Zuijlen Robin Whittle wrote: > > > Does anyone have more information about cmusic? > > Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07435; 17 Jun 99 5:24 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uTjD-0007oz-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 05:24:39 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (FAA17707); Thu, 17 Jun 1999 05:20:51 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 05:20:38 +0100 Received: from first1.lnk.telstra.net [139.130.48.118] by hermes via ESMTP (FAA00835); Thu, 17 Jun 1999 05:20:35 +0100 (BST) Received: from firstpr.com.au (wira.firstpr.com.au [203.36.57.201]) by gair.firstpr.com.au (8.8.7/8.8.7) with ESMTP id OAA14681; Thu, 17 Jun 1999 14:28:11 +1000 Message-ID: <37687703.14129C5D@firstpr.com.au> Date: Thu, 17 Jun 1999 14:18:11 +1000 From: Robin Whittle Organization: First Principles & Real World Interfaces X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: music-dsp@shoko.calarts.edu CC: pete moss , CSOUND Subject: Re: ksmps Was: Re: cmusic Was: Csound and other synthesis systems References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C895.4B7F857A@firstpr.com.au> <3767E49F.E1679F6B@bigfoot.com> <37685D9D.1FE8EE04@firstpr.com.au> <37684988.4433C3BC@westnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk I agree with what Larry Troxler wrote about how important it is for ksmps to be 1 in some applications - particularly those involving audio feedback. Ideally a system would enable some parts to be executed with various ksmps rates. It is a tall order, and the sort of thing I am contemplating for "Topsy" which is pure vapour-ware at present and likely to remain so for several years at least. Larger ksmps values certainly does speed calculations! In one elaborate Csound piece I did in 1996 (admittedly this was on a 100MHz AMD 486) ksmps=10 was 2.1 times faster than ksmps=3. Life is too short to try this at ksmps=1, since it took 36 hours to cook at my final rendering quality of ksmps=3. The piece had a mix of general simple Csound ugens and extensive use of a very large ugen of my own. For me, there are enough things which can be done with ksmps > 1 to make it worth the trouble. It is easy to dream of complexities of sound creation and reverberation which would tie up any amount of computing resources - so processing speed directly translates into the final sonic sophistication of the music and/or the ability of the composer to run it time and again whilst refining it. For instance I figured out how many paths of sound reach the head in a rectangular room, from a single source, allowing for direct, single wall, two wall, etc. up to six wall reflections. Not counting the sound hitting the same wall twice (and therefore not counting real reverberation), there were about 1956 paths - each which would ideally be processed by a CPU intensive binaural algorithm. The physical world is a very rich place, and if we want to do anything of similar finesse on a CPU, it is worth finding the fastest way of doing it. - Robin =============================================================== Robin Whittle rw@firstpr.com.au http://www.firstpr.com.au Heidelberg Heights, Melbourne, Australia First Principles Research and expression: Consulting and technical writing. Music. Internet music marketing. Telecommunications. Consumer advocacy in telecommunications, especially privacy. M-F relationships. Kinetic sculpture. Real World Electronics and software for music including: Interfaces Devil Fish mods for the TB-303, Akai sampler memory and Csound synthesis software. =============================================================== Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07446; 17 Jun 99 5:29 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uTns-00027s-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 05:29:28 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (FAA16136); Thu, 17 Jun 1999 05:26:04 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 05:25:53 +0100 Received: from dns2.seanet.com [199.181.164.2] by hermes via ESMTP (FAA08972); Thu, 17 Jun 1999 05:25:52 +0100 (BST) Received: from seanet.com (cy27.dialup.seanet.com [207.12.136.27]) by mx.seanet.com (8.9.3/Seanet-8.7.3) with ESMTP id VAA17919; Wed, 16 Jun 1999 21:25:59 -0700 (PDT) Message-ID: <37687A4B.802B0107@seanet.com> Date: Wed, 16 Jun 1999 21:32:11 -0700 From: Sean Costello X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: Michael Gogins CC: music-dsp@shoko.calarts.edu, CSOUND Subject: Re: Csound and other synthesis systems References: <008401beb84e$b4be8fe0$79d496c0@Realizer.ngt.sungard.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Michael Gogins wrote: > I would love if it SuperCollider: > > (a) ran on Windows > (b) had plugin unit generators (or words in its language - is that even > possible?) > (c) had an external API > (d) ran on Windows I would like to put my vote in for Linux, or BeOS, or anything that runs on an Intel-type processor. I will buy BeOS in a second, just to run SuperCollider. I have seen SuperCollider demoed, and am very impressed. I would also like to have the capability of creating unit generators or the equivalent (I've just completed some nice Csound ugens, and would love to use them in the SuperCollider environment). Sean Costello Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07454; 17 Jun 99 5:32 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uTqJ-0002CO-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 05:32:00 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id VAA11281 for music-dsp-outgoing; Wed, 16 Jun 1999 21:20:39 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from gair.firstpr.com.au (first1.lnk.telstra.net [139.130.48.118]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id VAA11277 for ; Wed, 16 Jun 1999 21:20:36 -0700 (PDT) Received: from firstpr.com.au (wira.firstpr.com.au [203.36.57.201]) by gair.firstpr.com.au (8.8.7/8.8.7) with ESMTP id OAA14681; Thu, 17 Jun 1999 14:28:11 +1000 Message-ID: <37687703.14129C5D@firstpr.com.au> Date: Thu, 17 Jun 1999 14:18:11 +1000 From: Robin Whittle Organization: First Principles & Real World Interfaces X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: music-dsp@shoko.calarts.edu CC: pete moss , CSOUND Subject: Re: ksmps Was: Re: cmusic Was: Csound and other synthesis systems References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C895.4B7F857A@firstpr.com.au> <3767E49F.E1679F6B@bigfoot.com> <37685D9D.1FE8EE04@firstpr.com.au> <37684988.4433C3BC@westnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu I agree with what Larry Troxler wrote about how important it is for ksmps to be 1 in some applications - particularly those involving audio feedback. Ideally a system would enable some parts to be executed with various ksmps rates. It is a tall order, and the sort of thing I am contemplating for "Topsy" which is pure vapour-ware at present and likely to remain so for several years at least. Larger ksmps values certainly does speed calculations! In one elaborate Csound piece I did in 1996 (admittedly this was on a 100MHz AMD 486) ksmps=10 was 2.1 times faster than ksmps=3. Life is too short to try this at ksmps=1, since it took 36 hours to cook at my final rendering quality of ksmps=3. The piece had a mix of general simple Csound ugens and extensive use of a very large ugen of my own. For me, there are enough things which can be done with ksmps > 1 to make it worth the trouble. It is easy to dream of complexities of sound creation and reverberation which would tie up any amount of computing resources - so processing speed directly translates into the final sonic sophistication of the music and/or the ability of the composer to run it time and again whilst refining it. For instance I figured out how many paths of sound reach the head in a rectangular room, from a single source, allowing for direct, single wall, two wall, etc. up to six wall reflections. Not counting the sound hitting the same wall twice (and therefore not counting real reverberation), there were about 1956 paths - each which would ideally be processed by a CPU intensive binaural algorithm. The physical world is a very rich place, and if we want to do anything of similar finesse on a CPU, it is worth finding the fastest way of doing it. - Robin =============================================================== Robin Whittle rw@firstpr.com.au http://www.firstpr.com.au Heidelberg Heights, Melbourne, Australia First Principles Research and expression: Consulting and technical writing. Music. Internet music marketing. Telecommunications. Consumer advocacy in telecommunications, especially privacy. M-F relationships. Kinetic sculpture. Real World Electronics and software for music including: Interfaces Devil Fish mods for the TB-303, Akai sampler memory and Csound synthesis software. =============================================================== dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07463; 17 Jun 99 5:34 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uTsd-0002CS-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 05:34:23 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id VAA11375 for music-dsp-outgoing; Wed, 16 Jun 1999 21:26:03 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from mx.seanet.com (dns2.seanet.com [199.181.164.2]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id VAA11371 for ; Wed, 16 Jun 1999 21:26:01 -0700 (PDT) Received: from seanet.com (cy27.dialup.seanet.com [207.12.136.27]) by mx.seanet.com (8.9.3/Seanet-8.7.3) with ESMTP id VAA17919; Wed, 16 Jun 1999 21:25:59 -0700 (PDT) Message-ID: <37687A4B.802B0107@seanet.com> Date: Wed, 16 Jun 1999 21:32:11 -0700 From: Sean Costello X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: Michael Gogins CC: music-dsp@shoko.calarts.edu, CSOUND Subject: Re: Csound and other synthesis systems References: <008401beb84e$b4be8fe0$79d496c0@Realizer.ngt.sungard.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu Michael Gogins wrote: > I would love if it SuperCollider: > > (a) ran on Windows > (b) had plugin unit generators (or words in its language - is that even > possible?) > (c) had an external API > (d) ran on Windows I would like to put my vote in for Linux, or BeOS, or anything that runs on an Intel-type processor. I will buy BeOS in a second, just to run SuperCollider. I have seen SuperCollider demoed, and am very impressed. I would also like to have the capability of creating unit generators or the equivalent (I've just completed some nice Csound ugens, and would love to use them in the SuperCollider environment). Sean Costello dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07487; 17 Jun 99 5:56 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uUEK-0007to-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 05:56:48 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (FAA12795); Thu, 17 Jun 1999 05:53:17 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 05:53:06 +0100 Received: from mercury.acs.unt.edu [129.120.220.1] by hermes via ESMTP (FAA09181); Thu, 17 Jun 1999 05:53:05 +0100 (BST) Received: from venus.acs.unt.edu (venus.acs.unt.edu [129.120.220.72]) by Mercury.unix.acs.cc.unt.edu (8.8.8/8.8.8) with ESMTP id XAA10321; Wed, 16 Jun 1999 23:53:03 -0500 (CDT) Received: from jove.acs.unt.edu (pras118.local.premium.dialup.unt.edu [129.120.217.118]) by venus.acs.unt.edu (8.8.8/8.8.8) with ESMTP id XAA10405; Wed, 16 Jun 1999 23:53:00 -0500 (CDT) Message-ID: <37689AC8.9F474221@jove.acs.unt.edu> Date: Wed, 16 Jun 1999 23:50:48 -0700 From: "Michael A. Thompson" X-Mailer: Mozilla 4.6C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Paul Barton-Davis CC: music-dsp@shoko.calarts.edu, csound@maths.ex.ac.uk Subject: Re: Csound and other synthesis systems References: <199906170212.WAA10493@renoir.op.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk In the perfect world we will have a DSP program that has good "real-time" performance, a GUI front end, and a very strong and powerful back end language that is structured, objectified, and extensible and that also covers not only the DSP-audio rate instrument design but includes support for embedded control-rate performance oriented code. Something that brings together the idea of the instrument and how it is performed in one script or program. Max/MSP and SuperCollider are the closest to this idea in my opinion. I cant stand brain dead GUI music apps that dont give the user any control for doing music or sound design other than pop - retro - dance related compositions or factory preset midi music. At the same time I dont want to have to learn 500 different languages. But I am more inclined to learn the languages than use something that I cant control. Michael Paul Barton-Davis wrote: > > James McCartney writes: > > >SuperCollider is a dynamically typed, real time garbage collected, > >fully object oriented language like Smalltalk with support for true closures, > >coroutines, positional or keyword arguments, variable length argument > >lists, default argument values, etc. > >It has a class library of 341 classes including a full set > >of Collection classes like Dictionary, Set, SortedList, etc. > >There are currently over 200 unit generators. > > While I share your conviction neither Csound nor C++ are the right > language to write complex algorithmic processes/patches/whatever, that > doesn't mean that I think that the same language should be used for > both those complex algorithmic processes and the specification of what > is essentially a DSP program. > > There is no justification for a DSP program to contain concepts such > as a Dictionary or a SortedList; on the other hand, there is no > justification for a sophisticated algorithmic language to be > constrained by the execution model embodied in a DSP program. > > Furthermore, I don't want to have to be stuck with only a single > language to program a DSP with - Csound is bad enough, and I don't > believe that any other language is perfect for this. What's really > important is not the visible language but the inner parse tree that is > used to represent DSP programs written in any language. Quasimodo has > the basic structure to support multiple DSP languages by compiling > them all down to the same internal form, and these different languages > are themselves intended to be "plugins". > > But to return to my point: I don't want* a dynamically typed, real > time garbage collected, fully object oriented language to write DSP > code in. I do want such a language to write higher level > abstractions in, and possibly to have it automatically generate DSP > code. From what I could read of SuperCollider, this separation doesn't > exist. This is not necessarily so bad if one can use the language > simply. But its important to take a lesson from the history of Csound: > things that are cool and useful ultimately end up as opcodes, not as > things written in Csound's orc language. This means that many cool > "modules" consist of very little more than a couple of opcode > calls. > > I also don't understand anything of what you said about note on > velocity controlling the complexity of a patch. I think you must be > describing something rather different than what I think of as a patch, > which is essentially the specification of what things are connected > together. The best I can imagine is that velocity is used to > essentially choose one of a particular set of possible > interconnections before any actual sound is generated, but there is no > particular reason for this to be part of the language, and in fact, > its a lot less flexible than doing this switching visually, via a > velocity zone map that acts as a switch to route note information to a > particular patch. This can be modified without editing a program, and > in theory, the velocity can be patched through something else (e.g. a > limiter, or an expander, or whatever) before being used by the zone > map. Modular synthesis did have a point to it :) > > --p -- ---------------------------------- Michael A. Thompson [IRIX - NeXTStep - Linux - MacOS - Windows] Home: (940)382-2086 E-Mail: mat0001@jove.acs.unt.edu ---------------------------------- Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07496; 17 Jun 99 6:00 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uUHQ-0007ts-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 06:00:00 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (FAA12943); Thu, 17 Jun 1999 05:56:36 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 05:56:25 +0100 Received: from tt56361@kielo.uta.fi [153.1.1.10] by hermes via ESMTP (FAA06350); Thu, 17 Jun 1999 05:56:24 +0100 (BST) Received: from localhost (tt56361@localhost) by kielo.uta.fi (8.8.7/8.8.2) with ESMTP id HAA27578; Thu, 17 Jun 1999 07:56:05 +0300 (EET DST) Date: Thu, 17 Jun 1999 07:56:05 +0300 (EET DST) From: Timo Tossavainen X-Sender: tt56361@kielo To: Robin Whittle cc: music-dsp@shoko.calarts.edu, pete moss , CSOUND Subject: Re: ksmps Was: Re: cmusic Was: Csound and other synthesis systems In-Reply-To: <37687703.14129C5D@firstpr.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk On Thu, 17 Jun 1999, Robin Whittle wrote: > I agree with what Larry Troxler wrote about how important it is for > ksmps to be 1 in some applications - particularly those involving > audio feedback. > > Ideally a system would enable some parts to be executed with various > ksmps rates. It is a tall order, and the sort of thing I am > contemplating for "Topsy" which is pure vapour-ware at present and > likely to remain so for several years at least. This not actually very hard to do. Just solve the strongly connected components of the signal flow network and at same time you get the order of the update from the first DFS. You can use any ksmps in UG which form a component by themselves and ksmps = 1 in components that have more UGs. In code you have to handle the connections between the components as special cases (ie. fill output vectors from the outputs from the components and feed single input samples to the inputs leading to the component). Doing this while the user dynamically alters the connections isn't that easy. Possible ? probably. Wouldn't it be best to implement a compiler, that compiles the UG network to a single monolithic piece of code and then gets rid of the function calls and unnecessary memory accesses, that are making the synth slower at kr = sr. In that there would still be some use for using vectors of data to keep the most of the data needed in calculations (for example, filter coefficients) in registers. For instance have it generate C and turn it into something like a DLL and then use that. Of course it would be a lot easier in Lisp, since you can generate and compile code in memory and don't need to invoke the compiler in a shell. Timo Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07514; 17 Jun 99 6:07 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uUOC-0007ty-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 06:07:00 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id VAA12050 for music-dsp-outgoing; Wed, 16 Jun 1999 21:56:33 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from kielo.uta.fi (tt56361@kielo.uta.fi [153.1.1.10]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id VAA12046 for ; Wed, 16 Jun 1999 21:56:31 -0700 (PDT) Received: from localhost (tt56361@localhost) by kielo.uta.fi (8.8.7/8.8.2) with ESMTP id HAA27578; Thu, 17 Jun 1999 07:56:05 +0300 (EET DST) Date: Thu, 17 Jun 1999 07:56:05 +0300 (EET DST) From: Timo Tossavainen X-Sender: tt56361@kielo To: Robin Whittle cc: music-dsp@shoko.calarts.edu, pete moss , CSOUND Subject: Re: ksmps Was: Re: cmusic Was: Csound and other synthesis systems In-Reply-To: <37687703.14129C5D@firstpr.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu On Thu, 17 Jun 1999, Robin Whittle wrote: > I agree with what Larry Troxler wrote about how important it is for > ksmps to be 1 in some applications - particularly those involving > audio feedback. > > Ideally a system would enable some parts to be executed with various > ksmps rates. It is a tall order, and the sort of thing I am > contemplating for "Topsy" which is pure vapour-ware at present and > likely to remain so for several years at least. This not actually very hard to do. Just solve the strongly connected components of the signal flow network and at same time you get the order of the update from the first DFS. You can use any ksmps in UG which form a component by themselves and ksmps = 1 in components that have more UGs. In code you have to handle the connections between the components as special cases (ie. fill output vectors from the outputs from the components and feed single input samples to the inputs leading to the component). Doing this while the user dynamically alters the connections isn't that easy. Possible ? probably. Wouldn't it be best to implement a compiler, that compiles the UG network to a single monolithic piece of code and then gets rid of the function calls and unnecessary memory accesses, that are making the synth slower at kr = sr. In that there would still be some use for using vectors of data to keep the most of the data needed in calculations (for example, filter coefficients) in registers. For instance have it generate C and turn it into something like a DLL and then use that. Of course it would be a lot easier in Lisp, since you can generate and compile code in memory and don't need to invoke the compiler in a shell. Timo dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07536; 17 Jun 99 6:14 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uUUz-0007u4-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 06:14:01 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (GAA12398); Thu, 17 Jun 1999 06:09:21 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 06:09:08 +0100 Received: from sm2.texas.rr.com [24.93.35.55] by hermes via ESMTP (GAA13055); Thu, 17 Jun 1999 06:09:07 +0100 (BST) Received: from [24.93.53.161] ([24.93.53.161]) by Mail.austin.rr.com with Microsoft SMTPSVC(5.5.1875.185.18); Thu, 17 Jun 1999 00:06:29 -0500 X-Sender: asynth@mail.io.com Message-Id: In-Reply-To: <199906170212.WAA10493@renoir.op.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Jun 1999 00:12:18 -0600 To: Paul Barton-Davis , music-dsp@shoko.calarts.edu From: James McCartney Subject: Re: Csound and other synthesis systems Cc: csound@maths.ex.ac.uk Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk At 8:20 PM -0600 6/16/99, Paul Barton-Davis wrote: >There is no justification for a DSP program to contain concepts such >as a Dictionary or a SortedList; on the other hand, there is no >justification for a sophisticated algorithmic language to be >constrained by the execution model embodied in a DSP program. Just because you cannot justify it to yourself does not mean that there are no justifiable uses. And the algorithmic language is in no way constrained or vice versa. In fact you have much greater flexibility because your algorithmic composition can get down and mess with the building structure of your DSP algorithms. I do this a lot. It is very powerful. Maybe you need to use your imagination a bit more. >But to return to my point: I don't want a dynamically typed, real >time garbage collected, fully object oriented language to write DSP >code in. The SC language does not implement the UGens, it creates the patching structure. Again I think that because you have never used it or been exposed to what you can do, you do not realize the power there. >From what I could read of SuperCollider, this separation doesn't >exist. This is not necessarily so bad if one can use the language >simply. Sure you can. There is an OrcScore ugen that can be used just like you would write a csound numeric score. >I also don't understand anything of what you said about note on >velocity controlling the complexity of a patch. I think you must be >describing something rather different than what I think of as a patch, >which is essentially the specification of what things are connected >together. The best I can imagine is that velocity is used to >essentially choose one of a particular set of possible >interconnections before any actual sound is generated, In supercollider your orchestra is not just some dead code. Unit generators are real objects and can be manipulated and combined in real time. In SuperCollider you are not defining a static structure beforehand but are building a graph of ugens in real time for each event. For example I can write in supercollider the following: n.do({ z = AllpassN.ar(z, 0.05, 0.05.rand, 2); }); This creates a daisy chain of n allpass delay lines. Now I can map n to some patch argument such as velocity and that will cause the number of allpass delays in series to be equal to n. In other words the structure of the patch can change per event. Now you could implement this as a lookup table of patches in a static language, but then if I went and added more structural mappings in SC, you'd begin to have a combinatorial explosion to match it in a static language. >particular reason for this to be part of the language, and in fact, >its a lot less flexible than doing this switching visually, via a >velocity zone map that acts as a switch to route note information to a >particular patch. There is so much more you can do than this. For example in SC if I write a function to be a simple sine wave instrument: f = { arg freq = 440.0, amp = 1.0; SinOsc.ar(freq, 0, EnvGen.ar(env, amp)); }; Now I can call it as follows giving it float arguments : Synth.play({ f.value(800.0, 0.2); }); Or I can call it with other sub patches as arguments: Synth.play({ f.value( XLine.kr(300, 2000, 4), SinOsc.kr(5, 0, 0.2, 0.4) ) }); Thus I am parameterizing a predefined patch function with other patches to create a new one. This can be done from within a score. So that you can write glissandi and such into your score and you don't have to worry that your patch was originally built to be able to do a glissando, you just plug in any control function per event. Such things like evolving new programmatically constructed patches via some performer directed process is possible in SC. And I have not mentioned other things like doing list processing on arrays of channels, multichannel expansion, spawning subpatches, etc. None of this is as flexible in a static environment. btw: In SC all scheduled event start times are sample accurate and ksmps is settable per event. --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07555; 17 Jun 99 6:18 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uUZ4-0007uC-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 06:18:14 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id WAA12418 for music-dsp-outgoing; Wed, 16 Jun 1999 22:09:25 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id WAA12414 for ; Wed, 16 Jun 1999 22:09:21 -0700 (PDT) Received: from [24.93.53.161] ([24.93.53.161]) by Mail.austin.rr.com with Microsoft SMTPSVC(5.5.1875.185.18); Thu, 17 Jun 1999 00:06:29 -0500 X-Sender: asynth@mail.io.com Message-Id: In-Reply-To: <199906170212.WAA10493@renoir.op.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Jun 1999 00:12:18 -0600 To: Paul Barton-Davis , music-dsp@shoko.calarts.edu From: James McCartney Subject: Re: Csound and other synthesis systems Cc: csound@maths.ex.ac.uk Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu At 8:20 PM -0600 6/16/99, Paul Barton-Davis wrote: >There is no justification for a DSP program to contain concepts such >as a Dictionary or a SortedList; on the other hand, there is no >justification for a sophisticated algorithmic language to be >constrained by the execution model embodied in a DSP program. Just because you cannot justify it to yourself does not mean that there are no justifiable uses. And the algorithmic language is in no way constrained or vice versa. In fact you have much greater flexibility because your algorithmic composition can get down and mess with the building structure of your DSP algorithms. I do this a lot. It is very powerful. Maybe you need to use your imagination a bit more. >But to return to my point: I don't want a dynamically typed, real >time garbage collected, fully object oriented language to write DSP >code in. The SC language does not implement the UGens, it creates the patching structure. Again I think that because you have never used it or been exposed to what you can do, you do not realize the power there. >From what I could read of SuperCollider, this separation doesn't >exist. This is not necessarily so bad if one can use the language >simply. Sure you can. There is an OrcScore ugen that can be used just like you would write a csound numeric score. >I also don't understand anything of what you said about note on >velocity controlling the complexity of a patch. I think you must be >describing something rather different than what I think of as a patch, >which is essentially the specification of what things are connected >together. The best I can imagine is that velocity is used to >essentially choose one of a particular set of possible >interconnections before any actual sound is generated, In supercollider your orchestra is not just some dead code. Unit generators are real objects and can be manipulated and combined in real time. In SuperCollider you are not defining a static structure beforehand but are building a graph of ugens in real time for each event. For example I can write in supercollider the following: n.do({ z = AllpassN.ar(z, 0.05, 0.05.rand, 2); }); This creates a daisy chain of n allpass delay lines. Now I can map n to some patch argument such as velocity and that will cause the number of allpass delays in series to be equal to n. In other words the structure of the patch can change per event. Now you could implement this as a lookup table of patches in a static language, but then if I went and added more structural mappings in SC, you'd begin to have a combinatorial explosion to match it in a static language. >particular reason for this to be part of the language, and in fact, >its a lot less flexible than doing this switching visually, via a >velocity zone map that acts as a switch to route note information to a >particular patch. There is so much more you can do than this. For example in SC if I write a function to be a simple sine wave instrument: f = { arg freq = 440.0, amp = 1.0; SinOsc.ar(freq, 0, EnvGen.ar(env, amp)); }; Now I can call it as follows giving it float arguments : Synth.play({ f.value(800.0, 0.2); }); Or I can call it with other sub patches as arguments: Synth.play({ f.value( XLine.kr(300, 2000, 4), SinOsc.kr(5, 0, 0.2, 0.4) ) }); Thus I am parameterizing a predefined patch function with other patches to create a new one. This can be done from within a score. So that you can write glissandi and such into your score and you don't have to worry that your patch was originally built to be able to do a glissando, you just plug in any control function per event. Such things like evolving new programmatically constructed patches via some performer directed process is possible in SC. And I have not mentioned other things like doing list processing on arrays of channels, multichannel expansion, spawning subpatches, etc. None of this is as flexible in a static environment. btw: In SC all scheduled event start times are sample accurate and ksmps is settable per event. --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07562; 17 Jun 99 6:19 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uUae-0002Cl-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 06:19:52 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (GAA15587); Thu, 17 Jun 1999 06:15:10 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 06:14:59 +0100 Received: from sm2.texas.rr.com [24.93.35.55] by hermes via ESMTP (GAA13462); Thu, 17 Jun 1999 06:14:58 +0100 (BST) Received: from [24.93.53.161] ([24.93.53.161]) by Mail.austin.rr.com with Microsoft SMTPSVC(5.5.1875.185.18); Thu, 17 Jun 1999 00:12:20 -0500 X-Sender: asynth@mail.io.com Message-Id: In-Reply-To: <008401beb84e$b4be8fe0$79d496c0@Realizer.ngt.sungard.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Jun 1999 00:18:09 -0600 To: music-dsp@shoko.calarts.edu From: James McCartney Subject: Re: Csound and other synthesis systems Cc: CSOUND Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk At 5:19 PM -0600 6/16/99, Michael Gogins wrote: >Thanks for your response to this discussion. I remember your exhibition of >SuperCollider at the last ICMC and was quite impressed. > >I would love if it SuperCollider: > >(a) ran on Windows >(b) had plugin unit generators (or words in its language - is that even >possible?) >(c) had an external API >(d) ran on Windows b & c are planned and are more an issue of documentation than implementation. a & d are more religious things I guess. I am of the opinion recently that OS's are too important to be proprietary. I am on the Mac nowadays mostly due to historical inertia and the fact that I like the PowerPC chip. At one time the Mac had provable UI advantages, but those are becoming harder to justify and as an OS it is really impossible to justify. Perhaps MacOSX will make the Mac more able to be compatible with the rest of the posix world, but I've heard that most posix things are not a simple recompile on MacOSX. BeOS has some nice real time media facilities available so I like that too though it definitely has its own problems. I find no reason to like Windows other than market size and that is not the reason I'm doing this. Win has all the same problems as MacOS does and the UI is not as consistent. If I'm on an Intel machine I'd much rather be running Linux or BeOS. --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07571; 17 Jun 99 6:23 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uUeR-0007uG-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 06:23:48 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id WAA12534 for music-dsp-outgoing; Wed, 16 Jun 1999 22:15:11 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id WAA12529 for ; Wed, 16 Jun 1999 22:15:09 -0700 (PDT) Received: from [24.93.53.161] ([24.93.53.161]) by Mail.austin.rr.com with Microsoft SMTPSVC(5.5.1875.185.18); Thu, 17 Jun 1999 00:12:20 -0500 X-Sender: asynth@mail.io.com Message-Id: In-Reply-To: <008401beb84e$b4be8fe0$79d496c0@Realizer.ngt.sungard.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Jun 1999 00:18:09 -0600 To: music-dsp@shoko.calarts.edu From: James McCartney Subject: Re: Csound and other synthesis systems Cc: CSOUND Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu At 5:19 PM -0600 6/16/99, Michael Gogins wrote: >Thanks for your response to this discussion. I remember your exhibition of >SuperCollider at the last ICMC and was quite impressed. > >I would love if it SuperCollider: > >(a) ran on Windows >(b) had plugin unit generators (or words in its language - is that even >possible?) >(c) had an external API >(d) ran on Windows b & c are planned and are more an issue of documentation than implementation. a & d are more religious things I guess. I am of the opinion recently that OS's are too important to be proprietary. I am on the Mac nowadays mostly due to historical inertia and the fact that I like the PowerPC chip. At one time the Mac had provable UI advantages, but those are becoming harder to justify and as an OS it is really impossible to justify. Perhaps MacOSX will make the Mac more able to be compatible with the rest of the posix world, but I've heard that most posix things are not a simple recompile on MacOSX. BeOS has some nice real time media facilities available so I like that too though it definitely has its own problems. I find no reason to like Windows other than market size and that is not the reason I'm doing this. Win has all the same problems as MacOS does and the UI is not as consistent. If I'm on an Intel machine I'd much rather be running Linux or BeOS. --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07611; 17 Jun 99 6:54 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uV7m-0002DC-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 06:54:06 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (GAA02035); Thu, 17 Jun 1999 06:46:51 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 06:46:42 +0100 Received: from ccrma.Stanford.EDU [36.49.0.84] by hermes via ESMTP (GAA10267); Thu, 17 Jun 1999 06:46:41 +0100 (BST) Received: from ccrma.stanford.edu ([207.97.74.43]) by ccrma.stanford.edu (8.8.8/8.8.8) with ESMTP id WAA28437; Wed, 16 Jun 1999 22:46:46 -0700 (PDT) Message-ID: <37688ADE.45029E23@ccrma.stanford.edu> Date: Thu, 17 Jun 1999 01:42:54 -0400 From: Tobias Kunze X-Mailer: Mozilla 4.51C-SGI [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: James McCartney CC: music-dsp@shoko.calarts.edu, csound@maths.ex.ac.uk Subject: Re: Csound and other synthesis systems References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Hi James- I've always wondered how on earth you came up with the name "SuperCollider" from. Could you explain? Graned, it's trivia, but there has been so much serious discussion going on recently, I think we could use a bit of enchantment :) And while I'm at the mic: damn straight, most people are so glued to their unit-generator-music-5 worldview, they simply can't imagine the possibilities of a runtime variable signal flow. Cheers, -Tobias Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07621; 17 Jun 99 6:59 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uVDL-0007uj-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 06:59:51 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (GAA01369); Thu, 17 Jun 1999 06:52:38 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 06:52:27 +0100 Received: from smtp0.mindspring.com [207.69.200.30] by hermes via ESMTP (GAA12920); Thu, 17 Jun 1999 06:52:26 +0100 (BST) Received: from Realizer (user-2ive2fr.dialup.mindspring.com [165.247.9.251]) by smtp0.mindspring.com (8.8.5/8.8.5) with SMTP id BAA09786; Thu, 17 Jun 1999 01:52:33 -0400 (EDT) Message-ID: <007301beb885$a1ced340$79d496c0@Realizer.ngt.sungard.com> From: Michael Gogins To: music-dsp@shoko.calarts.edu, James McCartney MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos Cc: CSOUND Subject: Re: Csound and other synthesis systems Date: Thu, 17 Jun 1999 01:52:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Whatever your religious objections to Windows, if you create a cross-platform virtual machine that works with Java, then you get it to run on Linux (or BeOS if BeOS have a Java virtual machine) and, without hurting anyone on those other platforms, it also runs on Windows where there are lots and lots of musicians who could use SuperCollider. I started on Unix and moved to Windows not for religious reasons, but because it made my musical life happen at home and more cheaply than any other way without really losing any vital functionality. I personally believe that some virtual-machine system is bound to run almost all software in the end. I think Java, its descendent, or something like it will end up running on everything from supercomputers to watches. I think this will happen because software is more expensive than hardware and general-purpose software is cheaper than special-purpose software. Note how the Ptolemy DSP project at UCB for the Navy has moved from C++ to Java in the past two years. Also Roldan Pozo and other big guns in numerics and supercomputing are pushing Java Grande because, I suspect, they anticipate distributed Java apps that can do more than any single app on any single machine. -----Original Message----- From: James McCartney To: music-dsp@shoko.calarts.edu Cc: CSOUND Date: Thursday, June 17, 1999 1:17 AM Subject: Re: Csound and other synthesis systems >At 5:19 PM -0600 6/16/99, Michael Gogins wrote: >>Thanks for your response to this discussion. I remember your exhibition of >>SuperCollider at the last ICMC and was quite impressed. >> >>I would love if it SuperCollider: >> >>(a) ran on Windows >>(b) had plugin unit generators (or words in its language - is that even >>possible?) >>(c) had an external API >>(d) ran on Windows > >b & c are planned and are more an issue of documentation than >implementation. > >a & d are more religious things I guess. I am of the opinion recently >that OS's are too important to be proprietary. I am on the Mac nowadays >mostly due to historical inertia and the fact that I like the PowerPC >chip. At one time the Mac had provable UI advantages, but those are >becoming harder to justify and as an OS it is really impossible to justify. >Perhaps MacOSX will make the Mac more able to be compatible with the rest >of the posix world, but I've heard that most posix things are not a >simple recompile on MacOSX. > >BeOS has some nice real time media facilities available so I like that >too though it definitely has its own problems. > >I find no reason to like Windows other than market size and >that is not the reason I'm doing this. Win has all the same problems >as MacOS does and the UI is not as consistent. >If I'm on an Intel machine I'd much rather be running Linux or BeOS. > > > --- james mccartney james@audiosynth.com http://www.audiosynth.com >If you have a PowerMac check out SuperCollider2, a real time synth program: > > > > > Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07641; 17 Jun 99 7:04 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uVHw-0002DK-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 07:04:36 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id WAA13105 for music-dsp-outgoing; Wed, 16 Jun 1999 22:52:37 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from smtp0.mindspring.com (smtp0.mindspring.com [207.69.200.30]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id WAA13101 for ; Wed, 16 Jun 1999 22:52:35 -0700 (PDT) Received: from Realizer (user-2ive2fr.dialup.mindspring.com [165.247.9.251]) by smtp0.mindspring.com (8.8.5/8.8.5) with SMTP id BAA09786; Thu, 17 Jun 1999 01:52:33 -0400 (EDT) Message-ID: <007301beb885$a1ced340$79d496c0@Realizer.ngt.sungard.com> From: Michael Gogins To: music-dsp@shoko.calarts.edu, James McCartney MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos Cc: CSOUND Subject: Re: Csound and other synthesis systems Date: Thu, 17 Jun 1999 01:52:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu Whatever your religious objections to Windows, if you create a cross-platform virtual machine that works with Java, then you get it to run on Linux (or BeOS if BeOS have a Java virtual machine) and, without hurting anyone on those other platforms, it also runs on Windows where there are lots and lots of musicians who could use SuperCollider. I started on Unix and moved to Windows not for religious reasons, but because it made my musical life happen at home and more cheaply than any other way without really losing any vital functionality. I personally believe that some virtual-machine system is bound to run almost all software in the end. I think Java, its descendent, or something like it will end up running on everything from supercomputers to watches. I think this will happen because software is more expensive than hardware and general-purpose software is cheaper than special-purpose software. Note how the Ptolemy DSP project at UCB for the Navy has moved from C++ to Java in the past two years. Also Roldan Pozo and other big guns in numerics and supercomputing are pushing Java Grande because, I suspect, they anticipate distributed Java apps that can do more than any single app on any single machine. -----Original Message----- From: James McCartney To: music-dsp@shoko.calarts.edu Cc: CSOUND Date: Thursday, June 17, 1999 1:17 AM Subject: Re: Csound and other synthesis systems >At 5:19 PM -0600 6/16/99, Michael Gogins wrote: >>Thanks for your response to this discussion. I remember your exhibition of >>SuperCollider at the last ICMC and was quite impressed. >> >>I would love if it SuperCollider: >> >>(a) ran on Windows >>(b) had plugin unit generators (or words in its language - is that even >>possible?) >>(c) had an external API >>(d) ran on Windows > >b & c are planned and are more an issue of documentation than >implementation. > >a & d are more religious things I guess. I am of the opinion recently >that OS's are too important to be proprietary. I am on the Mac nowadays >mostly due to historical inertia and the fact that I like the PowerPC >chip. At one time the Mac had provable UI advantages, but those are >becoming harder to justify and as an OS it is really impossible to justify. >Perhaps MacOSX will make the Mac more able to be compatible with the rest >of the posix world, but I've heard that most posix things are not a >simple recompile on MacOSX. > >BeOS has some nice real time media facilities available so I like that >too though it definitely has its own problems. > >I find no reason to like Windows other than market size and >that is not the reason I'm doing this. Win has all the same problems >as MacOS does and the UI is not as consistent. >If I'm on an Intel machine I'd much rather be running Linux or BeOS. > > > --- james mccartney james@audiosynth.com http://www.audiosynth.com >If you have a PowerMac check out SuperCollider2, a real time synth program: > > > > > dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07662; 17 Jun 99 7:09 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uVMt-0002DR-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 07:09:43 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (HAA08083); Thu, 17 Jun 1999 07:05:02 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 07:04:50 +0100 Received: from sm2.texas.rr.com [24.93.35.55] by hermes via ESMTP (HAA03946); Thu, 17 Jun 1999 07:04:49 +0100 (BST) Received: from [24.93.53.161] ([24.93.53.161]) by Mail.austin.rr.com with Microsoft SMTPSVC(5.5.1875.185.18); Thu, 17 Jun 1999 01:02:11 -0500 X-Sender: asynth@mail.io.com Message-Id: In-Reply-To: <007301beb885$a1ced340$79d496c0@Realizer.ngt.sungard.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Jun 1999 01:08:00 -0600 To: Michael Gogins , music-dsp@shoko.calarts.edu MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos From: James McCartney Subject: Re: Csound and other synthesis systems Cc: CSOUND Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk At 11:52 PM -0600 6/16/99, Michael Gogins wrote: >Whatever your religious objections to Windows, if you create a >cross-platform virtual machine that works with Java, then you get it to run >on Linux (or BeOS if BeOS have a Java virtual machine) and, without hurting >anyone on those other platforms, it also runs on Windows where there are >lots and lots of musicians who could use SuperCollider. Java's GC is not real time. Java is not a real time language. Java cannot run at interrupt level in a sound card's callback routine. --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07672; 17 Jun 99 7:14 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uVRO-0007ux-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 07:14:22 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id XAA13320 for music-dsp-outgoing; Wed, 16 Jun 1999 23:05:04 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id XAA13316 for ; Wed, 16 Jun 1999 23:05:03 -0700 (PDT) Received: from [24.93.53.161] ([24.93.53.161]) by Mail.austin.rr.com with Microsoft SMTPSVC(5.5.1875.185.18); Thu, 17 Jun 1999 01:02:11 -0500 X-Sender: asynth@mail.io.com Message-Id: In-Reply-To: <007301beb885$a1ced340$79d496c0@Realizer.ngt.sungard.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Jun 1999 01:08:00 -0600 To: Michael Gogins , music-dsp@shoko.calarts.edu MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos From: James McCartney Subject: Re: Csound and other synthesis systems Cc: CSOUND Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu At 11:52 PM -0600 6/16/99, Michael Gogins wrote: >Whatever your religious objections to Windows, if you create a >cross-platform virtual machine that works with Java, then you get it to run >on Linux (or BeOS if BeOS have a Java virtual machine) and, without hurting >anyone on those other platforms, it also runs on Windows where there are >lots and lots of musicians who could use SuperCollider. Java's GC is not real time. Java is not a real time language. Java cannot run at interrupt level in a sound card's callback routine. --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07691; 17 Jun 99 7:21 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uVXz-0007v5-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 07:21:11 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (HAA03628); Thu, 17 Jun 1999 07:13:26 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 07:13:15 +0100 Received: from sm2.texas.rr.com [24.93.35.55] by hermes via ESMTP (HAA04242); Thu, 17 Jun 1999 07:13:14 +0100 (BST) Received: from [24.93.53.161] ([24.93.53.161]) by Mail.austin.rr.com with Microsoft SMTPSVC(5.5.1875.185.18); Thu, 17 Jun 1999 01:09:38 -0500 X-Sender: asynth@mail.io.com Message-Id: In-Reply-To: <37688ADE.45029E23@ccrma.stanford.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Jun 1999 01:15:27 -0600 To: Tobias Kunze From: James McCartney Subject: Re: Csound and other synthesis systems Cc: music-dsp@shoko.calarts.edu, csound@maths.ex.ac.uk Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk At 11:42 PM -0600 6/16/99, Tobias Kunze wrote: >Hi James- > >I've always wondered how on earth you came up with the name >"SuperCollider" from. Could you explain? Graned, it's trivia, >but there has been so much serious discussion going on recently, >I think we could use a bit of enchantment :) > >And while I'm at the mic: damn straight, most people are so >glued to their unit-generator-music-5 worldview, they simply >can't imagine the possibilities of a runtime variable signal >flow. The SuperConducting SuperCollider was a Texas Big Science project that was feeding lots of the physicists working below me while I worked at the Astronomy Dept at Univ of Texas at Austin. Its funding got killed by Congress. Meanwhile I had these two pieces of code, one a synth language called Synth-O-Matic that I wrote in 1990, and a MAX object called Pyrite that was a real time GCed dynamic language, i.e. a "number cruncher" program and a (lisp) "atom smasher" program. I was going to "collide" these two programs together to see if a dynamic language could run a synth engine in real time. I was sure it was going to fail so I named it after the supercollider. I had not intended to keep that name but it stuck. Sometime during that period OSC had a contract to publish it. That fell through when they got bought by MacroMedia. Some folks hated the name so much that I decided I should call my next project something that no one would feel comfortable saying in public. So far the winner is "diarrhea popsicle". That will be the name of my next synth program, so hope that "SuperCollider" lasts a long time.. ;-} --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07697; 17 Jun 99 7:24 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uVaz-0002De-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 07:24:18 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id XAA13503 for music-dsp-outgoing; Wed, 16 Jun 1999 23:13:27 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id XAA13498 for ; Wed, 16 Jun 1999 23:13:26 -0700 (PDT) Received: from [24.93.53.161] ([24.93.53.161]) by Mail.austin.rr.com with Microsoft SMTPSVC(5.5.1875.185.18); Thu, 17 Jun 1999 01:09:38 -0500 X-Sender: asynth@mail.io.com Message-Id: In-Reply-To: <37688ADE.45029E23@ccrma.stanford.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Jun 1999 01:15:27 -0600 To: Tobias Kunze From: James McCartney Subject: Re: Csound and other synthesis systems Cc: music-dsp@shoko.calarts.edu, csound@maths.ex.ac.uk Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu At 11:42 PM -0600 6/16/99, Tobias Kunze wrote: >Hi James- > >I've always wondered how on earth you came up with the name >"SuperCollider" from. Could you explain? Graned, it's trivia, >but there has been so much serious discussion going on recently, >I think we could use a bit of enchantment :) > >And while I'm at the mic: damn straight, most people are so >glued to their unit-generator-music-5 worldview, they simply >can't imagine the possibilities of a runtime variable signal >flow. The SuperConducting SuperCollider was a Texas Big Science project that was feeding lots of the physicists working below me while I worked at the Astronomy Dept at Univ of Texas at Austin. Its funding got killed by Congress. Meanwhile I had these two pieces of code, one a synth language called Synth-O-Matic that I wrote in 1990, and a MAX object called Pyrite that was a real time GCed dynamic language, i.e. a "number cruncher" program and a (lisp) "atom smasher" program. I was going to "collide" these two programs together to see if a dynamic language could run a synth engine in real time. I was sure it was going to fail so I named it after the supercollider. I had not intended to keep that name but it stuck. Sometime during that period OSC had a contract to publish it. That fell through when they got bought by MacroMedia. Some folks hated the name so much that I decided I should call my next project something that no one would feel comfortable saying in public. So far the winner is "diarrhea popsicle". That will be the name of my next synth program, so hope that "SuperCollider" lasts a long time.. ;-} --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07782; 17 Jun 99 8:26 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uWZY-0007w9-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 08:26:52 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (IAA09220); Thu, 17 Jun 1999 08:22:02 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 08:21:50 +0100 Received: from [139.130.48.118] by hermes via ESMTP (IAA13122); Thu, 17 Jun 1999 08:21:46 +0100 (BST) Received: from firstpr.com.au (wira.firstpr.com.au [203.36.57.201]) by gair.firstpr.com.au (8.8.7/8.8.7) with ESMTP id RAA15138; Thu, 17 Jun 1999 17:28:45 +1000 Message-ID: <3768A155.7380B616@firstpr.com.au> Date: Thu, 17 Jun 1999 17:18:45 +1000 From: Robin Whittle Organization: First Principles & Real World Interfaces X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: csound@maths.ex.ac.uk Subject: PLUM list of music languages Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Tim Thompson's Progamming Languages Used for Music list is alive again: http://www.nosuch.com/plum/ It doesn't yet mention a promising youngster which is just finding its feet, Paul Barton-Davis' Quasimodo: http://www.op.net/~pbd/quasimodo/ http://gair.firstpr.com.au/qm/ - Robin =============================================================== Robin Whittle rw@firstpr.com.au http://www.firstpr.com.au Heidelberg Heights, Melbourne, Australia First Principles Research and expression: Consulting and technical writing. Music. Internet music marketing. Telecommunications. Consumer advocacy in telecommunications, especially privacy. M-F relationships. Kinetic sculpture. Real World Electronics and software for music including: Interfaces Devil Fish mods for the TB-303, Akai sampler memory and Csound synthesis software. =============================================================== Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07824; 17 Jun 99 8:39 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uWlo-0002Ex-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 08:39:32 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (IAA07901); Thu, 17 Jun 1999 08:33:45 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 08:33:30 +0100 Received: from dns2.seanet.com [199.181.164.2] by hermes via ESMTP (IAA08845); Thu, 17 Jun 1999 08:33:29 +0100 (BST) Received: from seanet.com (cy32.dialup.seanet.com [207.12.136.32]) by mx.seanet.com (8.9.3/Seanet-8.7.3) with ESMTP id AAA25856; Thu, 17 Jun 1999 00:32:44 -0700 (PDT) Message-ID: <3768A2AC.73A34BA@seanet.com> Date: Thu, 17 Jun 1999 00:24:28 -0700 From: Sean Costello X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: music-dsp@shoko.calarts.edu CC: pete moss , CSOUND Subject: Re: cmusic Was: Csound and other synthesis systems References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C895.4B7F857A@firstpr.com.au> <3767E49F.E1679F6B@bigfoot.com> <37685D9D.1FE8EE04@firstpr.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Robin Whittle wrote: > Please correct me if I am wrong, but it is my understanding that both > Music V and cmusic call the code for a unit-generator, and that code > produces just one sample of audio output. Csound's distinguishing > characteristic is that it has a variable "ksmps" which tells the unit > generator how many samples to calculate. I believe that having a separate control rate was a technique developed by Barry Vercoe for Music 11, and carried into Csound. I guess that any music language that distinguishes between control signals and audio signals (is SuperCollider this way?) can be viewed as being derivative of Barry Vercoe's innovations. I think that the Nord Modular also makes this distinction. BTW, Buchla modular synthesizers also had separate paths for audio and control signals, but for a different reason - the Buchla synths used optoisolators within their VCAs and VCFs, which had too slow of a response time to be modulated at audio rates. I would love to have a provision in Csound, where a separate kr=sr loop could be set up within an orchestra, for those techniques that require feedback to work. Or can this be done with the zak ugens? Sean Costello Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07830; 17 Jun 99 8:39 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uWly-0007wT-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 08:39:42 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (IAA02946); Thu, 17 Jun 1999 08:33:27 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 08:33:15 +0100 Received: from dns2.seanet.com [199.181.164.2] by hermes via ESMTP (IAA01765); Thu, 17 Jun 1999 08:33:14 +0100 (BST) Received: from seanet.com (cy32.dialup.seanet.com [207.12.136.32]) by mx.seanet.com (8.9.3/Seanet-8.7.3) with ESMTP id AAA25860; Thu, 17 Jun 1999 00:32:50 -0700 (PDT) Message-ID: <3768A617.B059C2FB@seanet.com> Date: Thu, 17 Jun 1999 00:39:03 -0700 From: Sean Costello X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: music-dsp@shoko.calarts.edu CC: pete moss , CSOUND Subject: Computer Music Books (was Re: cmusic) References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C895.4B7F857A@firstpr.com.au> <3767E49F.E1679F6B@bigfoot.com> <37685D9D.1FE8EE04@firstpr.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Robin Whittle wrote: > Does anyone have more information about cmusic? As someone else pointed out, F. Richard Moore's "Elements of Computer Music" is THE place to go for cmusic info, although I am not sure if cmusic is an active language at this point. It is also pretty good in describing the internals of computer music languages - it has good descriptions of the workings of table-lookup oscillators, comb filters, Karplus-Strong, and other cool things, as well as extensive C code and descriptions of phase vocoding and LPC. However, it skimps on some basic items; for example, even though it gets into some of the theory of digital filtering, it doesn't give any useful C code examples for basic building blocks such as reson, or any of the commonly used digital filters (on the other hand, I did figure out how to code allpass filters from this book). Going off on a little tangent here, what computer music books have been most useful to people on this list? As a way of distracting myself from the fact that my car was stolen last night, here is a list of books that have helped me: - Computer Music, Charles Dodge and Thomas A. Jerse, both 1st and 2nd editions. The 2nd edition was the textbook for my computer music classes at the University of Washington, and is excellent in that role - the sequence followed in introducing concepts is very logical and easy to follow for someone new to computer music. The 1st edition, from 1985, leaves out the descriptions of more modern techniques such as phase vocoding, physical modeling, and granular synthesis, but makes up for it with the inclusion of FORTRAN code for almost all of the "classic" unit generators (based on Music 4BF). The code in Computer Music is much easier to follow than the Csound source code - if you want to know how one of the older Csound ugens works, having this book around helps a great deal. - The Technology of Computer Music, by Max V. Mathews et al. A 1969 textbook, that is still amazingly useful today. No code per se, but excellent in-depth descriptions of the internals of unit generators that serves as a nice compliment to the code examples in the 1st edition of Dodge & Jerse. - Musical Applications of Microprocessors, by Hal Chamberlin. An excellent book that has helped me bridge the gap between analog synthesis and computer music. Code examples, schematics, in-depth descriptions that don't require engineering-level math - this book has got it all. Not as useful for understanding Music N-languages as the previous two books, but very useful for a broad perspective of the field. There have been lots of other books that have been useful to me (Foundations of Computer Music, Representations of Musical Signals, various issues of Electronotes) but the above books have been the most helpful in the past few months, at least with regards to writing Csound unit generators. Unfortunately, they are all out of print, but copies turn up on a regular basis - Powell's Technical Bookstore in Portland, Oregon is a good place to look for this type of stuff. Sean Costello P.S. Robin, when is the DevilFish unit generator coming out? :) I'd love to have a digital simulation of an overdriven diode ladder filter available in Csound, with the output being used to FM the cutoff... Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07840; 17 Jun 99 8:42 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uWop-0007wX-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 08:42:39 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id AAA14617 for music-dsp-outgoing; Thu, 17 Jun 1999 00:32:47 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from mx.seanet.com (dns2.seanet.com [199.181.164.2]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id AAA14613 for ; Thu, 17 Jun 1999 00:32:45 -0700 (PDT) Received: from seanet.com (cy32.dialup.seanet.com [207.12.136.32]) by mx.seanet.com (8.9.3/Seanet-8.7.3) with ESMTP id AAA25856; Thu, 17 Jun 1999 00:32:44 -0700 (PDT) Message-ID: <3768A2AC.73A34BA@seanet.com> Date: Thu, 17 Jun 1999 00:24:28 -0700 From: Sean Costello X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: music-dsp@shoko.calarts.edu CC: pete moss , CSOUND Subject: Re: cmusic Was: Csound and other synthesis systems References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C895.4B7F857A@firstpr.com.au> <3767E49F.E1679F6B@bigfoot.com> <37685D9D.1FE8EE04@firstpr.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu Robin Whittle wrote: > Please correct me if I am wrong, but it is my understanding that both > Music V and cmusic call the code for a unit-generator, and that code > produces just one sample of audio output. Csound's distinguishing > characteristic is that it has a variable "ksmps" which tells the unit > generator how many samples to calculate. I believe that having a separate control rate was a technique developed by Barry Vercoe for Music 11, and carried into Csound. I guess that any music language that distinguishes between control signals and audio signals (is SuperCollider this way?) can be viewed as being derivative of Barry Vercoe's innovations. I think that the Nord Modular also makes this distinction. BTW, Buchla modular synthesizers also had separate paths for audio and control signals, but for a different reason - the Buchla synths used optoisolators within their VCAs and VCFs, which had too slow of a response time to be modulated at audio rates. I would love to have a provision in Csound, where a separate kr=sr loop could be set up within an orchestra, for those techniques that require feedback to work. Or can this be done with the zak ugens? Sean Costello dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07848; 17 Jun 99 8:44 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uWqK-0007wZ-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 08:44:13 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id AAA14634 for music-dsp-outgoing; Thu, 17 Jun 1999 00:32:53 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from mx.seanet.com (dns2.seanet.com [199.181.164.2]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id AAA14625 for ; Thu, 17 Jun 1999 00:32:52 -0700 (PDT) Received: from seanet.com (cy32.dialup.seanet.com [207.12.136.32]) by mx.seanet.com (8.9.3/Seanet-8.7.3) with ESMTP id AAA25860; Thu, 17 Jun 1999 00:32:50 -0700 (PDT) Message-ID: <3768A617.B059C2FB@seanet.com> Date: Thu, 17 Jun 1999 00:39:03 -0700 From: Sean Costello X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: music-dsp@shoko.calarts.edu CC: pete moss , CSOUND Subject: Computer Music Books (was Re: cmusic) References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C895.4B7F857A@firstpr.com.au> <3767E49F.E1679F6B@bigfoot.com> <37685D9D.1FE8EE04@firstpr.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu Robin Whittle wrote: > Does anyone have more information about cmusic? As someone else pointed out, F. Richard Moore's "Elements of Computer Music" is THE place to go for cmusic info, although I am not sure if cmusic is an active language at this point. It is also pretty good in describing the internals of computer music languages - it has good descriptions of the workings of table-lookup oscillators, comb filters, Karplus-Strong, and other cool things, as well as extensive C code and descriptions of phase vocoding and LPC. However, it skimps on some basic items; for example, even though it gets into some of the theory of digital filtering, it doesn't give any useful C code examples for basic building blocks such as reson, or any of the commonly used digital filters (on the other hand, I did figure out how to code allpass filters from this book). Going off on a little tangent here, what computer music books have been most useful to people on this list? As a way of distracting myself from the fact that my car was stolen last night, here is a list of books that have helped me: - Computer Music, Charles Dodge and Thomas A. Jerse, both 1st and 2nd editions. The 2nd edition was the textbook for my computer music classes at the University of Washington, and is excellent in that role - the sequence followed in introducing concepts is very logical and easy to follow for someone new to computer music. The 1st edition, from 1985, leaves out the descriptions of more modern techniques such as phase vocoding, physical modeling, and granular synthesis, but makes up for it with the inclusion of FORTRAN code for almost all of the "classic" unit generators (based on Music 4BF). The code in Computer Music is much easier to follow than the Csound source code - if you want to know how one of the older Csound ugens works, having this book around helps a great deal. - The Technology of Computer Music, by Max V. Mathews et al. A 1969 textbook, that is still amazingly useful today. No code per se, but excellent in-depth descriptions of the internals of unit generators that serves as a nice compliment to the code examples in the 1st edition of Dodge & Jerse. - Musical Applications of Microprocessors, by Hal Chamberlin. An excellent book that has helped me bridge the gap between analog synthesis and computer music. Code examples, schematics, in-depth descriptions that don't require engineering-level math - this book has got it all. Not as useful for understanding Music N-languages as the previous two books, but very useful for a broad perspective of the field. There have been lots of other books that have been useful to me (Foundations of Computer Music, Representations of Musical Signals, various issues of Electronotes) but the above books have been the most helpful in the past few months, at least with regards to writing Csound unit generators. Unfortunately, they are all out of print, but copies turn up on a regular basis - Powell's Technical Bookstore in Portland, Oregon is a good place to look for this type of stuff. Sean Costello P.S. Robin, when is the DevilFish unit generator coming out? :) I'd love to have a digital simulation of an overdriven diode ladder filter available in Csound, with the output being used to FM the cutoff... dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07865; 17 Jun 99 8:56 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uX25-0002FD-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 08:56:21 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (IAA04681); Thu, 17 Jun 1999 08:50:32 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 08:50:18 +0100 Received: from first1.lnk.telstra.net [139.130.48.118] by hermes via ESMTP (IAA14372); Thu, 17 Jun 1999 08:50:16 +0100 (BST) Received: from firstpr.com.au (wira.firstpr.com.au [203.36.57.201]) by gair.firstpr.com.au (8.8.7/8.8.7) with ESMTP id RAA15203; Thu, 17 Jun 1999 17:57:22 +1000 Message-ID: <3768A80A.10734E16@firstpr.com.au> Date: Thu, 17 Jun 1999 17:47:22 +1000 From: Robin Whittle Organization: First Principles & Real World Interfaces X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Sean Costello CC: music-dsp@shoko.calarts.edu, pete moss , CSOUND Subject: Re: cmusic Was: Csound and other synthesis systems References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C895.4B7F857A@firstpr.com.au> <3767E49F.E1679F6B@bigfoot.com> <37685D9D.1FE8EE04@firstpr.com.au> <3768A2AC.73A34BA@seanet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Sean Costello wrote, in part: > I would love to have a provision in Csound, where a separate kr=sr > loop could be set up within an orchestra, for those techniques that > require feedback to work. Or can this be done with the zak > ugens? If you are keen, you can use some table read and write ugens I wrote to read ksmps audio samples into a function table, then do whatever processing you like on them with k-rate code, and then write them out to an audio variable of ksmps a-rate samples again. This gets you past the limitations of a-rate ugens, and enables you to do arbitrarily complex processing on a sample-by-sample basis - as if ksmps was 1. This would be ideal for chaotic generators, filters and probably quite a few other things. Intermediate storage from one set of a-rate samples to the next could be achieved with local k-rate variables. Of course it is slow, but it is probably faster to code a small but crucial part of a piece like this and run the rest at ksmps >= 5 or so, than run the entire piece at ksmps = 1. The ugens are: tablera and tablewa This URL at an old copy of the Csound manual at my web site gives examples: http://www.firstpr.com.au/csound/manual/Generate/tablera.html - Robin Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07887; 17 Jun 99 9:03 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uX94-0002FW-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 09:03:34 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id AAA15010 for music-dsp-outgoing; Thu, 17 Jun 1999 00:50:02 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from gair.firstpr.com.au (first1.lnk.telstra.net [139.130.48.118]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id AAA15004 for ; Thu, 17 Jun 1999 00:49:59 -0700 (PDT) Received: from firstpr.com.au (wira.firstpr.com.au [203.36.57.201]) by gair.firstpr.com.au (8.8.7/8.8.7) with ESMTP id RAA15203; Thu, 17 Jun 1999 17:57:22 +1000 Message-ID: <3768A80A.10734E16@firstpr.com.au> Date: Thu, 17 Jun 1999 17:47:22 +1000 From: Robin Whittle Organization: First Principles & Real World Interfaces X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Sean Costello CC: music-dsp@shoko.calarts.edu, pete moss , CSOUND Subject: Re: cmusic Was: Csound and other synthesis systems References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C895.4B7F857A@firstpr.com.au> <3767E49F.E1679F6B@bigfoot.com> <37685D9D.1FE8EE04@firstpr.com.au> <3768A2AC.73A34BA@seanet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu Sean Costello wrote, in part: > I would love to have a provision in Csound, where a separate kr=sr > loop could be set up within an orchestra, for those techniques that > require feedback to work. Or can this be done with the zak > ugens? If you are keen, you can use some table read and write ugens I wrote to read ksmps audio samples into a function table, then do whatever processing you like on them with k-rate code, and then write them out to an audio variable of ksmps a-rate samples again. This gets you past the limitations of a-rate ugens, and enables you to do arbitrarily complex processing on a sample-by-sample basis - as if ksmps was 1. This would be ideal for chaotic generators, filters and probably quite a few other things. Intermediate storage from one set of a-rate samples to the next could be achieved with local k-rate variables. Of course it is slow, but it is probably faster to code a small but crucial part of a piece like this and run the rest at ksmps >= 5 or so, than run the entire piece at ksmps = 1. The ugens are: tablera and tablewa This URL at an old copy of the Csound manual at my web site gives examples: http://www.firstpr.com.au/csound/manual/Generate/tablera.html - Robin dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07893; 17 Jun 99 9:03 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uX9N-0002FY-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 09:03:53 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (IAA10862); Thu, 17 Jun 1999 08:57:59 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 08:57:46 +0100 Received: from sm1.texas.rr.com [24.93.35.54] by hermes via ESMTP (IAA10360); Thu, 17 Jun 1999 08:57:45 +0100 (BST) Received: from [24.93.53.161] ([24.93.53.161]) by mail.austin.rr.com with Microsoft SMTPSVC(5.5.1875.185.18); Thu, 17 Jun 1999 02:56:55 -0500 X-Sender: asynth@mail.io.com Message-Id: In-Reply-To: <3768A2AC.73A34BA@seanet.com> References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C895.4B7F857A@firstpr.com.au> <3767E49F.E1679F6B@bigfoot.com> <37685D9D.1FE8EE04@firstpr.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Jun 1999 03:00:31 -0600 To: music-dsp@shoko.calarts.edu From: James McCartney Subject: Re: cmusic Was: Csound and other synthesis systems Cc: CSOUND Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk At 1:24 AM -0600 6/17/99, Sean Costello wrote: >11, and carried into Csound. I guess that any music language that distinguishes between control >signals and audio signals (is SuperCollider this way?) yes. However SC allows a separate block size per event. Control rate signals are always linearly interpolated when consumed by another ugen so there are never any zipper artifacts. This adds a bit of overhead, but since it is done in registers in the ugens loop, it is a small overhead and is much preferred to the two alternatives: 1) not using control rate but using audio rate. This causes a lot of overhead because reading from a buffer of samples is much slower than linearly ramping a value in a register. 2) having zipper noise artifacts. >can be viewed as being derivative of Barry >Vercoe's innovations. Well I stole good ideas from Roger Dannenberg too. When I read that Nyquist was sample accurate I considered that a raising of the bar and decided to implement that in SC as well. It is pretty important when scheduling grains, for example. --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07921; 17 Jun 99 9:10 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uXG4-0007xA-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 09:10:48 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id AAA15474 for music-dsp-outgoing; Thu, 17 Jun 1999 00:57:49 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id AAA15470 for ; Thu, 17 Jun 1999 00:57:47 -0700 (PDT) Received: from [24.93.53.161] ([24.93.53.161]) by mail.austin.rr.com with Microsoft SMTPSVC(5.5.1875.185.18); Thu, 17 Jun 1999 02:56:55 -0500 X-Sender: asynth@mail.io.com Message-Id: In-Reply-To: <3768A2AC.73A34BA@seanet.com> References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C895.4B7F857A@firstpr.com.au> <3767E49F.E1679F6B@bigfoot.com> <37685D9D.1FE8EE04@firstpr.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Jun 1999 03:00:31 -0600 To: music-dsp@shoko.calarts.edu From: James McCartney Subject: Re: cmusic Was: Csound and other synthesis systems Cc: CSOUND Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu At 1:24 AM -0600 6/17/99, Sean Costello wrote: >11, and carried into Csound. I guess that any music language that distinguishes between control >signals and audio signals (is SuperCollider this way?) yes. However SC allows a separate block size per event. Control rate signals are always linearly interpolated when consumed by another ugen so there are never any zipper artifacts. This adds a bit of overhead, but since it is done in registers in the ugens loop, it is a small overhead and is much preferred to the two alternatives: 1) not using control rate but using audio rate. This causes a lot of overhead because reading from a buffer of samples is much slower than linearly ramping a value in a register. 2) having zipper noise artifacts. >can be viewed as being derivative of Barry >Vercoe's innovations. Well I stole good ideas from Roger Dannenberg too. When I read that Nyquist was sample accurate I considered that a raising of the bar and decided to implement that in SC as well. It is pretty important when scheduling grains, for example. --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07931; 17 Jun 99 9:14 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uXJY-0002G7-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 09:14:24 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (JAA08423); Thu, 17 Jun 1999 09:08:27 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 09:08:17 +0100 Received: from first1.lnk.telstra.net [139.130.48.118] by hermes via ESMTP (JAA04958); Thu, 17 Jun 1999 09:08:13 +0100 (BST) Received: from firstpr.com.au (wira.firstpr.com.au [203.36.57.201]) by gair.firstpr.com.au (8.8.7/8.8.7) with ESMTP id SAA15277; Thu, 17 Jun 1999 18:15:48 +1000 Message-ID: <3768AC5C.D4EF2606@firstpr.com.au> Date: Thu, 17 Jun 1999 18:05:48 +1000 From: Robin Whittle Organization: First Principles & Real World Interfaces X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: music-dsp@shoko.calarts.edu, CSOUND CC: Sean Costello Subject: Re: Computer Music Books (was Re: cmusic) References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C895.4B7F857A@firstpr.com.au> <3767E49F.E1679F6B@bigfoot.com> <37685D9D.1FE8EE04@firstpr.com.au> <3768A617.B059C2FB@seanet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk To add to Sean Costello's list of books, there is an impressive book on filter design which I have bought but not read yet: Digital Filter Designer's Handbook With C++ Algorithms 2nd Edition C. Britton Rorabaugh McGraw Hill 1997 ISBN 0-07-053806-9 It comes with a floppy disc of source code. Amazon.com has it for USD$69.50. It is a magnificent-looking book, but it assumes more knowledge of calculus, z-transforms, real and imaginary numbers and the like than I have at present. It is clear that there is no alternative to knowing this stuff if you want to do DSP in the frequency domain. Sean also wrote: > P.S. Robin, when is the DevilFish unit generator coming out? :) > I'd love to have a digital simulation of an overdriven diode ladder > filter available in Csound, with the output being used to > FM the cutoff... Life is too short either to: 1 - Write a piece of software which behaves like the Devil Fish (my modifications to the Roland TB-303). or 2 - Wait for that software to produce audio. It is way too complex and idiosyncratic. Its not just a question of complexity, non-linearities and simulating diodes etc. There are the matters of needing instant feedback for Filter FM based on the output of the filter (ksmps = 1!) and of running at much higher sample rates then 44.1 kHz in order to simulate all the chaotic gyrations which actually occur - of which we hear the lower frequency components. Take a look at the waveform which forms the backdrop of the Devil Fish sound samples page: http://www.firstpr.com.au/rwi/dfish/sounds/ http://www.firstpr.com.au/rwi/dfish/sounds/df-waveform-q90.jpg If I get a piece of software kicking and gyrating even vaguely like the Devil Fish, I will be very proud of myself! The Devil Fish is complex for a piece of electronics, but it is simple compared to the reverberation of a room or a guitar sound box. Don't even think about cymbals, gongs, sitars, sarods or tympanies! - Robin =============================================================== Robin Whittle rw@firstpr.com.au http://www.firstpr.com.au Heidelberg Heights, Melbourne, Australia First Principles Research and expression: Consulting and technical writing. Music. Internet music marketing. Telecommunications. Consumer advocacy in telecommunications, especially privacy. M-F relationships. Kinetic sculpture. Real World Electronics and software for music including: Interfaces Devil Fish mods for the TB-303, Akai sampler memory and Csound synthesis software. =============================================================== Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa07946; 17 Jun 99 9:22 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uXR0-0007y3-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 09:22:07 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id BAA15694 for music-dsp-outgoing; Thu, 17 Jun 1999 01:08:13 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from gair.firstpr.com.au (first1.lnk.telstra.net [139.130.48.118]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id BAA15690 for ; Thu, 17 Jun 1999 01:08:09 -0700 (PDT) Received: from firstpr.com.au (wira.firstpr.com.au [203.36.57.201]) by gair.firstpr.com.au (8.8.7/8.8.7) with ESMTP id SAA15277; Thu, 17 Jun 1999 18:15:48 +1000 Message-ID: <3768AC5C.D4EF2606@firstpr.com.au> Date: Thu, 17 Jun 1999 18:05:48 +1000 From: Robin Whittle Organization: First Principles & Real World Interfaces X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: music-dsp@shoko.calarts.edu, CSOUND CC: Sean Costello Subject: Re: Computer Music Books (was Re: cmusic) References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C895.4B7F857A@firstpr.com.au> <3767E49F.E1679F6B@bigfoot.com> <37685D9D.1FE8EE04@firstpr.com.au> <3768A617.B059C2FB@seanet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu To add to Sean Costello's list of books, there is an impressive book on filter design which I have bought but not read yet: Digital Filter Designer's Handbook With C++ Algorithms 2nd Edition C. Britton Rorabaugh McGraw Hill 1997 ISBN 0-07-053806-9 It comes with a floppy disc of source code. Amazon.com has it for USD$69.50. It is a magnificent-looking book, but it assumes more knowledge of calculus, z-transforms, real and imaginary numbers and the like than I have at present. It is clear that there is no alternative to knowing this stuff if you want to do DSP in the frequency domain. Sean also wrote: > P.S. Robin, when is the DevilFish unit generator coming out? :) > I'd love to have a digital simulation of an overdriven diode ladder > filter available in Csound, with the output being used to > FM the cutoff... Life is too short either to: 1 - Write a piece of software which behaves like the Devil Fish (my modifications to the Roland TB-303). or 2 - Wait for that software to produce audio. It is way too complex and idiosyncratic. Its not just a question of complexity, non-linearities and simulating diodes etc. There are the matters of needing instant feedback for Filter FM based on the output of the filter (ksmps = 1!) and of running at much higher sample rates then 44.1 kHz in order to simulate all the chaotic gyrations which actually occur - of which we hear the lower frequency components. Take a look at the waveform which forms the backdrop of the Devil Fish sound samples page: http://www.firstpr.com.au/rwi/dfish/sounds/ http://www.firstpr.com.au/rwi/dfish/sounds/df-waveform-q90.jpg If I get a piece of software kicking and gyrating even vaguely like the Devil Fish, I will be very proud of myself! The Devil Fish is complex for a piece of electronics, but it is simple compared to the reverberation of a room or a guitar sound box. Don't even think about cymbals, gongs, sitars, sarods or tympanies! - Robin =============================================================== Robin Whittle rw@firstpr.com.au http://www.firstpr.com.au Heidelberg Heights, Melbourne, Australia First Principles Research and expression: Consulting and technical writing. Music. Internet music marketing. Telecommunications. Consumer advocacy in telecommunications, especially privacy. M-F relationships. Kinetic sculpture. Real World Electronics and software for music including: Interfaces Devil Fish mods for the TB-303, Akai sampler memory and Csound synthesis software. =============================================================== dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa08092; 17 Jun 99 10:29 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uYTi-0002JS-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 10:28:58 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (KAA13950); Thu, 17 Jun 1999 10:22:48 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 10:22:30 +0100 Received: from jaguars-int.cableinet.net [193.38.113.9] by hermes via SMTP (KAA00263); Thu, 17 Jun 1999 10:22:30 +0100 (BST) Received: (qmail 13282 invoked from network); 17 Jun 1999 09:18:29 -0000 Received: from unknown (HELO cableinet.co.uk) (194.117.146.169) by jaguars with SMTP; 17 Jun 1999 09:18:29 -0000 Message-ID: <3768BF96.E4D38AC7@cableinet.co.uk> Date: Thu, 17 Jun 1999 10:27:50 +0100 From: Richard Dobson Organization: Composers Desktop Project X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Robin Whittle CC: pete moss , music-dsp@shoko.calarts.edu, CSOUND Subject: Re: cmusic Was: Csound and other synthesis systems References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C895.4B7F857A@firstpr.com.au> <3767E49F.E1679F6B@bigfoot.com> <37685D9D.1FE8EE04@firstpr.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk A weblink for cmusic and pcmusic is: http://crca-www.ucsd.edu/cmusic/cmusic.html I suppose one significant difference between cmusic and Csound, which might explain the releative lack of 'modern' opcodes in the former, is that while cmusic has largely remained the property and product of F.R. Moore, Csound has reaped the benefit of a large, skilful, enthusiastic and mostly unrestrained net-wide user and development group. This is partly thanks to the prodigious work of John Fitch just about keeping everyone and everything co-ordinated, but partly also due to the fact that it is still essentially standard C, such that anybody can 'have a go' (including myself), on just about any platform (including the Atari ST) without have to climb a fierce learning curve of object-orientation, STL, multi-threading, yacc, lex, et al. Richard Dobson Robin Whittle wrote: > > Pete Moss pointed out that what I described as my long term plan (a > framework for C++ to support realtime synthesis) is akin to cmusic. > > I think this is true. This post looks at what I understand about > cmusic and how it only produces a single sample of audio per ugen > call, compared to Csound which produces ksmps samples, and so can be > very much faster. > > Looking at Dave Philip's marvellous link-farm on software synthesis: > > http://www.bright.net/~dlphilp/linux_soundapps.html > > leads me to Tim Thompson's venerable PLUM page on music languages, > which should be at: > > http://www.nosuch.com/plum > > but this file is absent at present. (I emailed Tim.) > > Searching for "cmusic" is tricky, but I found something from 1994 at: > > ftp://ccrma-ftp.stanford.edu/pub/cmusic/ > [etc] -- Test your DAW with my Soundcard Attrition Page! http://wkweb5.cableinet.co.uk/rwd (LU: 19th May 1999) CDP: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm (LU: 6th May 1999) Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa08109; 17 Jun 99 10:39 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uYeC-0002Jl-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 10:39:48 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id CAA16652 for music-dsp-outgoing; Thu, 17 Jun 1999 02:22:42 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from jaguars.cableinet.net (jaguars-int.cableinet.net [193.38.113.9]) by shoko.calarts.edu (8.9.3/8.9.3) with SMTP id CAA16648 for ; Thu, 17 Jun 1999 02:22:40 -0700 (PDT) Received: (qmail 13282 invoked from network); 17 Jun 1999 09:18:29 -0000 Received: from unknown (HELO cableinet.co.uk) (194.117.146.169) by jaguars with SMTP; 17 Jun 1999 09:18:29 -0000 Message-ID: <3768BF96.E4D38AC7@cableinet.co.uk> Date: Thu, 17 Jun 1999 10:27:50 +0100 From: Richard Dobson Organization: Composers Desktop Project X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Robin Whittle CC: pete moss , music-dsp@shoko.calarts.edu, CSOUND Subject: Re: cmusic Was: Csound and other synthesis systems References: <004701beb7f3$941829a0$79d496c0@Realizer.ngt.sungard.com> <3767C895.4B7F857A@firstpr.com.au> <3767E49F.E1679F6B@bigfoot.com> <37685D9D.1FE8EE04@firstpr.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu A weblink for cmusic and pcmusic is: http://crca-www.ucsd.edu/cmusic/cmusic.html I suppose one significant difference between cmusic and Csound, which might explain the releative lack of 'modern' opcodes in the former, is that while cmusic has largely remained the property and product of F.R. Moore, Csound has reaped the benefit of a large, skilful, enthusiastic and mostly unrestrained net-wide user and development group. This is partly thanks to the prodigious work of John Fitch just about keeping everyone and everything co-ordinated, but partly also due to the fact that it is still essentially standard C, such that anybody can 'have a go' (including myself), on just about any platform (including the Atari ST) without have to climb a fierce learning curve of object-orientation, STL, multi-threading, yacc, lex, et al. Richard Dobson Robin Whittle wrote: > > Pete Moss pointed out that what I described as my long term plan (a > framework for C++ to support realtime synthesis) is akin to cmusic. > > I think this is true. This post looks at what I understand about > cmusic and how it only produces a single sample of audio per ugen > call, compared to Csound which produces ksmps samples, and so can be > very much faster. > > Looking at Dave Philip's marvellous link-farm on software synthesis: > > http://www.bright.net/~dlphilp/linux_soundapps.html > > leads me to Tim Thompson's venerable PLUM page on music languages, > which should be at: > > http://www.nosuch.com/plum > > but this file is absent at present. (I emailed Tim.) > > Searching for "cmusic" is tricky, but I found something from 1994 at: > > ftp://ccrma-ftp.stanford.edu/pub/cmusic/ > [etc] -- Test your DAW with my Soundcard Attrition Page! http://wkweb5.cableinet.co.uk/rwd (LU: 19th May 1999) CDP: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm (LU: 6th May 1999) dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa08441; 17 Jun 99 13:04 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uauG-0002TJ-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 13:04:32 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (MAA06809); Thu, 17 Jun 1999 12:57:59 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 12:57:45 +0100 Received: from mta03-acc.tin.it [212.216.176.34] by hermes via ESMTP (MAA16434); Thu, 17 Jun 1999 12:57:43 +0100 (BST) Received: from fabiobiz ([212.216.232.163]) by fep03-svc.tin.it (InterMail v4.0 201-221-105) with SMTP id <19990617115719.MMUL20919.fep03-svc@fabiobiz> for ; Thu, 17 Jun 1999 13:57:19 +0200 Message-Id: <4.1.19990617134303.00948210@box4.tin.it> X-Sender: fabzt@box4.tin.it (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 17 Jun 1999 13:44:05 +0200 To: csound@maths.ex.ac.uk From: Fabio Bizzetti Subject: please help Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Hi, Going 3 months away, and not wanting to get my mailbox flooded, I would like to unsubcribe temporarily from the CSound list. Can anybody remember me what was the procedure? Thanks, Fabio B. Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa08459; 17 Jun 99 13:05 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10uauz-00084j-00 for jpff@maths.bath.ac.uk; Thu, 17 Jun 1999 13:05:17 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (MAA03644); Thu, 17 Jun 1999 12:58:46 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 17 Jun 1999 12:58:35 +0100 Received: from exim@wallace.maths.bath.ac.uk [138.38.100.104] by hermes via ESMTP (MAA08209); Thu, 17 Jun 1999 12:58:34 +0100 (BST) Received: from [138.38.99.25] (helo=maths.Bath.AC.UK ident=mmdf) by wallace.maths.bath.ac.uk with smtp (Exim 2.12 #1) id 10uaob-0002Sp-00; Thu, 17 Jun 1999 12:58:41 +0100 Date: Thu, 17 Jun 99 12:58:41 BST From: jpff@maths.bath.ac.uk Subject: Re: Csound and other synthesis systems To: music-dsp@shoko.calarts.edu, csound@maths.ex.ac.uk Message-Id: Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Message written at 16 Jun 1999 22:54:42 +0100 OK, so someone has to display their ignorance. What is a VST plugin? What does it do for me? ==John ffitch

Date	1999-06-16 16:32
From	James McCartney
Subject	Re: Csound and other synthesis systems
	At 6:26 AM -0600 6/16/99, Michael Gogins wrote: >Other >programs of note that I don't talk about here are SuperCollider and >GrainWave. OK, but... >What is needed here is a reasonable compromise between the power and >amenability for experimentation of a bare-bones piece of academic UNIX >software, and a user-friendly GUI and user-extensible plugin architecture, >with realtime performance AND non-realtime soundfile rendering. This is the >wonderful musical instrument that is evolving before our very eyes (and >ears), and Csound already contains all the necessary guts for the thing. If expressive power is what you want then why go with Csound? Csound : assembly language :: SuperCollider : Smalltalk (OK this is crossposted to the Csound list so I can see those flames rolling in.. 8-0 ) Seriously, I would be interested in any serious proposals for collaboration on a port of SuperCollider to Linux. I think a SuperCollider + GTK on Linux would be very cool. SuperCollider was written from the beginning to be used in real time. All operations were conceived and written with that in mind. For example variable delay lines of any maximum length can be allocated and used immediately without needing to be zeroed out first. (SC can do non real time just fine too.) Right now SC is closed source, however I have been considering opening the source to the language virtual machine. Plugins of UGens and language primitives are both possible. SC was designed for easy plugging in of language primitives. The virtual machine should be easily portable, there is no Mac specific code in there. -- SuperCollider is a dynamically typed, real time garbage collected, fully object oriented language like Smalltalk with support for true closures, coroutines, positional or keyword arguments, variable length argument lists, default argument values, etc. It has a class library of 341 classes including a full set of Collection classes like Dictionary, Set, SortedList, etc. There are currently over 200 unit generators. -- --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: dupswapdrop: the music-dsp mailing list and website http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html

Date	1999-06-16 21:36
From	Mark T Vigorito
Subject	Re: Csound and other synthesis systems
	On Wed, 16 Jun 1999, Michael Gogins wrote: [...] > Csound can act as a VST plugin. > [...] > The VST part is easy. > I am very interested in this (I use Samplitude Studio). What else needs to be done? I was under the impression that your AXCsound was already a step in that direction... Cheers, Mark Vigorito mtv@u.arizona.edu