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