I think this is a truly excellent idea. I hope you have looked at Phil
Burk's JSyn and James McCartney's SuperCollider. You also may want to check
out my plugin opcodes for Csound which appear in my AXCsound (at
http://www.pipeline.com~gogins) and in Gabriel Maldonado's DirectCsound.

I would love to see a software synthesizer that is designed in a modular
fashion, with plugin opcodes (keywords), GENs (function tables), inputs, and
outputs, based on Csound and/or Cmix and other classics reflecting deep
experience in audio DSP. This would be written in C or C++, it would not be
a whole new take on software synthesis the way Arctic or Nyquist or
SuperCollider is, it would just be a cleaned-up version of the C synthesizer
written to be extensible with plugins, efficient, and able to run on many
platforms.

I think re-implementing Csound is a good idea, but there also is SAOL, which
is part of MPEG-4. The SAOL standard, language, and reference implementation
are completely free and available. The language is not as advanced as
SuperCollider or Nyquist, but it is certainly more advanced than Csound. The
problem is the reference implementation is totally an interpreter and is
very slow.

It's important to get in there and do this right in an open source fashion,
otherwise some commercial thing will become popular and freeze development
in ways that may be good, or may be less than optimal. I shudder at the
thought that MIDI will become the only practical way to get performance data
into the standard software synthesizers.

My basic conceptual design, for what it's worth, is a fast SAOL runtime
compiler that has a Csound language backward compatibility mode, is written
in completely vanilla ANSI C or C++, and has plugin keywords, function
tables, inputs, and outputs, uses XML for text files, and in addition to
running as a command line interpreter, serves as native methods for a Java
interface.

Again, I think it is very important to have an open source software
synthesizer that is efficient, that is simple, that reflects long
experience, and yet is extensible with dynamically loaded opcodes so that it
can serve as a platform for contemporary research.

]-----Original Message-----
From: Paul Barton-Davis 
To: csound@maths.ex.ac.uk 
Date: Saturday, March 27, 1999 6:38 PM
Subject: Csound Copyright Holders: please read


>Dear All:
>
>some of you may be aware of my Quasimodo project, which is a
>GNU/Linux-based reimplementation of the internals of Csound, including
>an object oriented, multithreaded architecture, formal grammars and
>parsers, and a GUI based roughly on modular rack mounted devices
>(synthesizers, FX processors, mixers, etc.) that allows real-time
>manipulation of instrument parameters, cross-instrument patching and
>more.
>
>You can read about it at http://www.op.net/~pbd/quasimodo/.
>
>Quasimodo is free software: you will not have to pay for it, but it is
>not public domain. It is released under the GNU Public License, the
>primary goal of which is to ensure that anyone can use Quasimodo for
>anything they like, but nobody can produce versions of it for
>distribution to others and not provide source code to go with it.
>
>One of the fundamental design decisions to this point in the Quasimodo
>project has been to remain source-code compatible with almost all
>existing Csound opcodes. It was my desire to leverage as much as
>possible from the community's years of experience with Csound, and to
>avoid discarding and reimplementing all the amazing work that many
>people have contributed to Csound in the form of various opcodes.
>
>However, it appears from my attempts to contact Barry Vercoe (utterly
>useless), from an email exchange with Richard Boulanger and from
>discussions with Richard Stallman, author of the GPL, that I cannot
>distribute the existing Csound opcodes (modified or not) as part of a
>GPL-covered program. The license for Csound, coming from MIT,
>restricts source code use of Csound to "education and research".
>
>Although I plan to try to talk to MIT and convince them that my goals
>to release a modified set of the Csound opcodes under the GPL are
>honorable and not intended to steal anyone's work, but in fact to
>increase the utility of the work for everyone's benefit, it seems
>unlikely to me that this will succeed.
>
>In the meantime, I plan to split Quasimodo in two: one part will be
>the opcodes, with clear ancestry from Csound and issued under the MIT
>license, implying no source code use outside of education and
>research; and the Quasimodo core (including the parsers, GUI,
>"compiler", and execution engine) under the GPL. The second part
>contains no code derived from Csound, and dynamically loads opcodes,
>so there is no particular relationship between the two parts, except
>of course that the core is pretty useless without the opcodes.
>
>In the longer term, I intend to take up Stallman's challenge to me: "I
>reimplemented most of Unix; why don't you reimplement Csound so that
>it can be truly free ?"
>
>This means that over the coming few months, I will be orchestrating
>the work of others to do "clean-room" implementations of all the
>Csound opcodes that:
>
>       (1) I have not already reimplemented, mostly because of their
>           reliance on the internal data structures of Csound. This
>    includes, for example, all the MIDI opcodes, including
>    those from Gabriel Maldonaldo.
>
>       (2) I have not received notice from the Copyright holder on
>           the opcode source that I may release their opcode source code
>    under the GPL.
>
>I regard this as a sad and sorry and stupid waste of effort, but it
>seems unavoidable in the face of the MIT license.
>
>So, this is a call to anyone who is a copyright holder on one or more
>Csound opcodes (or parts of an opcode, or a function generator):
>
>       If you hold such copyright, and are willing to grant me the
>       right to distribute the source code, or slightly modified
>       versions of the source code, for one or more of those opcodes,
>       under the GNU Public License, version 2.0, please write to me
>       and let me know.
>
>That way, nobody will have to waste their energy and time
>reimplementing your already excellent work.
>
>Quasimodo is *not* an attempt to steal from anyone, but is instead an
>attempt to allow the use of the algorithms and ideas represented in
>Csound's opcodes within a vastly more powerful and notably more
>flexible/extensible framework than the current source base
>represents. I am happy to respect anyone's feeling that the GPL is too
>liberal, or otherwise unacceptable; under those circumstances, I will
>arrange for a programmer who is unfamiliar with the Csound source code
>to write the opcode(s) from scratch using just the Csound manual as a
>guide.
>
>I welcome the help, wisdom, comments and guidance of the Csound
>community.
>
>--sincerely,
>--paul barton-davis
>
>  email: pbd@op.net
>    tel: +1 610-667-4807
>

