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