Re: Proposal for a new version of Csound

Date	1999-06-27 14:24
From	Michael Gogins
Subject	Re: Proposal for a new version of Csound
	I'm surprised by the emotional depth of this discussion about C versis C++, which is distracting the discussion away from the merits of my proposal to rewrite the kernel of Csound. I don't care whether it's C or C++ as long as it's fast and completely platform-neutral so that in reality it IS just recompilation for different processors. Can we get back to the point now? -----Original Message----- From: Michel Jullian To: csound@maths.ex.ac.uk Cc: music-dsp list Date: Sunday, June 27, 1999 5:43 AM Subject: Re: Proposal for a new version of Csound >Paul Barton-Davis wrote: >> >> >What do you think about this idea? Would you be open to using this >> >JavaCsound kernel in Quasimodo, or merging the two kernels into one (as a >> >shared library, >> >> If it means moving away from C++, I'm not in favor of it. If it means >> not using a formal grammar, I'm not in favor of it. > >Well, what do you think Michael ? Might be worth considering C++ :-) >-- >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 aa12216; 27 Jun 99 14:45 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10yFF9-0000q7-00 for jpff@maths.bath.ac.uk; Sun, 27 Jun 1999 14:45:11 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id GAA12110 for music-dsp-outgoing; Sun, 27 Jun 1999 06:22:45 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from smtp4.mindspring.com (smtp4.mindspring.com [207.69.200.64]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id GAA12106 for ; Sun, 27 Jun 1999 06:22:43 -0700 (PDT) Received: from Realizer (user-2ive09e.dialup.mindspring.com [165.247.1.46]) by smtp4.mindspring.com (8.8.5/8.8.5) with SMTP id JAA06897; Sun, 27 Jun 1999 09:22:37 -0400 (EDT) Message-ID: <000e01bec0a0$68034e20$79d496c0@Realizer.ngt.sungard.com> From: Michael Gogins To: music-dsp@shoko.calarts.edu, csound@maths.ex.ac.uk MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos Cc: music-dsp list Subject: Re: Proposal for a new version of Csound Date: Sun, 27 Jun 1999 09:24:36 -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 surprised by the emotional depth of this discussion about C versis C++, which is distracting the discussion away from the merits of my proposal to rewrite the kernel of Csound. I don't care whether it's C or C++ as long as it's fast and completely platform-neutral so that in reality it IS just recompilation for different processors. Can we get back to the point now? -----Original Message----- From: Michel Jullian To: csound@maths.ex.ac.uk Cc: music-dsp list Date: Sunday, June 27, 1999 5:43 AM Subject: Re: Proposal for a new version of Csound >Paul Barton-Davis wrote: >> >> >What do you think about this idea? Would you be open to using this >> >JavaCsound kernel in Quasimodo, or merging the two kernels into one (as a >> >shared library, >> >> If it means moving away from C++, I'm not in favor of it. If it means >> not using a formal grammar, I'm not in favor of it. > >Well, what do you think Michael ? Might be worth considering C++ :-) >-- >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 > 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 aa12315; 27 Jun 99 15:43 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10yG9M-0004ke-00 for jpff@maths.bath.ac.uk; Sun, 27 Jun 1999 15:43:16 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (PAA14662); Sun, 27 Jun 1999 15:38:34 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 27 Jun 1999 15:38:22 +0100 Received: from root@renoir.op.net [209.152.193.4] by hermes via ESMTP (PAA16998); Sun, 27 Jun 1999 15:38:21 +0100 (BST) Received: from someip.ppp.op.net (d-bm3-19.ppp.op.net [209.152.194.89]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id KAA07271; Sun, 27 Jun 1999 10:38:14 -0400 (EDT) Message-Id: <199906271438.KAA07271@renoir.op.net> To: csound@maths.ex.ac.uk, music-dsp@shoko.calarts.edu Subject: Re: Proposal for a new version of Csound In-reply-to: Your message of "Sun, 27 Jun 1999 09:24:36 EDT." <000e01bec0a0$68034e20$79d496c0@Realizer.ngt.sungard.com> Date: Sun, 27 Jun 1999 10:45:02 -0400 From: Paul Barton-Davis Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk In message <000e01bec0a0$68034e20$79d496c0@Realizer.ngt.sungard.com>you write: >I'm surprised by the emotional depth of this discussion about C versis C++, >which is distracting the discussion away from the merits of my proposal to >rewrite the kernel of Csound. > >I don't care whether it's C or C++ as long as it's fast and completely >platform-neutral so that in reality it IS just recompilation for different >processors. This is a little disingenuous Michael - we got started on this track because Michel asked "why not do it in C++?" and you offered two arguments against it: speed, and your desire to use only the ANSI C runtime library. >Can we get back to the point now? Sure, but what is the point ? Given that I have already reimplemented a "Csound kernel" to do most of what you describe (and other stuff too), I would think that a good starting point would be: is Quasimodo a reasonable place to begin, or do we (you) want to do it all over again ? If the former, then we can ask: what needs to change in Quasimodo so that it can be used the way that you describe ? I expect that the answer to the first question is "well, no not really". I say this because I have an important goal for Quasimodo that you don't have for your proposal, namely a multithreaded implementation. Multithreadedness is no small alteration to a program, and although its conceivable that we could figure out a way to make this transparent, I think it would come back to bite somewhere else. There are many assumptions throughout the design of Quasimodo that there are different threads handling different responsibilities. The reason that multithreadedness is a problem is because there is a standard for threads that I think makes sense to follow: POSIX P.1003. This standard is not implemented, as far as I know, for the Mac, and I am not sure of its status for Windows (one of the cygnus libraries might have it, I don't know). This makes it hard to see how Quasimodo could form the basis for the cross-platform system you want to build. It certainly violates your desire to stick with the ANSI C runtime library. Other important issues: if you commit to being truly cross-platform, and reliant only on core C functionality, you can't use compiler-compiler's like bison. You could provide the C output of bison as part of the distribution, but that isn't cross-platform. Not using compiler-compilers is one of the biggest problems with Csound as it currently exists, IMHO. I sound negative in the above, which is not intentional. I don't want to see someone else having to redo all the stuff that I've already done, and I think that Quasimodo would itself benefit from being required to meet some of the design goals that you laid out. But I do feel that there is a bit of a disjunction between Quasimodo's overall goals and yours, and that these might make it hard to use the same kernel. It would be great if this was not true, and I welcome suggestions and ideas on how to make it not true. --p Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa12333; 27 Jun 99 15:51 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10yGHQ-0004ki-00 for jpff@maths.bath.ac.uk; Sun, 27 Jun 1999 15:51:36 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id HAA13005 for music-dsp-outgoing; Sun, 27 Jun 1999 07:38:26 -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 HAA13000 for ; Sun, 27 Jun 1999 07:38:24 -0700 (PDT) Received: from someip.ppp.op.net (d-bm3-19.ppp.op.net [209.152.194.89]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id KAA07271; Sun, 27 Jun 1999 10:38:14 -0400 (EDT) Message-Id: <199906271438.KAA07271@renoir.op.net> To: csound@noether.ex.AC.UK, music-dsp@shoko.calarts.edu Subject: Re: Proposal for a new version of Csound In-reply-to: Your message of "Sun, 27 Jun 1999 09:24:36 EDT." <000e01bec0a0$68034e20$79d496c0@Realizer.ngt.sungard.com> Date: Sun, 27 Jun 1999 10:45:02 -0400 From: Paul Barton-Davis Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu In message <000e01bec0a0$68034e20$79d496c0@Realizer.ngt.sungard.com>you write: >I'm surprised by the emotional depth of this discussion about C versis C++, >which is distracting the discussion away from the merits of my proposal to >rewrite the kernel of Csound. > >I don't care whether it's C or C++ as long as it's fast and completely >platform-neutral so that in reality it IS just recompilation for different >processors. This is a little disingenuous Michael - we got started on this track because Michel asked "why not do it in C++?" and you offered two arguments against it: speed, and your desire to use only the ANSI C runtime library. >Can we get back to the point now? Sure, but what is the point ? Given that I have already reimplemented a "Csound kernel" to do most of what you describe (and other stuff too), I would think that a good starting point would be: is Quasimodo a reasonable place to begin, or do we (you) want to do it all over again ? If the former, then we can ask: what needs to change in Quasimodo so that it can be used the way that you describe ? I expect that the answer to the first question is "well, no not really". I say this because I have an important goal for Quasimodo that you don't have for your proposal, namely a multithreaded implementation. Multithreadedness is no small alteration to a program, and although its conceivable that we could figure out a way to make this transparent, I think it would come back to bite somewhere else. There are many assumptions throughout the design of Quasimodo that there are different threads handling different responsibilities. The reason that multithreadedness is a problem is because there is a standard for threads that I think makes sense to follow: POSIX P.1003. This standard is not implemented, as far as I know, for the Mac, and I am not sure of its status for Windows (one of the cygnus libraries might have it, I don't know). This makes it hard to see how Quasimodo could form the basis for the cross-platform system you want to build. It certainly violates your desire to stick with the ANSI C runtime library. Other important issues: if you commit to being truly cross-platform, and reliant only on core C functionality, you can't use compiler-compiler's like bison. You could provide the C output of bison as part of the distribution, but that isn't cross-platform. Not using compiler-compilers is one of the biggest problems with Csound as it currently exists, IMHO. I sound negative in the above, which is not intentional. I don't want to see someone else having to redo all the stuff that I've already done, and I think that Quasimodo would itself benefit from being required to meet some of the design goals that you laid out. But I do feel that there is a bit of a disjunction between Quasimodo's overall goals and yours, and that these might make it hard to use the same kernel. It would be great if this was not true, and I welcome suggestions and ideas on how to make it not true. --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 aa12364; 27 Jun 99 16: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 10yGSs-0000r2-00 for jpff@maths.bath.ac.uk; Sun, 27 Jun 1999 16:03:26 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (PAA03405); Sun, 27 Jun 1999 15:58:31 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 27 Jun 1999 15:58:20 +0100 Received: from smtp3.mindspring.com [207.69.200.33] by hermes via ESMTP (PAA03433); Sun, 27 Jun 1999 15:58:19 +0100 (BST) Received: from Realizer (user-2ive0at.dialup.mindspring.com [165.247.1.93]) by smtp3.mindspring.com (8.8.5/8.8.5) with SMTP id KAA30688; Sun, 27 Jun 1999 10:58:16 -0400 (EDT) Message-ID: <000a01bec0ad$c50580e0$79d496c0@Realizer.ngt.sungard.com> From: Michael Gogins To: csound@maths.ex.ac.uk, music-dsp@shoko.calarts.edu, Paul Barton-Davis MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos Subject: Re: Proposal for a new version of Csound Date: Sun, 27 Jun 1999 11:00:16 -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 This is more like it... a substantial discussion. What indeed would need to be done to fit Quasimodo into the JavaSound framework using some class with native methods such as I have described? I have looked over the Quasimodo source code, but since I'm not experienced with Gtk and other Linux type stuff, it's not clear where, if at all, the GUI can be severed from the kernel. I must say I admire what I saw. It's also not clear to me whether currently compiling Csound scores and orchestras would run with Quasimodo, without modification, which is a requirement of my proposal: complete backward compatibility with existing scores and orchestras. Sorry if I didn't make that clear. When I say "cross-platform", I mean: you take the sources, which possibly have some conditional compilation in one or a few clearly demarcated files, define one macro in the makefile, type "make", and then you can run JavaCsound with JavaSound on your processor. If it is necessary to create some abstract interfaces (say an abstract thread class with different implementations on different platforms) that is fine, as long as this part of the work is stable and easily maintained. It also is not critical if the compiler-compiler runs only on one (common) platform, but I would prefer otherwise. As far as threading is concerned, the JavaCsound class is designed to have methods that are pulled at by different threads - but those threads are created in the JavaCsound Java code or in the external program itself, not in the Csound C or C++ kernel. In other words, the Csound kernel implements the guts of several worker thread routines, but those threads are created and destroyed outside of the kernel, either in the JavaCsound class or in its clients. This design makes it easy to (a) code a thread-safe kernel and (b) synchronize all the inputs and outputs.The thread synchronization model is pretty much mandated by the JavaSound API design, but I think it looks like a pretty good model. -----Original Message----- From: Paul Barton-Davis To: csound@maths.ex.ac.uk ; music-dsp@shoko.calarts.edu Date: Sunday, June 27, 1999 10:39 AM Subject: Re: Proposal for a new version of Csound >Given that I have already >reimplemented a "Csound kernel" to do most of what you describe (and >other stuff too), I would think that a good starting point would be: >is Quasimodo a reasonable place to begin, or do we (you) want to do it >all over again ? If the former, then we can ask: what needs to change >in Quasimodo so that it can be used the way that you describe ? > >I expect that the answer to the first question is "well, no not >really". I say this because I have an important goal for Quasimodo >that you don't have for your proposal, namely a multithreaded >implementation. Multithreadedness is no small alteration to a program, >and although its conceivable that we could figure out a way to make >this transparent, I think it would come back to bite somewhere >else. There are many assumptions throughout the design of Quasimodo >that there are different threads handling different responsibilities. > >The reason that multithreadedness is a problem is because there >is a standard for threads that I think makes sense to follow: POSIX >P.1003. This standard is not implemented, as far as I know, for the >Mac, and I am not sure of its status for Windows (one of the cygnus >libraries might have it, I don't know). > >This makes it hard to see how Quasimodo could form the basis for >the cross-platform system you want to build. It certainly violates >your desire to stick with the ANSI C runtime library. > >Other important issues: if you commit to being truly cross-platform, >and reliant only on core C functionality, you can't use >compiler-compiler's like bison. You could provide the C output of >bison as part of the distribution, but that isn't cross-platform. Not >using compiler-compilers is one of the biggest problems with Csound as >it currently exists, IMHO. > >I sound negative in the above, which is not intentional. I don't want >to see someone else having to redo all the stuff that I've already >done, and I think that Quasimodo would itself benefit from being >required to meet some of the design goals that you laid out. But I do >feel that there is a bit of a disjunction between Quasimodo's overall >goals and yours, and that these might make it hard to use the same >kernel. It would be great if this was not true, and I welcome >suggestions and ideas on how to make it not true. Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa12385; 27 Jun 99 16:11 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10yGav-0004kw-00 for jpff@maths.bath.ac.uk; Sun, 27 Jun 1999 16:11:46 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id HAA13149 for music-dsp-outgoing; Sun, 27 Jun 1999 07:58:23 -0700 (PDT) X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f Received: from smtp3.mindspring.com (smtp3.mindspring.com [207.69.200.33]) by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id HAA13145 for ; Sun, 27 Jun 1999 07:58:21 -0700 (PDT) Received: from Realizer (user-2ive0at.dialup.mindspring.com [165.247.1.93]) by smtp3.mindspring.com (8.8.5/8.8.5) with SMTP id KAA30688; Sun, 27 Jun 1999 10:58:16 -0400 (EDT) Message-ID: <000a01bec0ad$c50580e0$79d496c0@Realizer.ngt.sungard.com> From: Michael Gogins To: csound@maths.ex.ac.uk, music-dsp@shoko.calarts.edu, Paul Barton-Davis MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos Subject: Re: Proposal for a new version of Csound Date: Sun, 27 Jun 1999 11:00:16 -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 This is more like it... a substantial discussion. What indeed would need to be done to fit Quasimodo into the JavaSound framework using some class with native methods such as I have described? I have looked over the Quasimodo source code, but since I'm not experienced with Gtk and other Linux type stuff, it's not clear where, if at all, the GUI can be severed from the kernel. I must say I admire what I saw. It's also not clear to me whether currently compiling Csound scores and orchestras would run with Quasimodo, without modification, which is a requirement of my proposal: complete backward compatibility with existing scores and orchestras. Sorry if I didn't make that clear. When I say "cross-platform", I mean: you take the sources, which possibly have some conditional compilation in one or a few clearly demarcated files, define one macro in the makefile, type "make", and then you can run JavaCsound with JavaSound on your processor. If it is necessary to create some abstract interfaces (say an abstract thread class with different implementations on different platforms) that is fine, as long as this part of the work is stable and easily maintained. It also is not critical if the compiler-compiler runs only on one (common) platform, but I would prefer otherwise. As far as threading is concerned, the JavaCsound class is designed to have methods that are pulled at by different threads - but those threads are created in the JavaCsound Java code or in the external program itself, not in the Csound C or C++ kernel. In other words, the Csound kernel implements the guts of several worker thread routines, but those threads are created and destroyed outside of the kernel, either in the JavaCsound class or in its clients. This design makes it easy to (a) code a thread-safe kernel and (b) synchronize all the inputs and outputs.The thread synchronization model is pretty much mandated by the JavaSound API design, but I think it looks like a pretty good model. -----Original Message----- From: Paul Barton-Davis To: csound@maths.ex.ac.uk ; music-dsp@shoko.calarts.edu Date: Sunday, June 27, 1999 10:39 AM Subject: Re: Proposal for a new version of Csound >Given that I have already >reimplemented a "Csound kernel" to do most of what you describe (and >other stuff too), I would think that a good starting point would be: >is Quasimodo a reasonable place to begin, or do we (you) want to do it >all over again ? If the former, then we can ask: what needs to change >in Quasimodo so that it can be used the way that you describe ? > >I expect that the answer to the first question is "well, no not >really". I say this because I have an important goal for Quasimodo >that you don't have for your proposal, namely a multithreaded >implementation. Multithreadedness is no small alteration to a program, >and although its conceivable that we could figure out a way to make >this transparent, I think it would come back to bite somewhere >else. There are many assumptions throughout the design of Quasimodo >that there are different threads handling different responsibilities. > >The reason that multithreadedness is a problem is because there >is a standard for threads that I think makes sense to follow: POSIX >P.1003. This standard is not implemented, as far as I know, for the >Mac, and I am not sure of its status for Windows (one of the cygnus >libraries might have it, I don't know). > >This makes it hard to see how Quasimodo could form the basis for >the cross-platform system you want to build. It certainly violates >your desire to stick with the ANSI C runtime library. > >Other important issues: if you commit to being truly cross-platform, >and reliant only on core C functionality, you can't use >compiler-compiler's like bison. You could provide the C output of >bison as part of the distribution, but that isn't cross-platform. Not >using compiler-compilers is one of the biggest problems with Csound as >it currently exists, IMHO. > >I sound negative in the above, which is not intentional. I don't want >to see someone else having to redo all the stuff that I've already >done, and I think that Quasimodo would itself benefit from being >required to meet some of the design goals that you laid out. But I do >feel that there is a bit of a disjunction between Quasimodo's overall >goals and yours, and that these might make it hard to use the same >kernel. It would be great if this was not true, and I welcome >suggestions and ideas on how to make it not true. 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 aa12444; 27 Jun 99 16:45 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10yH7Y-0000rM-00 for jpff@maths.bath.ac.uk; Sun, 27 Jun 1999 16:45:29 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (QAA10172); Sun, 27 Jun 1999 16:39:34 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 27 Jun 1999 16:39:22 +0100 Received: from mercury.acs.unt.edu [129.120.220.1] by hermes via ESMTP (QAA08749); Sun, 27 Jun 1999 16:39:21 +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 KAA23929; Sun, 27 Jun 1999 10:38:58 -0500 (CDT) Received: from jove.acs.unt.edu (pras7.local.premium.dialup.unt.edu [129.120.217.7]) by venus.acs.unt.edu (8.8.8/8.8.8) with ESMTP id KAA01901; Sun, 27 Jun 1999 10:38:56 -0500 (CDT) Message-ID: <37766129.F897784A@jove.acs.unt.edu> Date: Sun, 27 Jun 1999 10:36:41 -0700 From: "Michael A. Thompson" X-Mailer: Mozilla 4.51C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Paul Barton-Davis CC: csound@maths.ex.ac.uk, music-dsp@shoko.calarts.edu Subject: Re: Proposal for a new version of Csound References: <199906271438.KAA07271@renoir.op.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Paul Barton-Davis wrote: > > > The reason that multithreadedness is a problem is because there > is a standard for threads that I think makes sense to follow: POSIX > P.1003. This standard is not implemented, as far as I know, for the > Mac, and I am not sure of its status for Windows (one of the cygnus > libraries might have it, I don't know). > > NT is supposed to be POSIX compliant. The Mac has threads but its not POSIX (although, I remember reading that MetroWerks compiler has some kind of thread layer (easier than the MacOS threads) and some people have been porting POSIX apps to this layer). MacOS X (server) has POSIX libs although I dont think its certified POSIX compliant. Many POSIX unix apps port without trouble, or so I hear. BeOS also has a POSIX threads implementation, if Im not mistaken. If using c++ all you need is a csound abstract threads class then platform dependent thread implications (in separate files, no more of this ifndef stuff in the middle of the code), similar to how the handling of the platform hardware dependencies is done. Michael -- ---------------------------------- Michael A. Thompson [IRIX - NeXTStep - Linux - MacOS - Windows] Home: (940)382-2086 E-Mail: mat0001@jove.acs.unt.edu ---------------------------------- Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa12463; 27 Jun 99 16:53 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10yHFj-0000rR-00 for jpff@maths.bath.ac.uk; Sun, 27 Jun 1999 16:53:55 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (QAA03567); Sun, 27 Jun 1999 16:49:11 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 27 Jun 1999 16:48:59 +0100 Received: from postal.interaccess.com [207.208.133.2] by hermes via ESMTP (QAA04966); Sun, 27 Jun 1999 16:48:58 +0100 (BST) Received: from rhays (d95.focal8.interaccess.com [207.208.189.95]) by postal.interaccess.com (8.9.0/8.9.0) with SMTP id KAA05480; Sun, 27 Jun 1999 10:49:05 -0500 (CDT) From: "Bob Hays, Computer Geek" To: Michael Gogins , music-dsp@shoko.calarts.edu, csound@maths.ex.ac.uk MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos Cc: music-dsp list Subject: RE: Proposal for a new version of Csound Date: Sun, 27 Jun 1999 10:48:03 -0500 Message-ID: <000001bec0b4$70fb0d60$5fbdd0cf@rhays.interaccess.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-reply-to: <000e01bec0a0$68034e20$79d496c0@Realizer.ngt.sungard.com> Importance: Normal Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk > I'm surprised by the emotional depth of this discussion about C > versis C++, which is distracting the discussion away from the merits of my proposal to > rewrite the kernel of Csound. Computer languages, like operating systems, are religious issues, and hence it is quite understandable that people would wage religious war over their favorite. > I don't care whether it's C or C++ as long as it's fast and completely > platform-neutral so that in reality it IS just recompilation for different > processors. Hence, the real question: has anyone stated clearly the goals (requirements) for a rebuild of CSound? BTW, these goals should be testable (quantifiable) in addition to viewable/discussable (qualifiable). Will everyone accede to consensus or will the loudest voice/most willing to do the work triumph? Perhaps a Socratic in the group will start asking questions that can direct this discussion away from anger and towards useful progress. Have fun! - Bob -- "I did not ask for the anal probe" -- Passion Fish "Discipline is never an end in itself, only a means to an end." - King Crimson "Whoever flees history will be pursued by history." - Janusz Korczak Bob Hays \| Aviva Kramer ---------------------------------------+-------------------------------- rhays@interaccess.com (home) \| a1kramer@interaccess.com (home) Bob.Hays@abnamro.com (work) \| http://homepage.interaccess.com/~rhays \| Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa12545; 27 Jun 99 17:35 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10yHuF-0004lm-00 for jpff@maths.bath.ac.uk; Sun, 27 Jun 1999 17:35:47 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (RAA10935); Sun, 27 Jun 1999 17:31:01 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 27 Jun 1999 17:30:49 +0100 Received: from rothko.bestweb.net [209.94.100.160] by hermes via ESMTP (RAA11999); Sun, 27 Jun 1999 17:30:48 +0100 (BST) Received: from goodguy (dialin-144.poughkeepsie.bestweb.net [216.179.13.42]) by rothko.bestweb.net (8.9.1a/8.9.0) with SMTP id MAA04345; Sun, 27 Jun 1999 12:28:15 -0400 (EDT) Message-ID: <377631B8.791DC2D7@westnet.com> Date: Sun, 27 Jun 1999 14:14:16 +0000 From: Larry Troxler X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.31 i586) MIME-Version: 1.0 To: "Bob Hays, Computer Geek" CC: Michael Gogins , music-dsp@shoko.calarts.edu, csound@maths.ex.ac.uk Subject: [OT] Languages / Re: Proposal for a new version of Csound References: <000001bec0b4$70fb0d60$5fbdd0cf@rhays.interaccess.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Bob Hays, Computer Geek wrote: > > > I'm surprised by the emotional depth of this discussion about C > > versis C++, which is distracting the discussion away from the merits of my > proposal to > > rewrite the kernel of Csound. > > Computer languages, like operating systems, are religious issues, and hence > it is quite understandable that people would wage religious war over their > favorite. > Oh, here we go again . To most normal people, Computer languages are not religious issues! However, we do enjoy discussing pros and cons of various languages. In fact, to me, the reason I enjoy discussing the merits and drawbacks of specific languages is precisely to avoid turning the language into a religious (read "irrational") issue! An off-topic language discussion/debate doesn't equate to languages being a religious issue! Well, now, that I'm completely off topic, I'll just say bye :-) Larry Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa12560; 27 Jun 99 17: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 10yI0p-0004ls-00 for jpff@maths.bath.ac.uk; Sun, 27 Jun 1999 17:42:35 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id JAA14531 for music-dsp-outgoing; Sun, 27 Jun 1999 09:30:39 -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 JAA14527 for ; Sun, 27 Jun 1999 09:30:37 -0700 (PDT) Received: from goodguy (dialin-144.poughkeepsie.bestweb.net [216.179.13.42]) by rothko.bestweb.net (8.9.1a/8.9.0) with SMTP id MAA04345; Sun, 27 Jun 1999 12:28:15 -0400 (EDT) Message-ID: <377631B8.791DC2D7@westnet.com> Date: Sun, 27 Jun 1999 14:14:16 +0000 From: Larry Troxler X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.31 i586) MIME-Version: 1.0 To: "Bob Hays, Computer Geek" CC: Michael Gogins , music-dsp@shoko.calarts.edu, csound@maths.ex.ac.uk Subject: [OT] Languages / Re: Proposal for a new version of Csound References: <000001bec0b4$70fb0d60$5fbdd0cf@rhays.interaccess.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 Bob Hays, Computer Geek wrote: > > > I'm surprised by the emotional depth of this discussion about C > > versis C++, which is distracting the discussion away from the merits of my > proposal to > > rewrite the kernel of Csound. > > Computer languages, like operating systems, are religious issues, and hence > it is quite understandable that people would wage religious war over their > favorite. > Oh, here we go again . To most normal people, Computer languages are not religious issues! However, we do enjoy discussing pros and cons of various languages. In fact, to me, the reason I enjoy discussing the merits and drawbacks of specific languages is precisely to avoid turning the language into a religious (read "irrational") issue! An off-topic language discussion/debate doesn't equate to languages being a religious issue! Well, now, that I'm completely off topic, I'll just say bye :-) 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 aa12598; 27 Jun 99 17:58 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10yIGH-0004m2-00 for jpff@maths.bath.ac.uk; Sun, 27 Jun 1999 17:58:33 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (RAA11560); Sun, 27 Jun 1999 17:53:48 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 27 Jun 1999 17:53:36 +0100 Received: from root@renoir.op.net [209.152.193.4] by hermes via ESMTP (RAA01406); Sun, 27 Jun 1999 17:53:35 +0100 (BST) Received: from someip.ppp.op.net (d-bm3-0e.ppp.op.net [209.152.194.78]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id MAA13218; Sun, 27 Jun 1999 12:53:10 -0400 (EDT) Message-Id: <199906271653.MAA13218@renoir.op.net> To: Michael Gogins cc: csound@maths.ex.ac.uk, music-dsp@shoko.calarts.edu, qm-dev@exp.firstpr.com.au Subject: Re: Proposal for a new version of Csound In-reply-to: Your message of "Sun, 27 Jun 1999 11:00:16 EDT." <000a01bec0ad$c50580e0$79d496c0@Realizer.ngt.sungard.com> Date: Sun, 27 Jun 1999 12:59:52 -0400 From: Paul Barton-Davis Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk [ please note the qm-dev mailing list inclusion in the Cc: line ] >with Gtk and other Linux type stuff, it's not clear where, if at all, the >GUI can be severed from the kernel. Its as completely separate as I could make it. There are just two "connections": 1) in nmain.cc: UI ui; if ((ui = ui_factory (&argc, &argv)) == NULL) { error << "Cannot start Quasimodo UI" << endmsg; return 1; } UI is an abstract class that declares the following functions: virtual bool running () = 0; virtual void quit () = 0; virtual void request (RequestType) = 0; virtual ModuleSet &default_module_set () = 0; virtual void new_module_set () = 0; virtual int nstate_query (size_t nstates, const char prompt, ...) = 0; virtual void queue_error_message (Transmitter::Channel, const char ) = 0; virtual void run (Receiver ) = 0; The things that really make the UI work are in a concrete UI class that implements the virtual methods as well as its own (see src/qm/abstract_ui.h for the definition) 2) various methods of the UI class are used by way of the global "ui" pointer. So, to make this work in Java, you just write a new concrete UI class implements the required methods. You don't need to fix up ui_factory, because presumably, there would be a different "main()" if things ran inside Java (but src/qm/nmain.cc shows very clearly how straightforward it is to get things running). >It's also not clear to me whether currently compiling Csound scores and >orchestras would run with Quasimodo, without modification, which is a >requirement of my proposal: complete backward compatibility with existing >scores and orchestras. Sorry if I didn't make that clear. The orchestra parser is complete (I think), and handles all Csound instruments that I've been able to find that use the opcodes I've ported thus far. It actually handles a few things more sensibly than Csound as well, but attempts to be backwards compatible. For example, value converters that return an i-time value can be used as an i-time argument to another opcode, instead of first storing their return value in another variable. The only (intended) notable change is that Quasimodo has no concept of "header statements", so setting kr, ksmps, etc. at the top of a .orc has no effect whatsoever. It wouldn't be hard to change that, but if you plan to load several different instrument files the way that Quasimodo does, the idea that these variables should be set in any one of them is just plain wrong. The score file stuff is both more compatible (in that there are no changes whatsoever), and less complete. It currently does not handle ramping, npp, lpp and various other things. There is also no support for the macro system, which I consider to have been an extremely bad design decision by jpff. All this is with the proviso that both are still liable to changes, and the score file stuff doesn't currently work at all (I broke it, but will fix it today). But hey, its all just Bison and flex specifications, so changing it is nothing like trying to change the Csound parser. >When I say "cross-platform", I mean: you take the sources, which possibly >have some conditional compilation in one or a few clearly demarcated files, >define one macro in the makefile, type "make", and then you can run >JavaCsound with JavaSound on your processor. Sounds pretty reasonable. Thats the way Quasimodo tries to be "for itself". There are almost no #ifdef's anywhere in the main code for different platforms, and I intend it to remain that way. There is a system-dependent directory with system-specific code in it that handles all the differences between platforms, as well as a "Platform" object that can be used for various platform-specific small tasks. >If it is necessary to create some abstract interfaces (say an abstract >thread class with different implementations on different platforms) that is >fine, as long as this part of the work is stable and easily maintained. It >also is not critical if the compiler-compiler runs only on one (common) >platform, but I would prefer otherwise. Well, Bison is out there, and I'm sure there are various versions for Windows etc. Same with flex. >in the Csound C or C++ kernel. In other words, the Csound kernel implements >the guts of several worker thread routines, but those threads are created >and destroyed outside of the kernel, either in the JavaCsound class or in >its clients. Quasimodo is written so that the code to handle various tasks run in a different thread than the DSP simulator. This is the key to making it able to use multiple processors. Although the DSP thread could be thought of as the Csound kernel, thats not really true in Quasimodo: to implement all that Csound does, Quasimodo uses 3 threads: the DSP simulator, the real time event thread and some other thread (which might be running the UI) to handle input/loading and parsing of scores and orchestras. This doesn't look like a single function, and if you used it for Java, you'd presumably need a Java wrapper that invoked the 2 "other" threads, and took care of the tasks currently done by the UI thread. Its going to get more complex too: I am about to change things so that there is one DSP thread per ModuleSet, and then a final (quick) mixdown of the output of each DSP before it goes off to the soundcard. This allows me to use N>2 CPU systems efficiently, and even N=2 CPU's more efficiently, since when Quasimodo is running, its almost always just the DSP thread thats active, leaving a second processor sitting idle until "something else" happens. It also opens the door to sound output from Quasimodo coming from things other than Quasimodo DSP threads, if you see what I mean. I don't know how this is sounding so far. I do think that Quasimodo could really benefit from trying to be made into something close to what you described. --p Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa12626; 27 Jun 99 18: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 10yIPO-0004mL-00 for jpff@maths.bath.ac.uk; Sun, 27 Jun 1999 18:07:58 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id JAA14719 for music-dsp-outgoing; Sun, 27 Jun 1999 09:53:46 -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 JAA14715 for ; Sun, 27 Jun 1999 09:53:43 -0700 (PDT) Received: from someip.ppp.op.net (d-bm3-0e.ppp.op.net [209.152.194.78]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id MAA13218; Sun, 27 Jun 1999 12:53:10 -0400 (EDT) Message-Id: <199906271653.MAA13218@renoir.op.net> To: Michael Gogins cc: csound@maths.ex.ac.uk, music-dsp@shoko.calarts.edu, qm-dev@exp.firstpr.com.au Subject: Re: Proposal for a new version of Csound In-reply-to: Your message of "Sun, 27 Jun 1999 11:00:16 EDT." <000a01bec0ad$c50580e0$79d496c0@Realizer.ngt.sungard.com> Date: Sun, 27 Jun 1999 12:59:52 -0400 From: Paul Barton-Davis Sender: owner-music-dsp@shoko.calarts.edu Precedence: bulk Reply-To: music-dsp@shoko.calarts.edu [ please note the qm-dev mailing list inclusion in the Cc: line ] >with Gtk and other Linux type stuff, it's not clear where, if at all, the >GUI can be severed from the kernel. Its as completely separate as I could make it. There are just two "connections": 1) in nmain.cc: UI ui; if ((ui = ui_factory (&argc, &argv)) == NULL) { error << "Cannot start Quasimodo UI" << endmsg; return 1; } UI is an abstract class that declares the following functions: virtual bool running () = 0; virtual void quit () = 0; virtual void request (RequestType) = 0; virtual ModuleSet &default_module_set () = 0; virtual void new_module_set () = 0; virtual int nstate_query (size_t nstates, const char prompt, ...) = 0; virtual void queue_error_message (Transmitter::Channel, const char ) = 0; virtual void run (Receiver ) = 0; The things that really make the UI work are in a concrete UI class that implements the virtual methods as well as its own (see src/qm/abstract_ui.h for the definition) 2) various methods of the UI class are used by way of the global "ui" pointer. So, to make this work in Java, you just write a new concrete UI class implements the required methods. You don't need to fix up ui_factory, because presumably, there would be a different "main()" if things ran inside Java (but src/qm/nmain.cc shows very clearly how straightforward it is to get things running). >It's also not clear to me whether currently compiling Csound scores and >orchestras would run with Quasimodo, without modification, which is a >requirement of my proposal: complete backward compatibility with existing >scores and orchestras. Sorry if I didn't make that clear. The orchestra parser is complete (I think), and handles all Csound instruments that I've been able to find that use the opcodes I've ported thus far. It actually handles a few things more sensibly than Csound as well, but attempts to be backwards compatible. For example, value converters that return an i-time value can be used as an i-time argument to another opcode, instead of first storing their return value in another variable. The only (intended) notable change is that Quasimodo has no concept of "header statements", so setting kr, ksmps, etc. at the top of a .orc has no effect whatsoever. It wouldn't be hard to change that, but if you plan to load several different instrument files the way that Quasimodo does, the idea that these variables should be set in any one of them is just plain wrong. The score file stuff is both more compatible (in that there are no changes whatsoever), and less complete. It currently does not handle ramping, npp, lpp and various other things. There is also no support for the macro system, which I consider to have been an extremely bad design decision by jpff. All this is with the proviso that both are still liable to changes, and the score file stuff doesn't currently work at all (I broke it, but will fix it today). But hey, its all just Bison and flex specifications, so changing it is nothing like trying to change the Csound parser. >When I say "cross-platform", I mean: you take the sources, which possibly >have some conditional compilation in one or a few clearly demarcated files, >define one macro in the makefile, type "make", and then you can run >JavaCsound with JavaSound on your processor. Sounds pretty reasonable. Thats the way Quasimodo tries to be "for itself". There are almost no #ifdef's anywhere in the main code for different platforms, and I intend it to remain that way. There is a system-dependent directory with system-specific code in it that handles all the differences between platforms, as well as a "Platform" object that can be used for various platform-specific small tasks. >If it is necessary to create some abstract interfaces (say an abstract >thread class with different implementations on different platforms) that is >fine, as long as this part of the work is stable and easily maintained. It >also is not critical if the compiler-compiler runs only on one (common) >platform, but I would prefer otherwise. Well, Bison is out there, and I'm sure there are various versions for Windows etc. Same with flex. >in the Csound C or C++ kernel. In other words, the Csound kernel implements >the guts of several worker thread routines, but those threads are created >and destroyed outside of the kernel, either in the JavaCsound class or in >its clients. Quasimodo is written so that the code to handle various tasks run in a different thread than the DSP simulator. This is the key to making it able to use multiple processors. Although the DSP thread could be thought of as the Csound kernel, thats not really true in Quasimodo: to implement all that Csound does, Quasimodo uses 3 threads: the DSP simulator, the real time event thread and some other thread (which might be running the UI) to handle input/loading and parsing of scores and orchestras. This doesn't look like a single function, and if you used it for Java, you'd presumably need a Java wrapper that invoked the 2 "other" threads, and took care of the tasks currently done by the UI thread. Its going to get more complex too: I am about to change things so that there is one DSP thread per ModuleSet, and then a final (quick) mixdown of the output of each DSP before it goes off to the soundcard. This allows me to use N>2 CPU systems efficiently, and even N=2 CPU's more efficiently, since when Quasimodo is running, its almost always just the DSP thread thats active, leaving a second processor sitting idle until "something else" happens. It also opens the door to sound output from Quasimodo coming from things other than Quasimodo DSP threads, if you see what I mean. I don't know how this is sounding so far. I do think that Quasimodo could really benefit from trying to be made into something close to what you described. --p 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 aa12838; 27 Jun 99 19:51 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10yK1i-0004nb-00 for jpff@maths.bath.ac.uk; Sun, 27 Jun 1999 19:51:38 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (TAA11835); Sun, 27 Jun 1999 19:46:52 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 27 Jun 1999 19:46:41 +0100 Received: from ares.flash.net [209.30.0.41] by hermes via ESMTP (TAA11968); Sun, 27 Jun 1999 19:46:40 +0100 (BST) Received: from bigfoot.com (p235-53.atnt1.dialup.ftw1.flash.net [209.30.235.53]) by ares.flash.net (8.9.3/8.9.3) with ESMTP id NAA08167; Sun, 27 Jun 1999 13:46:34 -0500 (CDT) Message-ID: <3776722A.DC1C7A70@bigfoot.com> Date: Sun, 27 Jun 1999 13:49:14 -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: handheld-music@onelist.com, "csound@maths.ex.ac.uk" Subject: panic button References: <007901bec013$0b8798a0$0101a8c0@233mmx> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk i am thinking of adding a panic button to my palmOS app 'theremini', for that 'just in case' category. but i am uncertain as to which controllers to use. All Notes Off (123) or All Sound Off (120) ? i am not sure which is the proper one to use. any pointers? :P Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa13309; 28 Jun 99 0: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 10yOBg-0000vl-00 for jpff@maths.bath.ac.uk; Mon, 28 Jun 1999 00:18:12 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id QAA19921 for music-dsp-outgoing; Sun, 27 Jun 1999 16:04:06 -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 QAA19917 for ; Sun, 27 Jun 1999 16:04:03 -0700 (PDT) Received: from Realizer (user-2ive1k3.dialup.mindspring.com [165.247.6.131]) by smtp0.mindspring.com (8.8.5/8.8.5) with SMTP id TAA18913; Sun, 27 Jun 1999 19:03:44 -0400 (EDT) Message-ID: <001c01bec0f1$9712de00$79d496c0@Realizer.ngt.sungard.com> From: Michael Gogins To: Paul Barton-Davis Cc: csound@maths.ex.ac.uk, music-dsp@shoko.calarts.edu, qm-dev@exp.firstpr.com.au MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos Subject: Re: Proposal for a new version of Csound Date: Sun, 27 Jun 1999 19:05:38 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0017_01BEC0D0.0B31DBA0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0017_01BEC0D0.0B31DBA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Many thanks for your thoughtful and detailed explanations. It now looks more like the Quasimodi UI class might possibly be used to implement my Java kernel. Certainly it looks worth looking into. When I perused the sources I thought UI had something to do with GUI, but now it seems to be just the API for Csound. The threading issues seem amenable to me. Either Quaismodo can do all this thread stuff internally, or we could break its threads out to Java and let only Java spawn and destroy them. Perhaps you can define some classes that expose the thread routines but not the thread creation and destruction, your concrete UI class can do that, and a Java version of the concrete UI class can also do that. I welcome your interest in my proposal. I will try to make a rough cut of integrating Quasimodo into my design, modifying the design if it seems reasonable, and get it up on the list soon. In the meantime, I have modified my design quite a bit after going over and over the JavaSound APIs. I have appended the new design, which is still not quite complete. At the lowest level, the actual native interfaces are all in the following (and there are not many native methods after all). This becomes a straight C++ class in the kernel code. /** * An implementation of SynthesizerKernel * based on a platform-independent, * re-entrant, multiply instantiable, * double-precision rewrite of Csound with * plugin unit generators and function tables. / public class CsoundKernel extends SynthesizerKernel { public native long createKernel(); public native void destroyKernel(long kernel); public native boolean read(long kernel, String filename); public native boolean compile(long kernel, String xml); public native void sendCommand(long kernel, String command); public native int loadAllPlugins(long kernel, String directory); public native int loadPlugin(long kernel, String filename); public native boolean midiSendOpen(long kernel); public native boolean midiSendClose(long kernel); public native boolean isMidiSendOpen(long kernel); public native void midiSend(long kernel, byte[] midiSendBytes); public native boolean midiReceiveOpen(long kernel); public native boolean midiReceiveClose(long kernel); public native boolean isMidiReceiveOpen(long kernel); public native synchronized int midiReceive(long kernel, byte[] midiInBytes, Object monitor); public native int getAudioSampleFramesPerSecond(long kernel); public native void setAudioSampleFramesPerSecond(long kernel, int value); public native int getAudioSampleFramesPerControlSample(long kernel); public native void setAudioSampleFramesPerControlSample(long kernel, int value); public native int getAudioInputChannelCount(long kernel); public native void setAudioInputChannelCount(long kernel, int value); public native boolean audioInputOpen(long kernel); public native boolean audioInputClose(long kernel); public native boolean audioInputIsOpen(long kernel); public native synchronized int audioInputWrite(long kernel, float[] audioInputBuffer, int offset, int length, Object monitor); public native int getAudioOutputChannelCount(long kernel); public native void setAudioOutputChannelCount(long kernel, int value); public native boolean audioOutputOpen(long kernel); public native boolean audioOutputClose(long kernel); public native boolean audioOutputIsOpen(long kernel); public native int audioOutputRead(long kernel, float[] audioOutputBuffer, int offset, int length); } One thing I have done is made the synthesizer interface abstract, so that it could be implemented by any number of different synthesizer "kernels", such as a rewrite of Csound, Quasimodo, or SAOL. In other words, my proposal is for an adapter class that fits general-purpose, academic, powerful software synthesizers seamlessly into the JavaSound framework, which, the more I work with it, seems reasonably flexible and useful. Only time can tell if the implementation of the JavaSound APIs lives up to its good appearance. From: Paul Barton-Davis To: Michael Gogins Cc: csound@maths.ex.ac.uk ; music-dsp@shoko.calarts.edu ; qm-dev@exp.firstpr.com.au Date: Sunday, June 27, 1999 12:53 PM Subject: Re: Proposal for a new version of Csound >>with Gtk and other Linux type stuff, it's not clear where, if at all, the >>GUI can be severed from the kernel. > >Its as completely separate as I could make it. There are just two >"connections": > >1) in nmain.cc: > UI ui; > > if ((ui = ui_factory (&argc, &argv)) == NULL) { > error << "Cannot start Quasimodo UI" << endmsg; > return 1; > } > >UI is an abstract class that declares the following functions: > > virtual bool running () = 0; > virtual void quit () = 0; > virtual void request (RequestType) = 0; > virtual ModuleSet &default_module_set () = 0; > virtual void new_module_set () = 0; > virtual int nstate_query (size_t nstates, const char prompt, ...) = 0; > virtual void queue_error_message (Transmitter::Channel, const char ) = 0; > virtual void run (Receiver ) = 0; > >Quasimodo is written so that the code to handle various tasks run in a >different thread than the DSP simulator. This is the key to making it >able to use multiple processors. Although the DSP thread could be >thought of as the Csound kernel, thats not really true in Quasimodo: >to implement all that Csound does, Quasimodo uses 3 threads: the DSP >simulator, the real time event thread and some other thread (which >might be running the UI) to handle input/loading and parsing of scores >and orchestras. > >This doesn't look like a single function, and if you used it for Java, >you'd presumably need a Java wrapper that invoked the 2 "other" >threads, and took care of the tasks currently done by the UI thread. > >Its going to get more complex too: I am about to change things so that >there is one DSP thread per ModuleSet, and then a final (quick) >mixdown of the output of each DSP before it goes off to the >soundcard. This allows me to use N>2 CPU systems efficiently, and even >N=2 CPU's more* efficiently, since when Quasimodo is running, its >almost always just the DSP thread thats active, leaving a second >processor sitting idle until "something else" happens. It also opens >the door to sound output from Quasimodo coming from things other than >Quasimodo DSP threads, if you see what I mean. >I don't know how this is sounding so far. I do think that Quasimodo >could really benefit from trying to be made into something close to >what you described. > >--p ------=_NextPart_000_0017_01BEC0D0.0B31DBA0 Content-Type: application/octet-stream; name="SynthesizerKernel.class" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="SynthesizerKernel.class" yv66vgADAC0AUAcAMgcATAoAAgAEDABLACMBABNMU3ludGhlc2l6ZXJLZXJuZWw7AQAPTGluZU51 bWJlclRhYmxlAQANQ29uc3RhbnRWYWx1ZQEACG1pZGlTZW5kAQAOaXNNaWRpU2VuZE9wZW4BAA9h dWRpb091dHB1dE9wZW4BAAZvZmZzZXQBAApsb2FkUGx1Z2luAQASTGphdmEvbGFuZy9TdHJpbmc7 AQAGKEpbQilWAQACW0IBAApFeGNlcHRpb25zAQAEKEopWgEABHJlYWQBAAQoSilWAQAPYXVkaW9J bnB1dFdyaXRlAQAYKEpbQkxqYXZhL2xhbmcvT2JqZWN0OylJAQAKU291cmNlRmlsZQEAEWlzTWlk aVJlY2VpdmVPcGVuAQAdZ2V0QXVkaW9TYW1wbGVGcmFtZXNQZXJTZWNvbmQBAAQoSilJAQANbWlk aVNlbmRDbG9zZQEABmtlcm5lbAEADGNyZWF0ZUtlcm5lbAEAHXNldEF1ZGlvU2FtcGxlRnJhbWVz UGVyU2Vjb25kAQASTG9jYWxWYXJpYWJsZVRhYmxlAQAQbWlkaVJlY2VpdmVDbG9zZQEAEGF1ZGlv SW5wdXRJc09wZW4BABBhdWRpb0lucHV0QnVmZmVyAQADeG1sAQADKClWAQAFKEpJKVYBAAR0aGlz AQANZGVzdHJveUtlcm5lbAEABXZhbHVlAQADKClKAQALbWlkaUluQnl0ZXMBAAtzZW5kQ29tbWFu ZAEAD2F1ZGlvT3V0cHV0UmVhZAEAD2F1ZGlvSW5wdXRDbG9zZQEACWRpcmVjdG9yeQEAGihKW0JJ SUxqYXZhL2xhbmcvT2JqZWN0OylJAQANbWlkaVNlbmRCeXRlcwEAJHNldEF1ZGlvU2FtcGxlRnJh bWVzUGVyQ29udHJvbFNhbXBsZQEAJGdldEF1ZGlvU2FtcGxlRnJhbWVzUGVyQ29udHJvbFNhbXBs ZQEAEVN5bnRoZXNpemVyS2VybmVsAQAWKEpMamF2YS9sYW5nL1N0cmluZzspWgEAFihKTGphdmEv bGFuZy9TdHJpbmc7KVYBABYoSkxqYXZhL2xhbmcvU3RyaW5nOylJAQABSgEAAUkBABJMamF2YS9s YW5nL09iamVjdDsBAAxtaWRpU2VuZE9wZW4BABBhdWRpb091dHB1dENsb3NlAQAHY29tcGlsZQEA BENvZGUBAA5Mb2NhbFZhcmlhYmxlcwEAC21pZGlSZWNlaXZlAQAZc2V0QXVkaW9JbnB1dENoYW5u ZWxDb3VudAEAEWF1ZGlvT3V0cHV0QnVmZmVyAQAZZ2V0QXVkaW9JbnB1dENoYW5uZWxDb3VudAEA D21pZGlSZWNlaXZlT3BlbgEACChKW0JJSSlJAQAac2V0QXVkaW9PdXRwdXRDaGFubmVsQ291bnQB ABpnZXRBdWRpb091dHB1dENoYW5uZWxDb3VudAEAFlN5bnRoZXNpemVyS2VybmVsLmphdmEBAAhm aWxlbmFtZQEADmxvYWRBbGxQbHVnaW5zAQAHY29tbWFuZAEAEWF1ZGlvT3V0cHV0SXNPcGVuAQAG PGluaXQ+AQAQamF2YS9sYW5nL09iamVjdAEAB21vbml0b3IBAA5hdWRpb0lucHV0T3BlbgEABmxl bmd0aAQhAAEAAgAAAAAAIAQBABwAKAAABAEAJgATAAAEAQASADMAAAQBADsAMwAABAEAKgA0AAAE AQBIADUAAAQBAAwANQAABAEAOQARAAAEAQAaABEAAAQBAAkAEQAABAEACAAOAAAEAQBCABEAAAQB AB8AEQAABAEAFwARAAAEIQA+ABUAAAQBABgAGQAABAEAHQAkAAAEAQAxABkAAAQBADAAJAAABAEA QQAZAAAEAQA/ACQAAAQBAE4AEQAABAEALAARAAAEAQAgABEAAAQhABQALgAABAEARQAZAAAEAQBE ACQAAAQBAAoAEQAABAEAOgARAAAEAQBKABEAAAQBACsAQwAAAAEASwAjAAEAPAAAAC8AAQABAAAA BSq3AAOxAAAAAgAGAAAABgABAAAAFAAeAAAADAABAAAABQAlAAUAAAABABYAAAACAEY= ------=_NextPart_000_0017_01BEC0D0.0B31DBA0 Content-Type: application/octet-stream; name="JavaSynthesizer.java" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="JavaSynthesizer.java" import java.io.; import java.util.; import javax.media.sound.; import javax.media.sound.midi.; import javax.media.sound.midi.spi.; import javax.media.sound.sampled.; import javax.media.sound.sampled.spi.; /* * JavaSynthesizer is the low-level external Java interface for a new = version of Csound * (or, potentially, of any other native synthesizer kernel that = implements the ISynthesizer interface). * JavaSynthesizer has inner classes that implement parts of the = JavaSound API, * using native methods implemented by the kernel, which is written in = platform-independent ANSI C++. * This enables the kernel to be used from Java as a JavaSound MIDI = input or output device,=20 * as an audio synthesizer, or as an audio mixer (processor or effect). * * All existing inputs, outputs, and platform-specific code will be = removed * from the kernel, and replaced by C++ implementations of the = following Java native methods.=20 * The kernel will become a shared library. It might well implement = additional,=20 * non-Java interfaces (ActiveX control, VST 2 plugin, Buzz = generator/effect, and so on). * * The orchestra language, score language, command options, and = behavior of Csound=20 * will remain exactly as they now are, but new features will be added, = * including re-entrancy, multi-instancing, low-latency real-time input = and output, * and complete programmatic control. * * Plugin unit generators may be supported inside the kernel=20 * with a very simple, platform-independent C interface. * * JavaSynthesizer audio uses exclusively float samples.=20 * JavaSynthesizer will supply Codecs for converting * to 16 or 24 bit little-endian samples (AIFF format) and=20 * to 16 or 24 bit big-endian samples (WAV format). * * JavaSynthesizer is a low-level class. It will be supplemented by a = higher-level class,=20 * JavaSynthesizerManager, a Java Bean with a graphical user interface, = XML file editing,=20 * and configurable connections to the JavaSound system. * @author Copyright (C) 1999 by Michael Gogins. All rights reserved. * * gogins@nyc.pipeline.com * / public class JavaSynthesizer { /* * Interface to the native kernel object (Csound, in this case). / long kernel =3D 0; SynthesizerKernel synthesizer =3D null; /=20 The default constructor instantiates a kernel, * and registers with the JavaSound system. / public JavaSynthesizer() { synthesizer =3D new CsoundKernel(); kernel =3D synthesizer.createKernel(); MidiConfig.addDeviceFactory(midiIn); MidiConfig.addDeviceFactory(midiOut); } public void finalize() { MidiConfig.removeDeviceFactory(midiIn); MidiConfig.removeDeviceFactory(midiOut); synthesizer.destroyKernel(kernel); kernel =3D 0; } =20 /* * The kernel pulls MIDI messages from clients using midiIn, * which is a MidiOutDevice. / public class MidiIn implements MidiOutDevice, Receiver, = MidiDeviceFactory { ByteArrayOutputStream midiOutputStream =3D null; StreamGenerator streamGenerator =3D null; public MidiDevice getDevice() { return midiIn; } public MidiDevice.Info getDeviceInfo() { return info; } MidiIn() { midiOutputStream =3D new ByteArrayOutputStream(); streamGenerator =3D new StreamGenerator(midiOutputStream); } ArrayList listeners =3D new ArrayList(); class Info extends MidiDevice.Info { Info(String name, String vendor, String description, Class = deviceClass) { super(name, vendor, description, deviceClass); } } MidiDevice.Info info =3D new Info("MIDI in", "Vineyard = Productions", "kernel MIDI in", getClass()); void notifyListeners(MidiDevice.Event event) { for(int i =3D 0, n =3D listeners.size(); i < n; i++) { ((MidiDevice.Listener) listeners.get(i)).update(event); } } public void send(MidiEvent event) { streamGenerator.send(event); synthesizer.midiSend(kernel, = midiOutputStream.toByteArray()); midiOutputStream.reset(); } public Receiver getReceiver() { return midiIn; } public Receiver[] getReceivers() { Receiver[] receivers =3D new Receiver[1]; receivers[0] =3D midiIn; return receivers; } public void addListener(MidiDevice.Listener listener) { listeners.add(listener); } public void close() { synthesizer.midiSendClose(kernel); notifyListeners(new MidiDevice.Event(midiIn, = MidiDevice.Event.Type.CLOSE, -1)); } public MidiDevice.Info getInfo() { return info; =20 } public int getMode() { return OMNI_ON_POLY; } public int[] getModes() { int[] modes =3D new int[1]; modes[0] =3D OMNI_ON_POLY; return modes; } public boolean isOpen() { return synthesizer.isMidiSendOpen(kernel); } public void removeListener(MidiDevice.Listener listener) { listeners.remove(listener); } public int setMode(int mode) { return OMNI_ON_POLY; } } public MidiIn midiIn =3D new MidiIn(); /* * Clients pull MIDI messages from kernel by adding receivers to = midiOut, * which is a MidiInDevice. / public class MidiOut implements MidiInDevice, MidiDeviceFactory, = Runnable { StreamParser streamParser =3D new StreamParser(); byte[] midiReceiveBytes =3D new byte[0x100]; Thread thread =3D null; boolean transmitting =3D false; public void start() { if(!transmitting) { transmitting =3D true; thread =3D new Thread(midiOut); thread.start(); } } public void stop() { try { if(transmitting) { transmitting =3D false; thread.join(50); thread.destroy(); thread =3D null; } } catch(InterruptedException e) { e.printStackTrace(); } } /* * The kernel calls midiOut.notify() immediately after=20 * it has written some MIDI data into midiReceiveBytes. / public void run() { try { while(transmitting) { int bytesReceived =3D = synthesizer.midiReceive(kernel, midiReceiveBytes, midiOut); if(bytesReceived > 0) { streamParser.write(midiReceiveBytes); = =20 } wait(); } } catch(java.io.IOException e) { e.printStackTrace(); stop(); } catch(java.lang.InterruptedException e) { e.printStackTrace(); stop(); } } public MidiDevice getDevice() { return midiOut; } public MidiDevice.Info getDeviceInfo() { return info; } public void addReceiver(Receiver receiver) { streamParser.addReceiver(receiver); } public Receiver[] getReceivers() { return streamParser.getReceivers(); } public void removeReceiver(Receiver receiver) { streamParser.removeReceiver(receiver); } ArrayList listeners =3D new ArrayList(); class Info extends MidiDevice.Info { Info(String name, String vendor, String description, Class = deviceClass) { super(name, vendor, description, deviceClass); } } MidiDevice.Info info =3D new Info("MIDI out", "Vineyard = Productions", "kernel MIDI out", getClass()); void notifyListeners(MidiDevice.Event event) { for(int i =3D 0, n =3D listeners.size(); i < n; i++) { ((MidiDevice.Listener) listeners.get(i)).update(event); } } public void addListener(MidiDevice.Listener listener) { listeners.add(listener); } public void close() { synthesizer.midiReceiveClose(kernel); notifyListeners(new MidiDevice.Event(midiOut, = MidiDevice.Event.Type.CLOSE, -1)); } public MidiDevice.Info getInfo() { return info; =20 } public int getMode() { return OMNI_ON_POLY; } public int[] getModes() { int[] modes =3D new int[1]; modes[0] =3D OMNI_ON_POLY; return modes; } public boolean isOpen() { return synthesizer.isMidiReceiveOpen(kernel); } public void removeListener(MidiDevice.Listener listener) { listeners.remove(listener); } public int setMode(int mode) { return OMNI_ON_POLY; } } public MidiOut midiOut =3D new MidiOut(); /* * kernel pulls audio from clients using audioIn, * which is an OutputDevice. / public abstract class AudioIn implements OutputDevice { } public AudioIn audioIn =3D new AudioIn(); /* * Clients pull audio from kernel using audioOut, * which is an InputDevice. / public class AudioOut implements InputDevice, InputChannel { ArrayList audioFormats =3D new ArrayList(); public class Info extends Device.Info { Info(String name, String vendor, String description) { super(name, vendor, description); } } Info info =3D new Info("Audio out", "Vineyard Productions", = "kernel audio out"); ArrayList listeners =3D new ArrayList(); boolean rendering =3D false; AudioOut() { audioFormats.add(new = AudioFormat(AudioFormat.Encoding.PCM_SIGNED_LITTLE_ENDIAN, = AudioFormat.FREE_RATE, 16, 1, 32, AudioFormat.FREE_RATE)); audioFormats.add(new = AudioFormat(AudioFormat.Encoding.PCM_SIGNED_LITTLE_ENDIAN, = AudioFormat.FREE_RATE, 24, 1, 48, AudioFormat.FREE_RATE)); audioFormats.add(new = AudioFormat(AudioFormat.Encoding.PCM_SIGNED_LITTLE_ENDIAN, = AudioFormat.FREE_RATE, 16, 2, 32, AudioFormat.FREE_RATE)); audioFormats.add(new = AudioFormat(AudioFormat.Encoding.PCM_SIGNED_LITTLE_ENDIAN, = AudioFormat.FREE_RATE, 24, 2, 48, AudioFormat.FREE_RATE)); } void notifyListeners(Channel.Event event) { for(int i =3D 0, n =3D listeners.size(); i < n; i++) { ((Channel.Listener) listeners.get(i)).update(event); } } public AudioFormat[] getFormats() { return (AudioFormat[]) audioFormats.toArray(); } public Device.Info getInfo() { return info; } public long getLatency() { return 10000; } public boolean supportsFormat(AudioFormat format) { return audioFormats.contains(format); } public InputChannel getInputChannel(AudioFormat audioFormat, int = bufferSize) { if(!supportsFormat(audioFormat)) { return null; } synthesizer.setAudioSampleFramesPerSecond(kernel, (int) = audioFormat.getFrameRate()); synthesizer.setAudioOutputChannelCount(kernel, = audioFormat.getChannels()); return audioOut; } public void addListener(Channel.Listener listener) { listeners.add(listener); } public void close() { synthesizer.audioOutputClose(kernel); notifyListeners(new Channel.Event(audioOut, = Channel.Event.Type.CLOSE, -1)); } public void drain() { } public void flush() { } public int getBufferSize() { return synthesizer.getAudioOutputChannelCount(kernel) 4; } public AudioFormat getFormat() { AudioFormat audioFormat =3D new = AudioFormat(AudioFormat.Encoding.PCM_FLOAT, synthesizer.getAudioSampleFramesPerSecond(kernel) / = synthesizer.getAudioOutputChannelCount(kernel), 32,=20 synthesizer.getAudioOutputChannelCount(kernel),=20 getSampleFrameSize(),=20 synthesizer.getAudioSampleFramesPerSecond(kernel)); return audioFormat; } public double getLevel() { return 1.0; } public long getPosition() { return -1; } public boolean isActive() { return synthesizer.audioOutputIsOpen(kernel) && rendering; } public boolean isOpen()=20 { return synthesizer.audioOutputIsOpen(kernel); } public boolean isPaused() { return !rendering; } public void pause() { rendering =3D false; } public void removeListener(Channel.Listener listener) { listeners.remove(listener); } public void resume() { rendering =3D true; } public Control getControl(java.lang.Class controlClass) { return null; } public Control[] getControls() { return null; } public int available() { if(isActive()) { return = synthesizer.getAudioOutputSampleFrameSize(kernel); } return 0; } public int read(byte[] buffer, int offset, int length) { return synthesizer.audioOutputRead(kernel, buffer, offset, = length); } } public AudioOut audioOut =3D new AudioOut(); } ------=_NextPart_000_0017_01BEC0D0.0B31DBA0 Content-Type: application/octet-stream; name="CsoundKernel.java" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="CsoundKernel.java" /** * An implementation of SynthesizerKernel * based on a platform-independent, * re-entrant, multiply instantiable,=20 * double-precision rewrite of Csound with * plugin unit generators and function tables. */ public class CsoundKernel extends SynthesizerKernel { public native long createKernel(); public native void destroyKernel(long kernel); public native boolean read(long kernel, String filename); public native boolean compile(long kernel, String xml); public native void sendCommand(long kernel, String command); public native int loadAllPlugins(long kernel, String directory); public native int loadPlugin(long kernel, String filename); public native boolean midiSendOpen(long kernel); public native boolean midiSendClose(long kernel); public native boolean isMidiSendOpen(long kernel); public native void midiSend(long kernel, byte[] midiSendBytes); public native boolean midiReceiveOpen(long kernel); public native boolean midiReceiveClose(long kernel); public native boolean isMidiReceiveOpen(long kernel); public native synchronized int midiReceive(long kernel, byte[] = midiInBytes, Object monitor); public native int getAudioSampleFramesPerSecond(long kernel); public native void setAudioSampleFramesPerSecond(long kernel, int = value); public native int getAudioSampleFramesPerControlSample(long kernel); public native void setAudioSampleFramesPerControlSample(long kernel, = int value); public native int getAudioInputChannelCount(long kernel); public native void setAudioInputChannelCount(long kernel, int = value); public native boolean audioInputOpen(long kernel); public native boolean audioInputClose(long kernel); public native boolean audioInputIsOpen(long kernel); public native synchronized int audioInputWrite(long kernel, byte[] = audioInputBuffer, int offset, int length, Object monitor); public native int getAudioOutputChannelCount(long kernel); public native void setAudioOutputChannelCount(long kernel, int = value); public native boolean audioOutputOpen(long kernel); public native boolean audioOutputClose(long kernel); public native boolean audioOutputIsOpen(long kernel); public native int audioOutputRead(long kernel, byte[] = audioOutputBuffer, int offset, int length); } ------=_NextPart_000_0017_01BEC0D0.0B31DBA0-- 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 aa13508; 28 Jun 99 2:52 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10yQbA-0000xX-00 for jpff@maths.bath.ac.uk; Mon, 28 Jun 1999 02:52:40 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (CAA16809); Mon, 28 Jun 1999 02:47:37 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Mon, 28 Jun 1999 02:47:25 +0100 Received: from eos.arc.nasa.gov [128.102.118.20] by hermes via ESMTP (CAA12986); Mon, 28 Jun 1999 02:47:23 +0100 (BST) Received: (from jim-ra@localhost) by eos.arc.nasa.gov (8.8.4/8.8.4) id SAA07757; Sun, 27 Jun 1999 18:47:15 -0700 Date: Sun, 27 Jun 1999 18:47:15 -0700 From: "Dr J.Stevenson's research assistant" Message-Id: <199906280147.SAA07757@eos.arc.nasa.gov> To: csound@maths.ex.ac.uk, mrhoades@innerlightpub.com Subject: Re: re techno bashing Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Hmmmmmmmmmm, ever Hear of Thrill Kill Kult ( & thye 38MB Girlz? ) IT IS VERY, VERY DIFERENT ( ~ 8 yrs old too. ) -U wrote:============== . Life is short.... There is a lot of "music" being put out there that I feel is no good at all (yet millions adore). This could give all music a bad rap. Yet I seek within myself as a composer and outside myself as a listener to find those rare gems of quality that do exist. Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa13580; 28 Jun 99 3:05 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10yQo0-0000xt-00 for jpff@maths.bath.ac.uk; Mon, 28 Jun 1999 03:05:56 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (DAA10671); Mon, 28 Jun 1999 03:01:16 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Mon, 28 Jun 1999 03:01:05 +0100 Received: from rothko.bestweb.net [209.94.100.160] by hermes via ESMTP (DAA01644); Mon, 28 Jun 1999 03:01:04 +0100 (BST) Received: from goodguy (dialin-184.poughkeepsie.bestweb.net [216.179.13.82]) by rothko.bestweb.net (8.9.1a/8.9.0) with SMTP id VAA19755; Sun, 27 Jun 1999 21:58:40 -0400 (EDT) Message-ID: <3776B765.74610F2D@westnet.com> Date: Sun, 27 Jun 1999 23:44:37 +0000 From: Larry Troxler X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.31 i586) MIME-Version: 1.0 To: "Dr J.Stevenson's research assistant" CC: csound@maths.ex.ac.uk, mrhoades@innerlightpub.com Subject: [OT] Re: re techno bashing References: <199906280147.SAA07757@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 Dr J.Stevenson's research assistant wrote: > > Hmmmmmmmmmm, ever Hear of Thrill Kill Kult ( & thye 38MB Girlz? ) > IT IS VERY, VERY DIFERENT ( ~ 8 yrs old too. ) > -U wrote:============== > . > Life is short.... > There is a lot of "music" being put out there that I feel is no good > at all (yet millions adore). This could give all music a bad rap. Yet I seek > within myself as a composer and outside myself as a listener to find those > rare gems of quality that do exist. BZZZTTT!!! So sorry, but you're off-topic. This is the csound list :-) (Well, I should talk!) Larry Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa13950; 28 Jun 99 7: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 10yUoB-00050B-00 for jpff@maths.bath.ac.uk; Mon, 28 Jun 1999 07:22:23 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (HAA02701); Mon, 28 Jun 1999 07:18:29 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Mon, 28 Jun 1999 07:18:17 +0100 Received: from eos.arc.nasa.gov [128.102.118.20] by hermes via ESMTP (HAA15427); Mon, 28 Jun 1999 07:18:16 +0100 (BST) Received: (from jim-ra@localhost) by eos.arc.nasa.gov (8.8.4/8.8.4) id XAA09910; Sun, 27 Jun 1999 23:18:10 -0700 Date: Sun, 27 Jun 1999 23:18:10 -0700 From: "Dr J.Stevenson's research assistant" Message-Id: <199906280618.XAA09910@eos.arc.nasa.gov> To: lt@westnet.com Subject: Re: [OT] Re: re techno bashing Cc: csound@maths.ex.ac.uk, mrhoades@innerlightpub.com Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Howz it of topic?????????????????????? If ya've heard sum of the weird shit My Life and Times with The Thrill Kill Kult did... you'd be wanna tryin' to copy it with Csound models ( it'd be tough though ) Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa14138; 28 Jun 99 9: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 10yWge-000522-00 for jpff@maths.bath.ac.uk; Mon, 28 Jun 1999 09:22:44 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (JAA06411); Mon, 28 Jun 1999 09:18:56 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Mon, 28 Jun 1999 09:18:42 +0100 Received: from ella.mills.edu [144.91.3.20] by hermes via SMTP (JAA15878); Mon, 28 Jun 1999 09:18:41 +0100 (BST) Received: (qmail 636053 invoked by uid 1964); 28 Jun 1999 01:18:17 -0700 Date: Mon, 28 Jun 1999 01:18:16 -0700 (PDT) From: "Matt J. Ingalls" Reply-To: "Matt J. Ingalls" To: csound@maths.ex.ac.uk Subject: PPC REAL TIME Beta In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk hey everyone, i just put a (hacked) beta of "perf3.55" on the mills ftp site: ftp://mills.edu/ccm/csound.ppc/RTPerf_beta.hqx if you are interested and/or use RT Csound on a mac, it might be nice to test out. Here's the Hack: ================ - all User Interface (most noticeably the transport and switching to another app) is frozen during Real Time Rendering - this means that if you are using the "f0" in your score method to play to infinity you will have to control-option-cmmd-escape to kill "perf" - to remove clicks/studders use the listing file option with the preference "listing file dispables output window" - a less reliable method is to just turn off all noteon and warning messages, but still some messages, like the "new alloc for instr x" message will be printed. - i compiled this version with all optimizations on, which has been known to break some things (like pvoc) -- so let me know if anything isnt working. - i have no MIDI gear so have only tested with MIDI files - please let me know how RTMIDI in works.. - RT sound out has not been tested. - on my 8500/132MHz i got around 40 sine waves (mono 16 bit, default sr/kr) using the smallest (128) buffer sizes before any break ups - and only a bit more using the largest (32768) buffers -- i would be curious to hear what its like on a G3. TODOs ===== - add a user setting for how often perf polls for mouse clicks, so you can set your own balance between UI responsiveness and RT performance. - fix the "play" code for files (after rendering and sndinfo) - using the buffer fills during interrupt,etc.. which will get rid of any studdering/weird pauses/etc.. - try to then use this code for RT processing - which should allow more UI polling and text printing, etc... feel free to email me any bugs or problems. -matt Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa14503; 28 Jun 99 11: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 10yYur-00056o-00 for jpff@maths.bath.ac.uk; Mon, 28 Jun 1999 11:45:33 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (LAA07543); Mon, 28 Jun 1999 11:41:45 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Mon, 28 Jun 1999 11:41:30 +0100 Received: from root@smtp-out-005.wanadoo.fr [193.252.19.88] by hermes via ESMTP (LAA05181); Mon, 28 Jun 1999 11:41:29 +0100 (BST) Received: from bmpl1-1-48.abo.wanadoo.fr [193.250.98.48] by wanadoo.fr for Paris Mon, 28 Jun 1999 12:41:23 +0200 (MET DST) Message-ID: <3777513C.FE905778@exbang.com> Date: Mon, 28 Jun 1999 12:41:03 +0200 From: Michel Jullian Reply-To: mj@exbang.com X-Mailer: Mozilla 4.04 (Macintosh; I; PPC) MIME-Version: 1.0 To: vst-plugins list CC: csound list , music-dsp list , reaktor-list , buzz-talk Subject: "Instrument files" for modular VST2 plugins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk (This is cross posted to the Csound, music-dsp, Generator/Reaktor and Buzz lists, sorry for those who are subscribed to all of them ;-) Hi Charlie, I think it would be a Good Thing if there were special provisions in VST2 for modular (as opposed to hardwired) plugins, such as Generator (VST2 announced for this summer), Csound (Michael Gogins just announced he is going to implement the VST2 interface in a new shared library version of Csound based on Paul Barton-Davis' Quasimodo kernel), SuperCollider (James McCartney envisages making it a "very fat" VST2 plugin), or Buzz (there is talk about VST2), which will need an additional "instrument file" to know what processing they should perform. Concretely it would be nice if, at first plugin instantiation in a document, the host (to avoid platform-specific code in the plugin, which is a paramount prerequisite for Csound people, and quite a relief for all others) could query the plugin for its "instrument files" extensions (.ins and .ens for Generator, .orc for Csound, .sc I think for SuperCollider, "hardwired" plugins just won't implement the extension accessor method which will preserve backward compatibility), and then launch an accordingly filtered Open dialog allowing the user to pick his/her "instrument file". Of course the host's document remembers the path and passes it automatically to the plugin on re-opening. Do you have or would you consider implementing such a mechanism in VST2 (or 2.01 :-) ? I must admit I haven't checked whether there wasn't already such a thing in the VST1 spec, which would make this whole post quite useless. BTW, when can we expect the eagerly awaited vst2 sdk ? :-) -- 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 aa14530; 28 Jun 99 12:02 BST Received: from [156.3.140.104] (helo=shoko.calarts.edu) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10yZBT-00057T-00 for jpff@maths.bath.ac.uk; Mon, 28 Jun 1999 12:02:44 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id DAA27774 for music-dsp-outgoing; Mon, 28 Jun 1999 03:41:41 -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 DAA27770 for ; Mon, 28 Jun 1999 03:41:32 -0700 (PDT) Received: from bmpl1-1-48.abo.wanadoo.fr [193.250.98.48] by wanadoo.fr for Paris Mon, 28 Jun 1999 12:41:23 +0200 (MET DST) Message-ID: <3777513C.FE905778@exbang.com> Date: Mon, 28 Jun 1999 12:41:03 +0200 From: Michel Jullian X-Mailer: Mozilla 4.04 (Macintosh; I; PPC) MIME-Version: 1.0 To: vst-plugins list CC: csound list , music-dsp list , reaktor-list , buzz-talk Subject: "Instrument files" for modular VST2 plugins 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 (This is cross posted to the Csound, music-dsp, Generator/Reaktor and Buzz lists, sorry for those who are subscribed to all of them ;-) Hi Charlie, I think it would be a Good Thing if there were special provisions in VST2 for modular (as opposed to hardwired) plugins, such as Generator (VST2 announced for this summer), Csound (Michael Gogins just announced he is going to implement the VST2 interface in a new shared library version of Csound based on Paul Barton-Davis' Quasimodo kernel), SuperCollider (James McCartney envisages making it a "very fat" VST2 plugin), or Buzz (there is talk about VST2), which will need an additional "instrument file" to know what processing they should perform. Concretely it would be nice if, at first plugin instantiation in a document, the host (to avoid platform-specific code in the plugin, which is a paramount prerequisite for Csound people, and quite a relief for all others) could query the plugin for its "instrument files" extensions (.ins and .ens for Generator, .orc for Csound, .sc I think for SuperCollider, "hardwired" plugins just won't implement the extension accessor method which will preserve backward compatibility), and then launch an accordingly filtered Open dialog allowing the user to pick his/her "instrument file". Of course the host's document remembers the path and passes it automatically to the plugin on re-opening. Do you have or would you consider implementing such a mechanism in VST2 (or 2.01 :-) ? I must admit I haven't checked whether there wasn't already such a thing in the VST1 spec, which would make this whole post quite useless. BTW, when can we expect the eagerly awaited vst2 sdk ? :-) -- 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 aa14556; 28 Jun 99 12:18 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 10yZQn-0001GS-00 for jpff@maths.bath.ac.uk; Mon, 28 Jun 1999 12:18:33 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (MAA04316); Mon, 28 Jun 1999 12:13:35 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Mon, 28 Jun 1999 12:13:18 +0100 Received: from root@smtp-out-004.wanadoo.fr [193.252.19.87] by hermes via ESMTP (MAA05006); Mon, 28 Jun 1999 12:13:17 +0100 (BST) Received: from bmpl1-1-48.abo.wanadoo.fr [193.250.98.48] by wanadoo.fr for Paris Mon, 28 Jun 1999 13:13:09 +0200 (MET DST) Message-ID: <377758C3.C8658C18@exbang.com> Date: Mon, 28 Jun 1999 13:13:11 +0200 From: Michel Jullian Reply-To: mj@exbang.com X-Mailer: Mozilla 4.04 (Macintosh; I; PPC) MIME-Version: 1.0 To: vst-plugins list CC: csound list , music-dsp list , reaktor-list , buzz-talk Subject: Re: "Instrument files" for modular VST2 plugins References: <3777513C.FE905778@exbang.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk And also, sorry, I forgot, there needs to be some way in the plugin interface for the plugin to tell the host "I have changed" : this will be useful in particular when the modular plugin user will introduce a new parameter in his synth. -- 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 aa14588; 28 Jun 99 12: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 10yZeX-0001Gu-00 for jpff@maths.bath.ac.uk; Mon, 28 Jun 1999 12:32:48 +0100 Received: (from majordom@localhost) by shoko.calarts.edu (8.9.3/8.9.3) id EAA27989 for music-dsp-outgoing; Mon, 28 Jun 1999 04:13:22 -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 EAA27985 for ; Mon, 28 Jun 1999 04:13:20 -0700 (PDT) Received: from bmpl1-1-48.abo.wanadoo.fr [193.250.98.48] by wanadoo.fr for Paris Mon, 28 Jun 1999 13:13:09 +0200 (MET DST) Message-ID: <377758C3.C8658C18@exbang.com> Date: Mon, 28 Jun 1999 13:13:11 +0200 From: Michel Jullian X-Mailer: Mozilla 4.04 (Macintosh; I; PPC) MIME-Version: 1.0 To: vst-plugins list CC: csound list , music-dsp list , reaktor-list , buzz-talk Subject: Re: "Instrument files" for modular VST2 plugins References: <3777513C.FE905778@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 And also, sorry, I forgot, there needs to be some way in the plugin interface for the plugin to tell the host "I have changed" : this will be useful in particular when the modular plugin user will introduce a new parameter in his synth. -- 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

Date	1999-06-27 15:45
From	Paul Barton-Davis
Subject	Re: Proposal for a new version of Csound
	In message <000e01bec0a0$68034e20$79d496c0@Realizer.ngt.sungard.com>you write: >I'm surprised by the emotional depth of this discussion about C versis C++, >which is distracting the discussion away from the merits of my proposal to >rewrite the kernel of Csound. > >I don't care whether it's C or C++ as long as it's fast and completely >platform-neutral so that in reality it IS just recompilation for different >processors. This is a little disingenuous Michael - we got started on this track because Michel asked "why not do it in C++?" and you offered two arguments against it: speed, and your desire to use only the ANSI C runtime library. >Can we get back to the point now? Sure, but what is the point ? Given that I have already reimplemented a "Csound kernel" to do most of what you describe (and other stuff too), I would think that a good starting point would be: is Quasimodo a reasonable place to begin, or do we (you) want to do it all over again ? If the former, then we can ask: what needs to change in Quasimodo so that it can be used the way that you describe ? I expect that the answer to the first question is "well, no not really". I say this because I have an important goal for Quasimodo that you don't have for your proposal, namely a multithreaded implementation. Multithreadedness is no small alteration to a program, and although its conceivable that we could figure out a way to make this transparent, I think it would come back to bite somewhere else. There are many assumptions throughout the design of Quasimodo that there are different threads handling different responsibilities. The reason that multithreadedness is a problem is because there is a standard for threads that I think makes sense to follow: POSIX P.1003. This standard is not implemented, as far as I know, for the Mac, and I am not sure of its status for Windows (one of the cygnus libraries might have it, I don't know). This makes it hard to see how Quasimodo could form the basis for the cross-platform system you want to build. It certainly violates your desire to stick with the ANSI C runtime library. Other important issues: if you commit to being truly cross-platform, and reliant only on core C functionality, you can't use compiler-compiler's like bison. You could provide the C output of bison as part of the distribution, but that isn't cross-platform. Not using compiler-compilers is one of the biggest problems with Csound as it currently exists, IMHO. I sound negative in the above, which is not intentional. I don't want to see someone else having to redo all the stuff that I've already done, and I think that Quasimodo would itself benefit from being required to meet some of the design goals that you laid out. But I do feel that there is a bit of a disjunction between Quasimodo's overall goals and yours, and that these might make it hard to use the same kernel. It would be great if this was not true, and I welcome suggestions and ideas on how to make it not true. --p

Date	1999-06-27 16:48
From	"Bob Hays, Computer Geek"
Subject	RE: Proposal for a new version of Csound
	> I'm surprised by the emotional depth of this discussion about C > versis C++, which is distracting the discussion away from the merits of my proposal to > rewrite the kernel of Csound. Computer languages, like operating systems, are religious issues, and hence it is quite understandable that people would wage religious war over their favorite. > I don't care whether it's C or C++ as long as it's fast and completely > platform-neutral so that in reality it IS just recompilation for different > processors. Hence, the real question: has anyone stated clearly the goals (requirements) for a rebuild of CSound? BTW, these goals should be testable (quantifiable) in addition to viewable/discussable (qualifiable). Will everyone accede to consensus or will the loudest voice/most willing to do the work triumph? Perhaps a Socratic in the group will start asking questions that can direct this discussion away from anger and towards useful progress. Have fun! - Bob -- "I did not ask for the anal probe" -- Passion Fish "Discipline is never an end in itself, only a means to an end." - King Crimson "Whoever flees history will be pursued by history." - Janusz Korczak Bob Hays \| Aviva Kramer ---------------------------------------+-------------------------------- rhays@interaccess.com (home) \| a1kramer@interaccess.com (home) Bob.Hays@abnamro.com (work) \| http://homepage.interaccess.com/~rhays \|