>I would love to see a software synthesizer that is designed in a modular
>fashion, with plugin opcodes (keywords), GENs (function tables), inputs, and
>outputs, based on Csound and/or Cmix and other classics reflecting deep
>experience in audio DSP. This would be written in C or C++, it would not be
>a whole new take on software synthesis the way Arctic or Nyquist or
>SuperCollider is, it would just be a cleaned-up version of the C synthesizer
>written to be extensible with plugins, efficient, and able to run on many
>platforms.

Quasimodo is all of the above, and more. Except one. It has been
designed with a multithreaded environment in mind, and also a
preemptive operating system. It would take a great deal of careful
work to make it run on Windows-non-NT or Mac operating systems. I have
no intention of doing this work, because I don't use such platforms,
but if someone else wants to, they are welcome, as long as it is done
in a way that does not pollute the code with "#ifdef WIN32" directives.

>I think re-implementing Csound is a good idea, but there also is SAOL, which
>is part of MPEG-4. The SAOL standard, language, and reference implementation
>are completely free and available.

Quasimodo uses an internal structure modelled on compiler technology,
not Csound or SAOL. It is relatively trivial, if you understand Bison
and Flex, to add a new language to it. For example, it took me less
than 1 day to add a new C-like language, which I now tend to use
instead of Csound. The internal structure also facilitates use of some
compiler optimization techniques, which I am working on at present.  I
also plan in the very near future to make even the parsers/lexers into
"plugins".

>It's important to get in there and do this right in an open source fashion,
>otherwise some commercial thing will become popular and freeze development
>in ways that may be good, or may be less than optimal. I shudder at the
>thought that MIDI will become the only practical way to get performance data
>into the standard software synthesizers.

Quasimodo already contains hooks to send it requests "directly" via
shared memory, and it also reads Csound scores from files (though currently,
ramping is not implemented, neither are np and pp references). In
theory, it will also read from FIFO's. As of tonight, it can also use
function tables stored in disk files instead of requiring real-time
generation. 

>My basic conceptual design, for what it's worth, is a fast SAOL runtime
>compiler that has a Csound language backward compatibility mode, is written
>in completely vanilla ANSI C or C++, and has plugin keywords, function
>tables, inputs, and outputs, uses XML for text files, and in addition to
>running as a command line interpreter, serves as native methods for a Java
>interface.

Quasimodo is similar but:

          - there is no command line interpreter at this time
	  - functional separation is at the thread level, not
	    the command line interpreter/GUI interface. Because of the
	    way the GUI works, both parts must share their address
	    space.
	    I considered it an important goal to allow real-time 
	    manipulation of instrument parameters,
	    which Quasimodo allows (e.g. wanna tweak the frequency
	    of an oscillator, or its amplitude, as it runs ? Quasimodo
	    does just this)
	  - written in C++ with the STL, assumes bug-free exceptions
	  - assumes POSIX run time environment, including important
	    use of mmap(2), which limits portability to various platforms.

I'm not sure where XML comes in :) The overall code is completely
object oriented, with some careful inspiration from the "Design
Patterns" community. Therefore it can be easily teased apart and reused
(say, for some java thing; a frightening idea, but different strokes
for different folks ;)
	  
The basic model is essentially a DSP simulation. The DSP instruction
set is made up of the available opcodes. Quasimodo itself consists of
the "compiler" for the DSP (and again, multiple languages are
trivial), the simulator itself (which runs in its own thread, and
under Linux can be made an RT-FIFO thread, with its pages locked down
and its execution (with some kernel patches) optionally bound to a
particular CPU in a multi-CPU setup), and a GUI running in its own
thread. MIDI I/O and other real-time input sources are managed by a
third thread, also capable of running as a real-time thread, and thus
preventing blocking operations in the GUI thread from creating MIDI
latency, etc. The GUI thread and the real-time event manager thread
insert requests into the DSP's submissions queue; the DSP picks them
up on every control cycle, and adds them to its work queue, which it
executes endlessly as long as it not empty. The GUI thread, because
Quasimodo is multithreaded, shares the address space of the DSP
thread, and so can directly manipulate the memory structures used by
the DSP (although this is mediated via object interfaces, of
course). This solves the "parameter update problem" very simply.

I came up with this model after a very careful exploration of the
literature, and also combining my own historical experience with both
large scale parallel computers and artificial life
simulations. Quasimodo contains just about every idea connected with
Music N languages, DSP's and digital synthesis that I could find
starting with Road's book as a jumping off point.

I could write more, but I'll get back to trying to iron out the last
few bugs that are holding up my preliminary release. Quasimodo is not
just an idea - its a working piece of software with a real interface
and it produces real (though at this point, not particularly
interesting) sound.

>Again, I think it is very important to have an open source software
>synthesizer that is efficient, that is simple, that reflects long
>experience, and yet is extensible with dynamically loaded opcodes so that it
>can serve as a platform for contemporary research.

If you have any opcodes you can make available under the GPL, please
let me know. And thanks for your enthusiasm.

--p











Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa00360;
          29 Mar 99 19:41 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
	id 10RgyF-0004hj-00
	for jpff@maths.bath.ac.uk; Mon, 29 Mar 1999 19:41:11 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (TAA09215); Mon, 29 Mar 1999 19:40:11 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Mon, 29 Mar 1999 18:39:59 GMT
Received: from water.CC.McGill.CA [132.206.27.29] by hermes via ESMTP (TAA13435); Mon, 29 Mar 1999 19:39:58 +0100 (BST)
Received: from po-box.mcgill.ca (B57-23.DAS.McGill.CA [198.168.184.143])
	by water.cc.mcgill.ca (8.9.1/8.9.1) with ESMTP id NAA05704
	for ; Mon, 29 Mar 1999 13:39:55 -0500 (EST)
Message-ID: <36FFCA6F.89912DEF@po-box.mcgill.ca>
Date: Mon, 29 Mar 1999 13:46:07 -0500
From: Blake Markle 
X-Mailer: Mozilla 4.08 [en] (Win98; I)
MIME-Version: 1.0
To: "csound@maths.ex.ac.uk" 
Subject: hetro/adsyn: open the black box
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Csounders,

I'm trying to open the "black box" and find out what the hetrodyne
procedure code actually does.  How is the FFT implemented and with what
parameters?  Are phase relations addressed?  Which harmonics are chosen
and why?  How can the accuracy (ie error) of the analysis be
quantitatively or qualitatively measured?  I've read over the c source
code but can't really make heads or tails of it.

The adsyn procedure is more straightforward, but I would like to know
what is happening inside the black box.  I would feel more comfortable
with the whole procedure if I understood exactly what is going on.

If anyone has helpful information or knows of a good source, please let
me know.

Thanks,

Greg Judelman
judelman@abraham.ugrad.physics.mcgill.ca











Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa00568;
          29 Mar 99 21:37 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
	id 10RimM-0004kg-00
	for jpff@maths.bath.ac.uk; Mon, 29 Mar 1999 21:37:02 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (VAA02723); Mon, 29 Mar 1999 21:35:20 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Mon, 29 Mar 1999 20:35:08 GMT
Received: from dns2.seanet.com [199.181.164.2] by hermes via ESMTP (VAA10681); Mon, 29 Mar 1999 21:35:07 +0100 (BST)
Received: from seanet.com (costello.seanet.com [204.182.65.218]) by mx.seanet.com (8.8.8/Seanet-8.7.3) with ESMTP id MAA14715; Mon, 29 Mar 1999 12:34:56 -0800 (PST)
Message-ID: <36FFE3EE.E404F771@seanet.com>
Date: Mon, 29 Mar 1999 12:34:54 -0800
From: Sean Costello 
X-Mailer: Mozilla 4.04 [en] (Win95; U)
MIME-Version: 1.0
To: Paul Barton-Davis 
CC: Michael Gogins , csound@maths.ex.ac.uk
Subject: Re: Csound Copyright Holders: please read
References: <199903291625.LAA03908@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:

> If you have any opcodes you can make available under the GPL, please
> let me know. And thanks for your enthusiasm.

