I would really welcome an efficient version of SAOL if it met the following
conditions:

Either licensed under the terms of the GNU General Public License with the
explicit provision that music produced by the thing be saleable for profit,
or inexpensive (less than about $500). I would prefer the GPL approach.

The kernel of the SAOL compiler and runtime should be written in completely
standard C or C++ so that it can be compiled and run on any machine with the
appropriate C or C++ compiler without any changes in source code, except as
to platform-specific MIDI and sound drivers, which should be located in
separate, dynamically loaded modules.

Without ever ceasing to implement the MPEG-4 standard SAOL language, the
SAOL kernel ought to be able to dynamically load, at run time, new opcodes
and wavetable generators and install them into its symbol tables. This would
make the system dynamically extensible. Plugin opcodes, in other words.

The SAOL system should be, as Csound is, a runtime compiler. It should be
possible to write SAOL code using a text editor or score generating program,
then immediately hear the results without going through a round of C code
compilation. It is very difficult to make MUSIC without being able to get
really rapid feedback on instrument and DSP design.

The SAOL kernel ought to be able to produce real-time audio output, or write
a soundfile, or both at the same time.

If these conditions were met, I would almost certainly replace Csound with
the SAOL compiler in all of my work.


-----Original Message-----
From: Eric Scheirer 
To: Thomas Hudson ; Richard Dobson 
Cc: Larry Troxler ; Csound List 
Date: Saturday, February 27, 1999 12:41 PM
Subject: Re: if.../ Common Lisp Music / compilers / interpreters