Why do they have to be released under the GPL? I certainly understand
the motives behind the GPL, but some opcode authors may feel constrained
by the terms of the GPL. As far as I understand it, if you write a piece
of software (say an opcode) and "copyleft" it under GPL, you can not use
that piece of software within a commercial product without publishing
the source code for that product (i.e. not really a viable commercial
product). I think that it would be unduly restrictive to insist that
opcodes to be used in Quasimodo must be GPL, as many of the opcode
authors may wish to incorporate their own code into a commercial product
(such as a VST or DirectX plugin) at some point in the future. 

I am hoping to author some opcodes this quarter for my final project in
my computer music course, and I plan on releasing these to the Csound
community as a whole - assuming I can get them to work. :) I would love
for these opcodes, if and when they are completed, to be useable in
Quasimodo, and in any other Csound variant.  However, I have to admit
that I would not want to release them in such a way as to prohibit my
own useage of my own code in a future commercial product.

Just my $.02,

Sean Costello










Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa00657;
          29 Mar 99 22:09 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
	id 10RjHr-0007Vc-00
	for jpff@maths.bath.ac.uk; Mon, 29 Mar 1999 22:09:35 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (WAA02429); Mon, 29 Mar 1999 22:08:27 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Mon, 29 Mar 1999 21:08:16 GMT
Received: from antioch-college.edu [192.131.123.11] by hermes via ESMTP (WAA16028); Mon, 29 Mar 1999 22:08:14 +0100 (BST)
Received: from localhost (jsteiner@localhost)
	by college.antioch-college.edu (8.8.8/8.8.8) with SMTP id QAA12649;
	Mon, 29 Mar 1999 16:11:51 -0500 (EST)
Date: Mon, 29 Mar 1999 16:11:51 -0500 (EST)
From: Josh Steiner 
To: Sean Costello 
cc: Paul Barton-Davis , Michael Gogins , 
    csound@maths.ex.ac.uk
Subject: Re: Csound Copyright Holders: please read
In-Reply-To: <36FFE3EE.E404F771@seanet.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

> Why do they have to be released under the GPL? I certainly understand
> the motives behind the GPL, but some opcode authors may feel constrained
> by the terms of the GPL. As far as I understand it, if you write a piece
> of software (say an opcode) and "copyleft" it under GPL, you can not use
> that piece of software within a commercial product without publishing
> the source code for that product (i.e. not really a viable commercial

Excuse me if i step in here, but this is an incorect interpretation of the
GPL.  The license only says that the person who i chose to distribute my
code to is bound by these terms.  _I_ can ALWAYS release MY CODE under any
license i feel like.  I can simultaneously release it under the GPL, QPL,
NPL, MPL, APSL etc... its totally up to me.  The grey area comes in is
that I cannot change the license on other people alterations/submissions
to that code.  So if someone else sends me some bug fixes for my software,
I could not later alter the license on that code fix without the other
authors consent. 

> community as a whole - assuming I can get them to work. :) I would love
> for these opcodes, if and when they are completed, to be useable in
> Quasimodo, and in any other Csound variant.  However, I have to admit
> that I would not want to release them in such a way as to prohibit my
> own useage of my own code in a future commercial product.

This will never be the case.  You are the copyright owner and get to chose
how you license your code.

Hope that clears some stuff up.

---
Joshua W. H. Steiner - jsteiner@antioch-college.edu - http://joschi.base.org

Turing once dreamed that he was a machine. When he awoke he exclaimed: 

"I don't know whether I am Turing dreaming that I am a machine, or a 
machine dreaming that I am Turing!"











Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa01730;
          30 Mar 99 7:00 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
	id 10RrZN-0007jK-00
	for jpff@maths.bath.ac.uk; Tue, 30 Mar 1999 07:00:14 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (GAA14294); Tue, 30 Mar 1999 06:59:23 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Tue, 30 Mar 1999 06:59:11 +0100
Received: from vcn.bc.ca [207.102.64.2] by hermes via ESMTP (GAA13324); Tue, 30 Mar 1999 06:59:10 +0100 (BST)
Received: from localhost (wfreno@localhost)
	by vcn.bc.ca (8.9.2/8.9.2) with ESMTP id VAA23676;
	Mon, 29 Mar 1999 21:59:08 -0800 (PST)
Date: Mon, 29 Mar 1999 21:59:08 -0800 (PST)
From: Wayne Freno 
To: Robert Junior Mcnulty 
cc: csound@maths.ex.ac.uk
Subject: Re: your mail
In-Reply-To: <19990328121929.25562.qmail@www0x.netaddress.usa.net>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

The csound book comes out in September of 1999.

On 28 Mar 1999, Robert Junior Mcnulty wrote:

> Obviously, My message did not come through.
> When does the book about Csound for Csound come out?
> 
> 
> ____________________________________________________________________
> Get free e-mail and a permanent address at http://www.netaddress.com/?N=1
> 

end soundbite