>I did't make all of this stuff explicit when I noted
>something about SAOL before, and perhaps there are some
>people who are unaware.  This is off-topic for this list, and I
>apologize in advance.  I won't post anything more about SAOL
>for a while.
>
>Thomas Hudson wrote:
>
>>Perhaps it is time for a new environment, inspired by both CLM and CSound,
>>with a GPL-style license so it could be distributed like Linux, and of
>>course, a more modern syntax.
>
>SAOL (pronounced "SAOL") is a new music language that is part
>of the MPEG-4 standard.  It has all of the features that have
>been discussed in this thread, including block-structured
>syntax, procedural abstraction, an extensive library of
>built-in unit generators plus dynamic extensibility, a
>formalized scheduling and processing model, and a lot of other
>things.
>
>The syntax of SAOL is C-like (C++ mode for emacs can be
>used to edit SAOL orchestra code).
>
>SAOL was created by MIT and has formally been released into the
>public domain.  This is a more open license than Csound.  MIT
>has explicitly expressed that it has no plans to profit
>from SAOL in any way.  Every fully conforming MPEG-4 decoder
>(for example, any MPEG-4 set-top box) is required to provide
>real-time synthesis of SAOL code.  The so-called Structured
>Audio tools of MPEG-4 are the only part of MPEG-4 without IP and
>patent hangups.
>
>The implementation that MIT wrote is a simple interpreter.
>There's a brand-new implementation, completely SAOL-compatible
>with ours, that another organization will be making available
>soon (likely free of cost, but I don't know under what terms)
>that compiles SAOL to C code for real-time execution.  There's
>at least one more project in the works to make a free run-time
>p-code interpreter.
>
>There are a number of papers about SAOL and the rest of the
>Structured Audio tools here:
>
>  http://sound.media.mit.edu/~eds/papers.html.
>
>There's an extensive overview being published in the Summer 1999
>Computer Music Journal.
>
>You can download a draft of the Structured Audio standard,
>which contains the formal specification of SAOL, as well as
>my slow implementation, here:
>
>  http://sound.media.mit.edu/mpeg4.
>
>This site also has mailing lists and very simple example orchestras
>to download.
>
>For people who want to get involved, there's lots to do, including
>hacking on the free implementations, writing tutorials, making
>example orchestras, writing music, adding SAOL support to other
>computer-music tools, and so forth.  We're delighted to have you!
>
>Best to all,
>
> -- Eric
>
>+-----------------+
>|  Eric Scheirer  |A-7b5 D7b9|G-7 C7|Cb   C-7b5 F7#9|Bb  |B-7 E7|
>|eds@media.mit.edu|      < http://sound.media.mit.edu/~eds >
>|  617 253 0112   |A A/G# F#-7 F#-/E|Eb-7b5 D7b5|Db|C7b5 B7b5|Bb|
>+-----------------+
>
>











Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa14320;
          28 Feb 99 17:28 GMT
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by shaun.maths.bath.ac.uk with esmtp (Exim 1.92 #2)
	for jpff@maths.bath.ac.uk
	id 10HA0m-0002Hz-00; Sun, 28 Feb 1999 17:28:16 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (RAA18198); Sun, 28 Feb 1999 17:27:16 GMT
Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 28 Feb 1999 17:27:04 GMT
Received: from smtp1.mindspring.com [207.69.200.31] by hermes via ESMTP (RAA07860); Sun, 28 Feb 1999 17:27:03 GMT
Received: from Realizer (user-38ld1c8.dialup.mindspring.com [209.86.133.136])
	by smtp1.mindspring.com (8.8.5/8.8.5) with SMTP id MAA23723;
	Sun, 28 Feb 1999 12:27:04 -0500 (EST)
Message-ID: <001001be633f$9824f180$79d496c0@Realizer.ngt.sungard.com>
From: Michael Gogins 
To: Richard Dobson , 
    Csound List 
Subject: Re: thought experiment (was:Re: if.../)
Date: Sun, 28 Feb 1999 12:27:18 -0500
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

What you are talking about is similar to SmallTalk. The programming
environment for a project can be saved as an "image" and some
implementations of SmallTalk can compile this image to machine language that
executes immediately and efficiently.

However, I must say that I am leery of continuing to invest substantial work
into Csound due to the intellectual property situation, especially now that
SAOL is a standard that exists in the public domain. I would much rather see
an efficient implementation of SAOL that we can all use that has this
feature, which appears to be envisioned or hinted at in the very purpose of
the thing.

-----Original Message-----
From: Richard Dobson 
To: Csound List 
Date: Saturday, February 27, 1999 7:04 PM
Subject: thought experiment (was:Re: if.../)


>I don't have much of a problem with this 'loosely speaking' defininition
>of a compiler, with respect to Csound, though the pseudo-code is very
>tightly coupled to the Csound virtual machine (indeed, entirely
>embedded); even java byte-code can be distributed independently of the
>compiler.
>
>On this basis, all the current 'soft-synth's which are based on the
>ad-lib interconnection of unit generators can similarly be described as
>compilers, even though the 'pseudo-code' generated by them remains
>inacessible. MAX (especially with MSP) would also fall into this
>category.
>
>Now, my thought experiment is this:
>
>One lingering 'feature' of Csound is that although it can be run in
>real-time, as we all know, there is nevertheless a significant delay
>between the command to compile, and the start of performance -
>especially if a number of samples have to be loaded, function tables
>created, and so on. Complex orchestras can themselves take a while to
>compile. Each time the orc+score is run, you have this delay. This is
>even true with Extended Csound on the ADI card - you press 'play' - then
>wait, and at some arbitrary time, performance actually starts.
>
>Given the fact, as established, that Csound compiles into pseudo-code,
>it should be possible to export that code in some binary format,
>together with all ftables, samples, and so forth - in effect, a huge
>readymade preset (and probably not so different in principle from a SAOL
>bit-stream). A cut-down performance-only version of Csound (preferably
>re-entrant!) could load this with negligible delay (no parsing, sorting
>or error-checking - done already by the compiler), and playback would be
>able to start instantly at the moment of the command - as everything has
>already been built. This has a number of advantages - predictable and
>reliable timing in the context of live interactive performance, and the
>possibility of binary-only distribution of instruments and compositions,
>which immediately leads to the further possibility of commercial
>exploitation. This is after all one of the purposes of a compiler - to
>produce an application that can be run and distributed independently of
>the tools used to create it, and that does not expose intellectual
>property.
>
>So, how about it? How feasible is this, and what are the political,
>technical, legal and other ramifications of such a development? Does
>anyone on this list even like the idea?
>
>
>Richard Dobson
>
>Michael Gogins wrote:
>>
>> Sorry to belabor the point, but this whole business of what is a compiler
or
>> an interpreter does not seem to be well understood on this list.
>>
>
>>
>> Csound does not produce executable code for the host processor, but
rather
>> for musmon, which is (loosely speaking) a virtual machine. A virtual
machine
>> is sometimes called an interpreter, but this not accurate. Unlike
>> interpreted code, all the symbols (function addresses, variable
addresses)
>> in pseudo-code are resolved at the time of original translation. It is
more
>> accurate to say that the "actions" in the pseudo-code are carried out by
a
>> virtual machine, which is emulated by a program running on the host
>> processor.
>>
>[etc]
>
>--
>Test your DAW with my Soundcard Attrition Page!
>http://wkweb5.cableinet.co.uk/rwd
>CDP homepage: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm











Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa14425;
          28 Feb 99 18:17 GMT
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by shaun.maths.bath.ac.uk with esmtp (Exim 1.92 #2)
	for jpff@maths.bath.ac.uk
	id 10HAm0-0002KJ-00; Sun, 28 Feb 1999 18:17:04 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (SAA16742); Sun, 28 Feb 1999 18:14:31 GMT
Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 28 Feb 1999 18:14:19 GMT
Received: from aleve.media.mit.edu [18.85.2.171] by hermes via ESMTP (SAA01004); Sun, 28 Feb 1999 18:14:18 GMT
Received: from paddington (dynamic-54.media.mit.edu [18.85.12.182])
	by aleve.media.mit.edu (8.9.1a/8.9.1/+ALEVE) with SMTP id NAA02444;
	Sun, 28 Feb 1999 13:14:12 -0500 (EST)
Received: by localhost with Microsoft MAPI; Sun, 28 Feb 1999 13:16:29 -0500
Message-ID: <01BE631C.8D58E540.eds@media.mit.edu>
From: Eric Scheirer 
Reply-To: "eds@media.mit.edu" 
To: 'Michael Gogins' , 
    Thomas Hudson , Richard Dobson 
Cc: Larry Troxler , Csound List 
Subject: RE: if.../ Common Lisp Music / compilers / interpreters
Date: Sun, 28 Feb 1999 13:16:20 -0500
Organization: MIT Media Laboratory
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Hi Michael,

'saolc' meets all of your criteria except for real-time.  There is no
intrinsic reason why saolc couldn't be made real-time; it's just not
programmed well enough yet.  There's a project going on hosted
at EPFL (a Swiss university) to replace the saolc core with a
real-time SAOL synth.  Anyone who wants to help, I'm sure they'd
be glad for it and I can put you in touch.

In particular:

> Either licensed under the terms of the GNU General Public License with the
> explicit provision that music produced by the thing be saleable for profit,
> or inexpensive (less than about $500). I would prefer the GPL approach.

saolc and the EPFL modifications are both open-source freeware.

> The kernel of the SAOL compiler and runtime should be written in completely
> standard C or C++ so that it can be compiled and run on any machine with the
> appropriate C or C++ compiler without any changes in source code, except as
> to platform-specific MIDI and sound drivers, which should be located in
> separate, dynamically loaded modules.

saolc compiles without problem on Alpha, Linux, OS/2, SGI, and Solaris.  It
should build on Mac, too -- I don't think anyone's tried yet.  Note that MIDI
support is also required in the MPEG-4 specification, including streaming
MIDI data, Standard MIDI files, and DLS-2 wavetable support.  This is done
(well, will be in the April release) in saolc.

> Without ever ceasing to implement the MPEG-4 standard SAOL language, the
> SAOL kernel ought to be able to dynamically load, at run time, new opcodes
> and wavetable generators and install them into its symbol tables. This would
> make the system dynamically extensible. Plugin opcodes, in other words.

Dynamic extensions are part of the SAOL specification.  You can write new
opcodes, unit generators, and wavetable generators in SAOL and they are
linked with the core functionality at orchestra compile-time.  This has the
disadvantage of being slightly less efficient than native C extensions, but
the advantages of guaranteeing portability between SAOL playback devices
and much easier authoring.

With an implementation-language plugin system per your suggestion,
what do I do when sending my SAOL compositions to someone whose SAOL
is running on a vastly different sort of player?  (A set-top box, for example.)
In my view, it's much better for extensions to be coded in SAOL, rather
than having to hybridize SAOL and C++ in order to extend the language.

There's no theoretical reason why a good SAOL compiler shouldn't be able
to run SAOL extensions nearly as fast as C++ extensions -- this is a
compiler-technology issue, not a music issue.  I note also that there's
now serious attention to SAOL in compiler-research groups at several
universities, studying the issues involved in efficient compilation and
run-time systems for SAOL.

> The SAOL system should be, as Csound is, a runtime compiler. It should be
> possible to write SAOL code using a text editor or score generating program,
> then immediately hear the results without going through a round of C code
> compilation. It is very difficult to make MUSIC without being able to get
> really rapid feedback on instrument and DSP design.

I agree.  This is the paradigm taken by saolc.

> The SAOL kernel ought to be able to produce real-time audio output, or write
> a soundfile, or both at the same time.

saolc is "real-time in principle": if your orchestra is simple enough and your
machine fast enough, it generates real-time audio output.  It's only a matter
of efficiency right now.  It generates AIFF files as well.

saolc on my SGI Octane is roughly the speed of Csound on my old Decstation
3500: roughly a factor of 10 for the average orchestra.  So it's not wildly out 
of
realtime now for simple things, and I think it's a straightforward matter of
development attention to make it 5-10x faster.

I'm happy to act as a clearinghouse for improvements made by others
per the Linux model, although I don't have cycles to actively develop saolc
anymore after April.

Best,

 -- Eric











Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa15013;
          28 Feb 99 23:24 GMT
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by shaun.maths.bath.ac.uk with esmtp (Exim 1.92 #2)
	for jpff@maths.bath.ac.uk
	id 10HFZM-0002ZG-00; Sun, 28 Feb 1999 23:24:20 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (XAA11587); Sun, 28 Feb 1999 23:22:24 GMT
Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 28 Feb 1999 23:22:12 GMT
Received: from kgallagh@tempest.ocis.temple.edu [155.247.166.120] by hermes via ESMTP (XAA14259); Sun, 28 Feb 1999 23:22:10 GMT
Received: from localhost (kgallagh@localhost)
	by tempest.ocis.temple.edu (8.8.8/8.8.8) with ESMTP id SAA24747;
	Sun, 28 Feb 1999 18:22:06 -0500 (EST)
Date: Sun, 28 Feb 1999 18:22:06 -0500 (EST)
From: Kevin Gallagher 
X-Sender: kgallagh@tempest.ocis.temple.edu
To: Csound Discussion List 
cc: aclearfi@astro.ocis.temple.edu, mawebs@aol.com, 
    tdavidsn@bellatlantic.net, Michael Berry , 
    "Dr. Maurice Wright" , 
    "Dr. Steven G. Estrella" , makst130+@pitt.edu, 
    "Dr. Norman P. David" , 
    "Edward W. Gaittins III" , 
    David Kaczorowski , dpoe@erols.com, 
    momamissy@juno.com, mherman@nimbus.ocis.temple.edu, 
    miannant@nimbus.ocis.temple.edu, melpaul116@aol.com
Subject: computer music performance in Philly
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Attention Csound/electronic music enthusiasts in the Philadelphia Area,
	I am a student in Temple University's Esther Boyer College of
Music majoring in Jazz Composition and graduating this semester.  As such
I will be presenting my senior recital on March 23.  I have been studying
music technology with Dr. Maurice Wright, and I have put two computer
music pieces on my recital.
	The first piece is a trio of soprano sax, double bass, and
MIDI-controlled electronic sounds.  The electronic sounds are produced by
a computer running a Csound script and playing notes according to MIDI
data from a keyboard synth controller.
	The second piece is my three-movement Csound Suite for solo guitar
synth in conjunction with the computer.  Again, the computer runs a Csound
script, but for this piece a guitar synth is the MIDI controller.
	The recital will be held on Tuesday, March 23, 1999 at 7:30 PM,
Klein Recital Hall, second floor of Presser Hall, Temple University, 13th
and Norris Sts., Philadelphia, PA.  Email me privately for more
information, and if you wish, forward this to anyone you think might be
interested in attending.  I hope to see some of you there!

				Kevin Gallager, kgallagh@astro.temple.edu
				Web - http://astro.temple.edu/~kgallagh













Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa15287;
          1 Mar 99 1:36 GMT
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by wallace.maths.bath.ac.uk with esmtp (Exim 1.92 #2)
	for jpff@maths.bath.ac.uk
	id 10HHdS-0002qe-00; Mon, 1 Mar 1999 01:36:42 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (BAA15256); Mon, 1 Mar 1999 01:34:13 GMT
Received: from exeter.ac.uk by maths.ex.ac.uk; Mon, 1 Mar 1999 01:34:01 GMT
Received: from pop01.globecomm.net [206.253.129.185] by hermes via ESMTP (BAA03056); Mon, 1 Mar 1999 01:34:00 GMT
Received: from iname.com (ppp193.124.mmtl.videotron.net [206.231.124.193]) by pop01.globecomm.net (8.9.0/8.8.0) with ESMTP id UAA17566 for ; Sun, 28 Feb 1999 20:33:51 -0500 (EST)
Message-Id: <199903010133.UAA17566@pop01.globecomm.net>
Date: Sun, 28 Feb 1999 20:41:12 -0500 (EST)
From: Antoine Lefebvre 
Reply-To: gamma_orion@iname.com
Subject: devaudio
To: csound@maths.ex.ac.uk
MIME-Version: 1.0
Content-Type: TEXT/plain; CHARSET=US-ASCII
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Hello csounder,
today I have succesfullt install two soundblaster16 card in my linux
machine. I would like to use one card to do realtime input while the
other do realtime output. However, it seem to be impossible to specify
to csound two different device, like this

csound -odevaudio -idevaudio1 .....

or something like that. I could probably use stdin but if there is no
soundfile header in the input csound use short sample.

There is somebody having an idea.

thanks a lot
-- 
Antoine Lefebvre
antoinelefebvre@softhome.net
http://pages.infinit.net/linux/music/music.html











Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa15461;
          1 Mar 99 3:09 GMT
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by shaun.maths.bath.ac.uk with esmtp (Exim 1.92 #2)
	for jpff@maths.bath.ac.uk
	id 10HJ5X-0002jd-00; Mon, 1 Mar 1999 03:09:47 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (DAA07270); Mon, 1 Mar 1999 03:08:35 GMT
Received: from exeter.ac.uk by maths.ex.ac.uk; Mon, 1 Mar 1999 03:08:23 GMT
Received: from smtp0.mindspring.com [207.69.200.30] by hermes via ESMTP (DAA16725); Mon, 1 Mar 1999 03:08:21 GMT
Received: from Realizer (user-38ld0jf.dialup.mindspring.com [209.86.130.111])
	by smtp0.mindspring.com (8.8.5/8.8.5) with SMTP id WAA25129;
	Sun, 28 Feb 1999 22:08:14 -0500 (EST)
Message-ID: <000e01be6390$c7f4c420$79d496c0@Realizer.ngt.sungard.com>
From: Michael Gogins 
To: eds@media.mit.edu, Thomas Hudson , 
    Richard Dobson 
MMDF-Warning:  Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos
Cc: Larry Troxler , Csound List 
Subject: Re: if.../ Common Lisp Music / compilers / interpreters
Date: Sun, 28 Feb 1999 22:08:27 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

I am not sure myself how much I could contribute to a more efficient SAOLC,
since at this time my time goes mainly into composing, but I would certainly
appreciate your putting me in touch with the EPFL so that they and I could
determine that ourselves. I am currently working as a software engineer
doing C++ development for Infinity, making a foreign currency trading
system. One thing that springs to mind that I could do without much effort
is to provide a Java and/or COM interface for the thing. I might also be
able to help optimizing specific sections of code.

-----Original Message-----
From: Eric Scheirer 
To: 'Michael Gogins' ; Thomas Hudson
; Richard Dobson 
Cc: Larry Troxler ; Csound List 
Date: Sunday, February 28, 1999 1:14 PM
Subject: RE: if.../ Common Lisp Music / compilers / interpreters


>Hi Michael,
>
>'saolc' meets all of your criteria except for real-time.  There is no
>intrinsic reason why saolc couldn't be made real-time; it's just not
>programmed well enough yet.  There's a project going on hosted
>at EPFL (a Swiss university) to replace the saolc core with a
>real-time SAOL synth.  Anyone who wants to help, I'm sure they'd
>be glad for it and I can put you in touch.
>
>In particular:
>
>> Either licensed under the terms of the GNU General Public License with
the
>> explicit provision that music produced by the thing be saleable for
profit,
>> or inexpensive (less than about $500). I would prefer the GPL approach.
>
>saolc and the EPFL modifications are both open-source freeware.
>
>> The kernel of the SAOL compiler and runtime should be written in
completely
>> standard C or C++ so that it can be compiled and run on any machine with
the
>> appropriate C or C++ compiler without any changes in source code, except
as
>> to platform-specific MIDI and sound drivers, which should be located in
>> separate, dynamically loaded modules.
>
>saolc compiles without problem on Alpha, Linux, OS/2, SGI, and Solaris.  It
>should build on Mac, too -- I don't think anyone's tried yet.  Note that
MIDI
>support is also required in the MPEG-4 specification, including streaming
>MIDI data, Standard MIDI files, and DLS-2 wavetable support.  This is done
>(well, will be in the April release) in saolc.
>
>> Without ever ceasing to implement the MPEG-4 standard SAOL language, the
>> SAOL kernel ought to be able to dynamically load, at run time, new
opcodes
>> and wavetable generators and install them into its symbol tables. This
would
>> make the system dynamically extensible. Plugin opcodes, in other words.
>
>Dynamic extensions are part of the SAOL specification.  You can write new
>opcodes, unit generators, and wavetable generators in SAOL and they are
>linked with the core functionality at orchestra compile-time.  This has the
>disadvantage of being slightly less efficient than native C extensions, but
>the advantages of guaranteeing portability between SAOL playback devices
>and much easier authoring.
>
>With an implementation-language plugin system per your suggestion,
>what do I do when sending my SAOL compositions to someone whose SAOL
>is running on a vastly different sort of player?  (A set-top box, for
example.)
>In my view, it's much better for extensions to be coded in SAOL, rather
>than having to hybridize SAOL and C++ in order to extend the language.
>
>There's no theoretical reason why a good SAOL compiler shouldn't be able
>to run SAOL extensions nearly as fast as C++ extensions -- this is a
>compiler-technology issue, not a music issue.  I note also that there's
>now serious attention to SAOL in compiler-research groups at several
>universities, studying the issues involved in efficient compilation and
>run-time systems for SAOL.
>
>> The SAOL system should be, as Csound is, a runtime compiler. It should be
>> possible to write SAOL code using a text editor or score generating
program,
>> then immediately hear the results without going through a round of C code
>> compilation. It is very difficult to make MUSIC without being able to get
>> really rapid feedback on instrument and DSP design.
>
>I agree.  This is the paradigm taken by saolc.
>
>> The SAOL kernel ought to be able to produce real-time audio output, or
write
>> a soundfile, or both at the same time.
>
>saolc is "real-time in principle": if your orchestra is simple enough and
your
>machine fast enough, it generates real-time audio output.  It's only a
matter
>of efficiency right now.  It generates AIFF files as well.
>
>saolc on my SGI Octane is roughly the speed of Csound on my old Decstation
>3500: roughly a factor of 10 for the average orchestra.  So it's not wildly
out
>of
>realtime now for simple things, and I think it's a straightforward matter
of
>development attention to make it 5-10x faster.
>
>I'm happy to act as a clearinghouse for improvements made by others
>per the Linux model, although I don't have cycles to actively develop saolc
>anymore after April.
>
>Best,
>
> -- Eric
>











Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa16367;
          1 Mar 99 10:11 GMT
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by wallace.maths.bath.ac.uk with esmtp (Exim 1.92 #2)
	for jpff@maths.bath.ac.uk
	id 10HPg1-0003JR-00; Mon, 1 Mar 1999 10:11:53 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (KAA10714); Mon, 1 Mar 1999 10:07:30 GMT
Received: from exeter.ac.uk by maths.ex.ac.uk; Mon, 1 Mar 1999 10:07:15 GMT
Received: from falcon.glas.apc.org [193.124.5.54] by hermes via ESMTP (KAA08665); Mon, 1 Mar 1999 10:07:07 GMT
Received: from mail.glas.apc.org([193.124.5.37]) (1155 bytes) by falcon.glas.apc.org
	via sendmail with P:esmtp/R:inet_hosts/T:inet_zone_smtp
	(sender: ) 
	id 
	for ; Mon, 1 Mar 1999 13:06:48 +0300 (WSU)
	(Smail-3.2.0.104 1998-Nov-20 #2 built 1998-Nov-27)
Received: from default(src addr [195.218.128.233]) (780 bytes) by mail.glas.apc.org
	via sendmail with P\:esmtp/R:smart_host/T:smtp
	(sender: ) 
	id 
	for ; Mon, 1 Mar 1999 13:06:41 +0300 (WSU)
	(Smail-3.2.0.96 1997-Jun-2 #11 built DST-Aug-25)
Message-Id: 
From: Sergey Batov 
To: csound@maths.ex.ac.uk
MMDF-Warning:  Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos
Date: Mon, 1 Mar 1999 13:07:22 +0300
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Hi, Csounders!

I suppose that at the beginning the opcode 'pluck' was just some orc+sco,
wasn't
it?

Does anybody know where can I find this (or close to it as much as
possible)
orc+sco?

Also, what is the "two-tap averager" (I found this in
 some article about Karplus-Strong algorithm)?

Thank you.
Regards,


Sergey Batov   batov@glasnet.ru










Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa16799;
          1 Mar 99 12:06 GMT
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by shaun.maths.bath.ac.uk with esmtp (Exim 1.92 #2)
	for jpff@maths.bath.ac.uk
	id 10HRTK-0003Hf-00; Mon, 1 Mar 1999 12:06:54 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (LAA01167); Mon, 1 Mar 1999 11:56:44 GMT
Received: from sunny.ex.ac.uk by maths.ex.ac.uk; Mon, 1 Mar 1999 11:56:25 GMT
Received: from exim@wallace.maths.bath.ac.uk [138.38.100.104] by sunny via ESMTP (LAA15435); Mon, 1 Mar 1999 11:56:29 GMT
Received: from [138.38.97.36] (helo=maths.Bath.AC.UK ident=mmdf)
	by wallace.maths.bath.ac.uk with smtp (Exim 1.92 #2)
	id 10HRJA-0003Ym-00; Mon, 1 Mar 1999 11:56:24 +0000
From: jpff@maths.bath.ac.uk
To: batov@glasnet.ru
CC: csound@maths.ex.ac.uk
In-reply-to:  (message from Sergey Batov on
	Mon, 1 Mar 1999 13:07:22 +0300)
References:  
Date: Mon, 1 Mar 99 11:56:21 GMT
Source-Info:  From (or Sender) name not authenticated.
Message-Id: 
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

I think you are wrong when you say

 Sergey> I suppose that at the beginning the opcode 'pluck' was just some orc+sco,
 Sergey> wasn't it?

I think it was originally coded in C; it certainly is very old and was
already there before I ever used csound

 Sergey> Also, what is the "two-tap averager" (I found this in
 Sergey>  some article about Karplus-Strong algorithm)?

Sounds like an interpolating delay line, using taps at two points and
doing linear interpolation.  Better answer from those who know, or
after a reference

==John ff










Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa17022;
          1 Mar 99 12:57 GMT
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by wallace.maths.bath.ac.uk with esmtp (Exim 1.92 #2)
	for jpff@maths.bath.ac.uk
	id 10HSGJ-0003e9-00; Mon, 1 Mar 1999 12:57:31 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (MAA18447); Mon, 1 Mar 1999 12:40:31 GMT
Received: from exeter.ac.uk by maths.ex.ac.uk; Mon, 1 Mar 1999 12:39:56 GMT
Received: from jaguars-int.cableinet.net [193.38.113.9] by hermes via SMTP (MAA14546); Mon, 1 Mar 1999 12:39:49 GMT
Received: (qmail 24636 invoked from network); 1 Mar 1999 12:36:14 -0000
Received: from unknown (HELO cableinet.co.uk) (194.117.146.49)
  by jaguars with SMTP; 1 Mar 1999 12:36:14 -0000
Message-ID: <36DA8BA5.8A8258B2@cableinet.co.uk>
Date: Mon, 01 Mar 1999 12:44:21 +0000
From: Richard Dobson 
Organization: Composers Desktop Project
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Csound List 
Subject: Re: if.../ Common Lisp Music / compilers / interpreters
References: <01BE631C.8D58E540.eds@media.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

As far as optimizing goes, it looks as if quite a lot could be
translated almost verbatim from Csound. To cite one example I happen to
have noticed - in saolc 'buzz' is implemented by directly calculating
every partial in a loop, using cos(). Csound uses the closed-form
formula (and a table), which is ovbiously much more efficient.

It looks like saolc does meet most of the requirements expressed on this
list for higher-level constructs; there is also a degree of polymorphism
in user-defined opcodes (itself a very useful feature), and a template
mechanism. The global busses, with their 'route/send' opcodes look like
powerful extensions of the facilities provided by the zak system in
Csound. However, the current implementation of saolc is almost certainly
too slow (and incomplete) to draw composers away from Csound in the
short term. A direct translation program would be very nice, but may not
be practicable, and would in any case only be useful insofar as opcodes
which nominally do the same things, such as buzz, fof, the filters, etc,
do in fact match up sonically. 'Fof' and 'grain' especially have many
more parameters in Csound than do the saolc versions.

So there is arguably a useful degree of overlap of interests between
programmers/users of Csound and saolc. For composers working alone, on a
single workstation, speed and range of facilities are likely to be far
more important than portability under the terms of MPEG-4, so that I can
see two semi-independent streams of development arising - the
'canonical' source under the remit of MP4, which naturally needs to be
carefully (and presumably centrally) managed, and a much more
distributed ad-lib development for composers along the lines of Csound.

I am myself interested in working on saolc (partly because it will also
be relevant to CDP users - especially the imminent enhancements!), on
optimizing, adding support for WAVE and WAVE_EX, and no doubt some WIN32
specific things.

Presumably there are dedicated saolc lists, so the question (apart from:
what are those lists?) is to what extent discussion of saolc is welcome
on this list, or is it too much of a digression off-topic? 


Richard Dobson

Eric Scheirer wrote:

> 'saolc' meets all of your criteria except for real-time.  There is no
> intrinsic reason why saolc couldn't be made real-time; it's just not
> programmed well enough yet.  There's a project going on hosted
> at EPFL (a Swiss university) to replace the saolc core with a
> real-time SAOL synth.  Anyone who wants to help, I'm sure they'd
> be glad for it and I can put you in touch.
> 
[snip]
> 
> saolc is "real-time in principle": if your orchestra is simple enough and your
> machine fast enough, it generates real-time audio output.  It's only a matter
> of efficiency right now.  It generates AIFF files as well.
> 
> saolc on my SGI Octane is roughly the speed of Csound on my old Decstation
> 3500: roughly a factor of 10 for the average orchestra.  So it's not wildly out
> of
> realtime now for simple things, and I think it's a straightforward matter of
> development attention to make it 5-10x faster.
> 
> I'm happy to act as a clearinghouse for improvements made by others
> per the Linux model, although I don't have cycles to actively develop saolc
> anymore after April.
> 
> Best,
> 
>  -- Eric

-- 
Test your DAW with my Soundcard Attrition Page!
http://wkweb5.cableinet.co.uk/rwd
CDP homepage: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm