Interesting question; I'd say we've probably inherited the term from
Max Mathews' "An Acoustic Compiler for Music and Psychological
Stimuli" (published 1961):

http://ia802700.us.archive.org/19/items/bstj40-3-677/bstj40-3-677.pdf
https://ieeexplore.ieee.org/document/6773634/

and perhaps the notion of a "Sound Compiler" was commonly understood
at the time transitioning from Music 360 => Music 11 => Csound to talk
about programs that started with source code and generated audio
output to disk.  I would guess that the implementation changed between
generations of MUSIC-N software, but the terminology for the overall
process of code-to-sound stuck around.
On Wed, Aug 15, 2018 at 8:33 PM Mauro Giubileo
 wrote:
>
> To me Csound is much more an interpreter than a compiler...
>
> The "Get started" page of the Csound site defines what a compiler is, describing what it does:
>
>
> source code ---> object code ---> executable file
>              ^
>              |
>           compiler
>
>
> Then it states that Csound does more or less the same thing:
>
>
> source code ---> digital audio stream
>              ^
>              |
>            Csound
>
>
> And, as a result, it is stated that Csound is a compiler, since the analogue of the object code would be the digital audio stream generated by Csound.
>
> Honestly, I don't understand how the author came to this conclusion...
>
> First of all, an object code, result of the compiling process, is a "sequence of instructions" in machine code language (or an intermediate low-level language) which then needs to be further elaborated (and typically linked to other object code files) and finally converted into an executable file or a dynamic library via the so-called "linker".
>
> A digital audio stream, however, is not a sequence of instructions written in an intermediate language (unless you consider a WAV file as a sequence of instructions written in some programming language!), nor does it have the ultimate goal of being converted into an executable or dynamic library...
>
> Csound could be defined "a compiler" if it would generate an intermediate object code which, fed to a "linker", would in turn produce an executable binary capable natively (ie without interpreting further scripts or reading a parsing tree) to reproduce the desired audio stream:
>
>
> Csound source ---> intermediate ---> executable that natively
>     code       ^   object code   ^   generates the audio stream
>                |                 |
>            compiler            linker
>
>
> In practice, in the diagram above, the linker would generate an executable in which the parsing tree that actually Csound creates in ram and crosses each k-time would be transformed directly into native code (and, of course, the run-time execution would be more efficient). Unfortunately, actually this does not happen...
>
> Therefore, I personally think that a more correct (and not misleading) definition of Csound could be the following:
>
> "Csound is a software that is able to generate (and play) audio streams from programs written in Csound language".
>
> And the definition could continue by explaining what "the Csound language" is and what are its motivations and potentials...
>
> What do you think?
>
> Best Regards,
> Mauro
> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Thank you for the link to that document. It's very interesting considering that it's from 1960!
Inside it the author talks about "compiling" in the correct way. The source code of the instruments, in fact, was written in assembly (with many macros) and then compiled into real machine code for the IBM 7090 ancient computer. Then, these machine code programs (the "instruments") were launched by another compiled program, the "sequencer". The order of execution of the instruments and their parameters were taken from the "note cards". The sequencer, therefore, read the notes cards and from these established which instrument to execute, when and for how long. The output (digital audio stream) was collected on magnetic tapes.

In practice, for each of the n instruments of the orchestra you had to write the source code in assembly language so that the compiler could generate n programs in machine code language:

INSTRUMENT n   -----> INSTRUMENT n
 assembly code   ^     machine code
                 |
             compiler

Once the instruments were compiled (the orchestra is ready!), the sequencer program could play the "NOTE cards" (analogue of the Csound score):

NOTES card ---> digital audio stream
            ^
            |
        sequencer

The "NOTE card" corresponded to the "score" section of Csound. The "instruments" corresponded to the source code of the Csound instruments.

The difference is that while in Csound the instruments are programs written in a high-level language (the Csound language) and interpreted at run-time, in the old system from that document, they were written in assembly and then compiled into machine code before being launched by the sequencer!

So, I continue to not understand why Csound is defined as a compiler in the "Get-Started" guide...

Il 2018-08-15 14:21 Steven Yi ha scritto:

Interesting question; I'd say we've probably inherited the term from
Max Mathews' "An Acoustic Compiler for Music and Psychological
Stimuli" (published 1961):

http://ia802700.us.archive.org/19/items/bstj40-3-677/bstj40-3-677.pdf
https://ieeexplore.ieee.org/document/6773634/

and perhaps the notion of a "Sound Compiler" was commonly understood
at the time transitioning from Music 360 => Music 11 => Csound to talk
about programs that started with source code and generated audio
output to disk.  I would guess that the implementation changed between
generations of MUSIC-N software, but the terminology for the overall
process of code-to-sound stuck around.
On Wed, Aug 15, 2018 at 8:33 PM Mauro Giubileo
<mgiubileo@computeraltafed.it> wrote:

To me Csound is much more an interpreter than a compiler...

The "Get started" page of the Csound site defines what a compiler is, describing what it does:


source code ---> object code ---> executable file
             ^
             |
          compiler


Then it states that Csound does more or less the same thing:


source code ---> digital audio stream
             ^
             |
           Csound


And, as a result, it is stated that Csound is a compiler, since the analogue of the object code would be the digital audio stream generated by Csound.

Honestly, I don't understand how the author came to this conclusion...

First of all, an object code, result of the compiling process, is a "sequence of instructions" in machine code language (or an intermediate low-level language) which then needs to be further elaborated (and typically linked to other object code files) and finally converted into an executable file or a dynamic library via the so-called "linker".

A digital audio stream, however, is not a sequence of instructions written in an intermediate language (unless you consider a WAV file as a sequence of instructions written in some programming language!), nor does it have the ultimate goal of being converted into an executable or dynamic library...

Csound could be defined "a compiler" if it would generate an intermediate object code which, fed to a "linker", would in turn produce an executable binary capable natively (ie without interpreting further scripts or reading a parsing tree) to reproduce the desired audio stream:


Csound source ---> intermediate ---> executable that natively
    code       ^   object code   ^   generates the audio stream
               |                 |
           compiler            linker


In practice, in the diagram above, the linker would generate an executable in which the parsing tree that actually Csound creates in ram and crosses each k-time would be transformed directly into native code (and, of course, the run-time execution would be more efficient). Unfortunately, actually this does not happen...

Therefore, I personally think that a more correct (and not misleading) definition of Csound could be the following:

"Csound is a software that is able to generate (and play) audio streams from programs written in Csound language".

And the definition could continue by explaining what "the Csound language" is and what are its motivations and potentials...

What do you think?

Best Regards,
Mauro
Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I believe the term "compiler" was used by analogy. Certainly, Csound
takes high-level source code, and transforms that code to an "object."
In the case of Csound, the "object" is a soundfile or audio stream,
not an object file. In spite of that, many of the steps used by Csound
to perform this transformation are similar to those used by a standard
software compiler. Csound parses input files syntatically to produce
an abstract syntax tree, and attaches semantic actions to the nodes in
the AST



-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

On Wed, Aug 15, 2018 at 9:31 AM Mauro Giubileo
 wrote:
>
> Thank you for the link to that document. It's very interesting considering that it's from 1960!
> Inside it the author talks about "compiling" in the correct way. The source code of the instruments, in fact, was written in assembly (with many macros) and then compiled into real machine code for the IBM 7090 ancient computer. Then, these machine code programs (the "instruments") were launched by another compiled program, the "sequencer". The order of execution of the instruments and their parameters were taken from the "note cards". The sequencer, therefore, read the notes cards and from these established which instrument to execute, when and for how long. The output (digital audio stream) was collected on magnetic tapes.
>
> In practice, for each of the n instruments of the orchestra you had to write the source code in assembly language so that the compiler could generate n programs in machine code language:
>
> INSTRUMENT n   -----> INSTRUMENT n
>  assembly code   ^     machine code
>                  |
>              compiler
>
>
> Once the instruments were compiled (the orchestra is ready!), the sequencer program could play the "NOTE cards" (analogue of the Csound score):
>
>
> NOTES card ---> digital audio stream
>             ^
>             |
>         sequencer
>
>
> The "NOTE card" corresponded to the "score" section of Csound. The "instruments" corresponded to the source code of the Csound instruments.
>
> The difference is that while in Csound the instruments are programs written in a high-level language (the Csound language) and interpreted at run-time, in the old system from that document, they were written in assembly and then compiled into machine code before being launched by the sequencer!
>
> So, I continue to not understand why Csound is defined as a compiler in the "Get-Started" guide...
>
> Regards,
> Mauro
>
>
> Il 2018-08-15 14:21 Steven Yi ha scritto:
>
> Interesting question; I'd say we've probably inherited the term from
> Max Mathews' "An Acoustic Compiler for Music and Psychological
> Stimuli" (published 1961):
>
> http://ia802700.us.archive.org/19/items/bstj40-3-677/bstj40-3-677.pdf
> https://ieeexplore.ieee.org/document/6773634/
>
> and perhaps the notion of a "Sound Compiler" was commonly understood
> at the time transitioning from Music 360 => Music 11 => Csound to talk
> about programs that started with source code and generated audio
> output to disk.  I would guess that the implementation changed between
> generations of MUSIC-N software, but the terminology for the overall
> process of code-to-sound stuck around.
> On Wed, Aug 15, 2018 at 8:33 PM Mauro Giubileo
>  wrote:
>
>
> To me Csound is much more an interpreter than a compiler...
>
> The "Get started" page of the Csound site defines what a compiler is, describing what it does:
>
>
> source code ---> object code ---> executable file
>              ^
>              |
>           compiler
>
>
> Then it states that Csound does more or less the same thing:
>
>
> source code ---> digital audio stream
>              ^
>              |
>            Csound
>
>
> And, as a result, it is stated that Csound is a compiler, since the analogue of the object code would be the digital audio stream generated by Csound.
>
> Honestly, I don't understand how the author came to this conclusion...
>
> First of all, an object code, result of the compiling process, is a "sequence of instructions" in machine code language (or an intermediate low-level language) which then needs to be further elaborated (and typically linked to other object code files) and finally converted into an executable file or a dynamic library via the so-called "linker".
>
> A digital audio stream, however, is not a sequence of instructions written in an intermediate language (unless you consider a WAV file as a sequence of instructions written in some programming language!), nor does it have the ultimate goal of being converted into an executable or dynamic library...
>
> Csound could be defined "a compiler" if it would generate an intermediate object code which, fed to a "linker", would in turn produce an executable binary capable natively (ie without interpreting further scripts or reading a parsing tree) to reproduce the desired audio stream:
>
>
> Csound source ---> intermediate ---> executable that natively
>     code       ^   object code   ^   generates the audio stream
>                |                 |
>            compiler            linker
>
>
> In practice, in the diagram above, the linker would generate an executable in which the parsing tree that actually Csound creates in ram and crosses each k-time would be transformed directly into native code (and, of course, the run-time execution would be more efficient). Unfortunately, actually this does not happen...
>
> Therefore, I personally think that a more correct (and not misleading) definition of Csound could be the following:
>
> "Csound is a software that is able to generate (and play) audio streams from programs written in Csound language".
>
> And the definition could continue by explaining what "the Csound language" is and what are its motivations and potentials...
>
> What do you think?
>
> Best Regards,
> Mauro
> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
>
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>
> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Didn't finish my message before accidentally sending... complete
message follows.

I sent my answer by accident before I was finished. Here is the finished answer.

I believe the term "compiler" was used by analogy.

Internally, Csound uses a Flex-generated lexer and a Bison-generated
parser to transform the orchestra source code into a tree (not an
abstract tree as I first said, I think, but a concrete tree; this is
exposed in the csoundParseOrc function). Then, Csound transforms the
tree by translating its semantic actions into a dynamically linked
chain of opcode invocations, which is an "instance" of Csound (this is
exposed in the csoundCompileTree function).

Up to this point, Csound is acting more or less like a standard
compiler. After this, it's different.

Then, Csound repeatedly invokes the root of the chain of opcode
functions until the score is consumed, or Csound is progammatically
stopped. Csound is similar to a dynamic language runtime in that
Csound repeatedly polls the score or audio and MIDI inputs a bit like
a dynamic language repeatedly polls user input. In other words, Csound
has a built in "main loop."

Csound is different in that there is no attempt to save a directly
executable form of the Csound instance.

In theory, it should be possible, just before (or instead of) running
the Csound instance, to traverse the instance tree and write out
machine language for executing it into an executable file that would
be linked with the Csound shared library. Csound would then be a
compiler by your definition.

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot comOn Wed, Aug 15, 2018 at 10:46 AM
Michael Gogins  wrote:
>
> I believe the term "compiler" was used by analogy. Certainly, Csound
> takes high-level source code, and transforms that code to an "object."
> In the case of Csound, the "object" is a soundfile or audio stream,
> not an object file. In spite of that, many of the steps used by Csound
> to perform this transformation are similar to those used by a standard
> software compiler. Csound parses input files syntatically to produce
> an abstract syntax tree, and attaches semantic actions to the nodes in
> the AST
>
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
> On Wed, Aug 15, 2018 at 9:31 AM Mauro Giubileo
>  wrote:
> >
> > Thank you for the link to that document. It's very interesting considering that it's from 1960!
> > Inside it the author talks about "compiling" in the correct way. The source code of the instruments, in fact, was written in assembly (with many macros) and then compiled into real machine code for the IBM 7090 ancient computer. Then, these machine code programs (the "instruments") were launched by another compiled program, the "sequencer". The order of execution of the instruments and their parameters were taken from the "note cards". The sequencer, therefore, read the notes cards and from these established which instrument to execute, when and for how long. The output (digital audio stream) was collected on magnetic tapes.
> >
> > In practice, for each of the n instruments of the orchestra you had to write the source code in assembly language so that the compiler could generate n programs in machine code language:
> >
> > INSTRUMENT n   -----> INSTRUMENT n
> >  assembly code   ^     machine code
> >                  |
> >              compiler
> >
> >
> > Once the instruments were compiled (the orchestra is ready!), the sequencer program could play the "NOTE cards" (analogue of the Csound score):
> >
> >
> > NOTES card ---> digital audio stream
> >             ^
> >             |
> >         sequencer
> >
> >
> > The "NOTE card" corresponded to the "score" section of Csound. The "instruments" corresponded to the source code of the Csound instruments.
> >
> > The difference is that while in Csound the instruments are programs written in a high-level language (the Csound language) and interpreted at run-time, in the old system from that document, they were written in assembly and then compiled into machine code before being launched by the sequencer!
> >
> > So, I continue to not understand why Csound is defined as a compiler in the "Get-Started" guide...
> >
> > Regards,
> > Mauro
> >
> >
> > Il 2018-08-15 14:21 Steven Yi ha scritto:
> >
> > Interesting question; I'd say we've probably inherited the term from
> > Max Mathews' "An Acoustic Compiler for Music and Psychological
> > Stimuli" (published 1961):
> >
> > http://ia802700.us.archive.org/19/items/bstj40-3-677/bstj40-3-677.pdf
> > https://ieeexplore.ieee.org/document/6773634/
> >
> > and perhaps the notion of a "Sound Compiler" was commonly understood
> > at the time transitioning from Music 360 => Music 11 => Csound to talk
> > about programs that started with source code and generated audio
> > output to disk.  I would guess that the implementation changed between
> > generations of MUSIC-N software, but the terminology for the overall
> > process of code-to-sound stuck around.
> > On Wed, Aug 15, 2018 at 8:33 PM Mauro Giubileo
> >  wrote:
> >
> >
> > To me Csound is much more an interpreter than a compiler...
> >
> > The "Get started" page of the Csound site defines what a compiler is, describing what it does:
> >
> >
> > source code ---> object code ---> executable file
> >              ^
> >              |
> >           compiler
> >
> >
> > Then it states that Csound does more or less the same thing:
> >
> >
> > source code ---> digital audio stream
> >              ^
> >              |
> >            Csound
> >
> >
> > And, as a result, it is stated that Csound is a compiler, since the analogue of the object code would be the digital audio stream generated by Csound.
> >
> > Honestly, I don't understand how the author came to this conclusion...
> >
> > First of all, an object code, result of the compiling process, is a "sequence of instructions" in machine code language (or an intermediate low-level language) which then needs to be further elaborated (and typically linked to other object code files) and finally converted into an executable file or a dynamic library via the so-called "linker".
> >
> > A digital audio stream, however, is not a sequence of instructions written in an intermediate language (unless you consider a WAV file as a sequence of instructions written in some programming language!), nor does it have the ultimate goal of being converted into an executable or dynamic library...
> >
> > Csound could be defined "a compiler" if it would generate an intermediate object code which, fed to a "linker", would in turn produce an executable binary capable natively (ie without interpreting further scripts or reading a parsing tree) to reproduce the desired audio stream:
> >
> >
> > Csound source ---> intermediate ---> executable that natively
> >     code       ^   object code   ^   generates the audio stream
> >                |                 |
> >            compiler            linker
> >
> >
> > In practice, in the diagram above, the linker would generate an executable in which the parsing tree that actually Csound creates in ram and crosses each k-time would be transformed directly into native code (and, of course, the run-time execution would be more efficient). Unfortunately, actually this does not happen...
> >
> > Therefore, I personally think that a more correct (and not misleading) definition of Csound could be the following:
> >
> > "Csound is a software that is able to generate (and play) audio streams from programs written in Csound language".
> >
> > And the definition could continue by explaining what "the Csound language" is and what are its motivations and potentials...
> >
> > What do you think?
> >
> > Best Regards,
> > Mauro
> > Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
> >
> >
> > Csound mailing list
> > Csound@listserv.heanet.ie
> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> > Send bugs reports to
> >         https://github.com/csound/csound/issues
> > Discussions of bugs and features can be posted here
> >
> > Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

So, despite Csound do some things similar to what a compiler would do, you agree with me that Csound is not a compiler, being that its output is neither an intermediate object code nor an executable file, but just an audio stream.

You wrote:

In theory, it should be possible, just before (or instead of) running
the Csound instance, to traverse the instance tree and write out
machine language for executing it into an executable file that would
be linked with the Csound shared library. Csound would then be a
compiler by your definition.

It would be very nice if Csound could generate an optimized executable binary file. I suppose it could give a nice boost to the real-time performance (for example, if you create a synth in Csound, a compiled version of it could achieve greater polyphony on the same computer. Another example: you could chain more advanced audio filters in cascade before you run out of CPU power).

Just a note: the definition of compiler is not "my" definition of compiler... It's the definition that I learned at my University and that I found on every Computer Science book (and every internet site that talks about it). Of course, if we don't agree on the definition of what a compiler is, then all these reasonings would be useless... :-)

Best Regards,
Mauro

Il 2018-08-15 17:15 Michael Gogins ha scritto:

Didn't finish my message before accidentally sending... complete
message follows.

I sent my answer by accident before I was finished. Here is the finished answer.

I believe the term "compiler" was used by analogy.

Internally, Csound uses a Flex-generated lexer and a Bison-generated
parser to transform the orchestra source code into a tree (not an
abstract tree as I first said, I think, but a concrete tree; this is
exposed in the csoundParseOrc function). Then, Csound transforms the
tree by translating its semantic actions into a dynamically linked
chain of opcode invocations, which is an "instance" of Csound (this is
exposed in the csoundCompileTree function).

Up to this point, Csound is acting more or less like a standard
compiler. After this, it's different.

Then, Csound repeatedly invokes the root of the chain of opcode
functions until the score is consumed, or Csound is progammatically
stopped. Csound is similar to a dynamic language runtime in that
Csound repeatedly polls the score or audio and MIDI inputs a bit like
a dynamic language repeatedly polls user input. In other words, Csound
has a built in "main loop."

Csound is different in that there is no attempt to save a directly
executable form of the Csound instance.

In theory, it should be possible, just before (or instead of) running
the Csound instance, to traverse the instance tree and write out
machine language for executing it into an executable file that would
be linked with the Csound shared library. Csound would then be a
compiler by your definition.

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot comOn Wed, Aug 15, 2018 at 10:46 AM
Michael Gogins <michael.gogins@gmail.com> wrote:

I believe the term "compiler" was used by analogy. Certainly, Csound
takes high-level source code, and transforms that code to an "object."
In the case of Csound, the "object" is a soundfile or audio stream,
not an object file. In spite of that, many of the steps used by Csound
to perform this transformation are similar to those used by a standard
software compiler. Csound parses input files syntatically to produce
an abstract syntax tree, and attaches semantic actions to the nodes in
the AST



-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

On Wed, Aug 15, 2018 at 9:31 AM Mauro Giubileo
<mgiubileo@computeraltafed.it> wrote:

Thank you for the link to that document. It's very interesting considering that it's from 1960!
Inside it the author talks about "compiling" in the correct way. The source code of the instruments, in fact, was written in assembly (with many macros) and then compiled into real machine code for the IBM 7090 ancient computer. Then, these machine code programs (the "instruments") were launched by another compiled program, the "sequencer". The order of execution of the instruments and their parameters were taken from the "note cards". The sequencer, therefore, read the notes cards and from these established which instrument to execute, when and for how long. The output (digital audio stream) was collected on magnetic tapes.

In practice, for each of the n instruments of the orchestra you had to write the source code in assembly language so that the compiler could generate n programs in machine code language:

INSTRUMENT n   -----> INSTRUMENT n
 assembly code   ^     machine code
                 |
             compiler


Once the instruments were compiled (the orchestra is ready!), the sequencer program could play the "NOTE cards" (analogue of the Csound score):


NOTES card ---> digital audio stream
            ^
            |
        sequencer


The "NOTE card" corresponded to the "score" section of Csound. The "instruments" corresponded to the source code of the Csound instruments.

The difference is that while in Csound the instruments are programs written in a high-level language (the Csound language) and interpreted at run-time, in the old system from that document, they were written in assembly and then compiled into machine code before being launched by the sequencer!

So, I continue to not understand why Csound is defined as a compiler in the "Get-Started" guide...

Regards,
Mauro


Il 2018-08-15 14:21 Steven Yi ha scritto:

Interesting question; I'd say we've probably inherited the term from
Max Mathews' "An Acoustic Compiler for Music and Psychological
Stimuli" (published 1961):

http://ia802700.us.archive.org/19/items/bstj40-3-677/bstj40-3-677.pdf
https://ieeexplore.ieee.org/document/6773634/

and perhaps the notion of a "Sound Compiler" was commonly understood
at the time transitioning from Music 360 => Music 11 => Csound to talk
about programs that started with source code and generated audio
output to disk.  I would guess that the implementation changed between
generations of MUSIC-N software, but the terminology for the overall
process of code-to-sound stuck around.
On Wed, Aug 15, 2018 at 8:33 PM Mauro Giubileo
<mgiubileo@computeraltafed.it> wrote:


To me Csound is much more an interpreter than a compiler...

The "Get started" page of the Csound site defines what a compiler is, describing what it does:


source code ---> object code ---> executable file
             ^
             |
          compiler


Then it states that Csound does more or less the same thing:


source code ---> digital audio stream
             ^
             |
           Csound


And, as a result, it is stated that Csound is a compiler, since the analogue of the object code would be the digital audio stream generated by Csound.

Honestly, I don't understand how the author came to this conclusion...

First of all, an object code, result of the compiling process, is a "sequence of instructions" in machine code language (or an intermediate low-level language) which then needs to be further elaborated (and typically linked to other object code files) and finally converted into an executable file or a dynamic library via the so-called "linker".

A digital audio stream, however, is not a sequence of instructions written in an intermediate language (unless you consider a WAV file as a sequence of instructions written in some programming language!), nor does it have the ultimate goal of being converted into an executable or dynamic library...

Csound could be defined "a compiler" if it would generate an intermediate object code which, fed to a "linker", would in turn produce an executable binary capable natively (ie without interpreting further scripts or reading a parsing tree) to reproduce the desired audio stream:


Csound source ---> intermediate ---> executable that natively
    code       ^   object code   ^   generates the audio stream
               |                 |
           compiler            linker


In practice, in the diagram above, the linker would generate an executable in which the parsing tree that actually Csound creates in ram and crosses each k-time would be transformed directly into native code (and, of course, the run-time execution would be more efficient). Unfortunately, actually this does not happen...

Therefore, I personally think that a more correct (and not misleading) definition of Csound could be the following:

"Csound is a software that is able to generate (and play) audio streams from programs written in Csound language".

And the definition could continue by explaining what "the Csound language" is and what are its motivations and potentials...

What do you think?

Best Regards,
Mauro
Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I think, in your case (waiting hours to produce a WAV file from a csd file) you used Csound as an "offline renderer", not as a "compiler". The output of a compiler should be an intermediate object code or an executable file... But a WAV file it is neither one nor the other. :-)

Regards,
Mauro

Il 2018-08-15 17:09 Brian Redfern ha scritto:

Now that csound can run in realtime even on phones it is more helpful to think of it as an interpreter but back in the late 90s running a Mac os9 machine with 24 Meg's of RAM it was a compiler you sometimes waited hours for a WAV file to be produced from your code. Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

I think that in many cases the speed increase would be much more bigger than twice. For example, from my experiments, if I use a Csound implementation of the biquad opcode instead of the native one, the performance decreases dramatically... Tens and tens of times slower... Maybe it's my Csound implementation that is wrong, so here it is my biquad udo:

opcode mybiquad, a, akkkkkk
    aXn, kb0, kb1, kb2, ka0, ka1, ka2 xin
            setksmps 1
    
    kXn_1   init    0 ; x[n-1]
    kXn_2   init    0 ; x[n-2]
    kYn_1   init    0 ; y[n-1]
    kYn_2   init    0 ; y[n-2]
    
    ; a0*y(n) + a1*y[n-1] + a2*y[n-2] = b0*x[n] + b1*x[n-1] + b2*x[n-2]
    aYn     =       (kb0*aXn + kb1*kXn_1 + kb2*kXn_2 - ka1*kYn_1 - ka2*kYn_2) / ka0
    
    ; let's prepare for next iteration:
    kXn_2   =       kXn_1
    kXn_1   =       aXn[0]
    kYn_2   =       kYn_1
    kYn_1   =       aYn[0]
        
            xout    aYn
endop

In my experience the above code is incredibly slower than the native biquad opcode (if the global ksmps=256 it's about 20 times slower!), so, either there is something that is horribly wrong in my implementation, or the Csound tree traversal is much slower than a true native execution (and, consequently, a Csound scripts would greatly benefit from a full compilation in a binary executable).

Regards,
Mauro

Il 2018-08-15 19:43 Michael Gogins ha scritto:

Based on a variety of experiments I've performed over the years, Csound is doing all but the last steps a real computer would do, yes. But in addition to compiling there is optimization and linking, including link time optimization. I think replacing the existing steps after csoundCompileTree with compilation to machine language using LLVM with LTO could double the speed of Csound. Maybe. 

On Wed, Aug 15, 2018, 12:55 Forrest Curo <treegestalt@gmail.com> wrote:

If each built-in 'opcode' is a chunk of optimized code, & the 'program' that gets interpreted by a csound instance is a string of these... probably we're not very far from something a compiler would produce; we just aren't saving it in that form because we're already running extremely close to what a compiled executable would do in practice, & getting it from a general-purpose piece of software.

(?)

 

Forrest

San Diego

On Wed, Aug 15, 2018 at 9:49 AM, Mauro Giubileo <mgiubileo@computeraltafed.it> wrote:

I think, in your case (waiting hours to produce a WAV file from a csd file) you used Csound as an "offline renderer", not as a "compiler". The output of a compiler should be an intermediate object code or an executable file... But a WAV file it is neither one nor the other. :-)

Regards,
Mauro

Il 2018-08-15 17:09 Brian Redfern ha scritto:

Now that csound can run in realtime even on phones it is more helpful to think of it as an interpreter but back in the late 90s running a Mac os9 machine with 24 Meg's of RAM it was a compiler you sometimes waited hours for a WAV file to be produced from your code. Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Hi Michael, I didn't know of Faust and the related Csound opcodes. It's very interesting!

I spent the day trying to get used to the Faust language (I have to say, its reference docs and tutorials are not much beginner-friendly, and the language itself is not one of the easiest to learn!).

Anyway, after a lot of effort, I managed to write my Faust version of the biquad opcode. The problem is: Csound give me errors when I try to use the faustgen opcode... I'm sure the problem is not in my code, because it gives the same errors with the example in the Csound docs too!

For example, the following code from the Csound manual:

instr 1

  ain1 oscili 0dbfs/2, 440

  idsp,a1 faustgen {{

    gain = hslider("vol",1,0,1,0.01);

    process = (_ * gain);

  }}, ain1

  k1 line 0, p3, 1

  faustctl idsp, "vol", k1

  out a1

endin

when I try to run it, I have an error like the following:

>>> idsp,a1 faustgen <<<

Unexpected untyped word a1 when expecting a variable

What can it be?

Regards,

Mauro

Il 2018-08-15 23:57 Michael Gogins ha scritto:

That's very interesting. I appreciate your making these kinds of measurements. 

 

Are you aware of the LLVM based runtime compiler for Faust and the Csound opcodes that use it?

On Wed, Aug 15, 2018, 17:33 Mauro Giubileo <mgiubileo@computeraltafed.it> wrote:

I think that in many cases the speed increase would be much more bigger than twice. For example, from my experiments, if I use a Csound implementation of the biquad opcode instead of the native one, the performance decreases dramatically... Tens and tens of times slower... Maybe it's my Csound implementation that is wrong, so here it is my biquad udo:

opcode mybiquad, a, akkkkkk
    aXn, kb0, kb1, kb2, ka0, ka1, ka2 xin
            setksmps 1
    
    kXn_1   init    0 ; x[n-1]
    kXn_2   init    0 ; x[n-2]
    kYn_1   init    0 ; y[n-1]
    kYn_2   init    0 ; y[n-2]
    
    ; a0*y(n) + a1*y[n-1] + a2*y[n-2] = b0*x[n] + b1*x[n-1] + b2*x[n-2]
    aYn     =       (kb0*aXn + kb1*kXn_1 + kb2*kXn_2 - ka1*kYn_1 - ka2*kYn_2) / ka0
    
    ; let's prepare for next iteration:
    kXn_2   =       kXn_1
    kXn_1   =       aXn[0]
    kYn_2   =       kYn_1
    kYn_1   =       aYn[0]
        
            xout    aYn
endop

 

In my experience the above code is incredibly slower than the native biquad opcode (if the global ksmps=256 it's about 20 times slower!), so, either there is something that is horribly wrong in my implementation, or the Csound tree traversal is much slower than a true native execution (and, consequently, a Csound scripts would greatly benefit from a full compilation in a binary executable).

Regards,
Mauro

Il 2018-08-15 19:43 Michael Gogins ha scritto:

Based on a variety of experiments I've performed over the years, Csound is doing all but the last steps a real computer would do, yes. But in addition to compiling there is optimization and linking, including link time optimization. I think replacing the existing steps after csoundCompileTree with compilation to machine language using LLVM with LTO could double the speed of Csound. Maybe. 

On Wed, Aug 15, 2018, 12:55 Forrest Curo <treegestalt@gmail.com> wrote:

If each built-in 'opcode' is a chunk of optimized code, & the 'program' that gets interpreted by a csound instance is a string of these... probably we're not very far from something a compiler would produce; we just aren't saving it in that form because we're already running extremely close to what a compiled executable would do in practice, & getting it from a general-purpose piece of software.

(?)

 

Forrest

San Diego

On Wed, Aug 15, 2018 at 9:49 AM, Mauro Giubileo <mgiubileo@computeraltafed.it> wrote:

I think, in your case (waiting hours to produce a WAV file from a csd file) you used Csound as an "offline renderer", not as a "compiler". The output of a compiler should be an intermediate object code or an executable file... But a WAV file it is neither one nor the other. :-)

Regards,
Mauro

Il 2018-08-15 17:09 Brian Redfern ha scritto:

Now that csound can run in realtime even on phones it is more helpful to think of it as an interpreter but back in the late 90s running a Mac os9 machine with 24 Meg's of RAM it was a compiler you sometimes waited hours for a WAV file to be produced from your code. Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Sorry I can't help you, as I haven't been able to get the faustgen
opcode built on my system, so I'm not able to try what you did to see
what the problem is. But it's on my list of things to do!

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

On Thu, Aug 16, 2018 at 7:17 PM Mauro Giubileo
 wrote:
>
> Hi Michael, I didn't know of Faust and the related Csound opcodes. It's very interesting!
>
> I spent the day trying to get used to the Faust language (I have to say, its reference docs and tutorials are not much beginner-friendly, and the language itself is not one of the easiest to learn!).
>
> Anyway, after a lot of effort, I managed to write my Faust version of the biquad opcode. The problem is: Csound give me errors when I try to use the faustgen opcode... I'm sure the problem is not in my code, because it gives the same errors with the example in the Csound docs too!
>
> For example, the following code from the Csound manual:
>
> instr 1
>
>   ain1 oscili 0dbfs/2, 440
>
>   idsp,a1 faustgen {{
>
>     gain = hslider("vol",1,0,1,0.01);
>
>     process = (_ * gain);
>
>   }}, ain1
>
>   k1 line 0, p3, 1
>
>   faustctl idsp, "vol", k1
>
>   out a1
>
> endin
>
> when I try to run it, I have an error like the following:
>
> >>> idsp,a1 faustgen <<<
>
> Unexpected untyped word a1 when expecting a variable
>
>
>
> What can it be?
>
>
>
> Regards,
>
> Mauro
>
>
>
> Il 2018-08-15 23:57 Michael Gogins ha scritto:
>
> That's very interesting. I appreciate your making these kinds of measurements.
>
> Are you aware of the LLVM based runtime compiler for Faust and the Csound opcodes that use it?
>
> On Wed, Aug 15, 2018, 17:33 Mauro Giubileo  wrote:
>>
>> I think that in many cases the speed increase would be much more bigger than twice. For example, from my experiments, if I use a Csound implementation of the biquad opcode instead of the native one, the performance decreases dramatically... Tens and tens of times slower... Maybe it's my Csound implementation that is wrong, so here it is my biquad udo:
>>
>> opcode mybiquad, a, akkkkkk
>>     aXn, kb0, kb1, kb2, ka0, ka1, ka2 xin
>>             setksmps 1
>>
>>     kXn_1   init    0 ; x[n-1]
>>     kXn_2   init    0 ; x[n-2]
>>     kYn_1   init    0 ; y[n-1]
>>     kYn_2   init    0 ; y[n-2]
>>
>>     ; a0*y(n) + a1*y[n-1] + a2*y[n-2] = b0*x[n] + b1*x[n-1] + b2*x[n-2]
>>     aYn     =       (kb0*aXn + kb1*kXn_1 + kb2*kXn_2 - ka1*kYn_1 - ka2*kYn_2) / ka0
>>
>>     ; let's prepare for next iteration:
>>     kXn_2   =       kXn_1
>>     kXn_1   =       aXn[0]
>>     kYn_2   =       kYn_1
>>     kYn_1   =       aYn[0]
>>
>>             xout    aYn
>> endop
>>
>>
>>
>> In my experience the above code is incredibly slower than the native biquad opcode (if the global ksmps=256 it's about 20 times slower!), so, either there is something that is horribly wrong in my implementation, or the Csound tree traversal is much slower than a true native execution (and, consequently, a Csound scripts would greatly benefit from a full compilation in a binary executable).
>>
>> Regards,
>> Mauro
>>
>>
>> Il 2018-08-15 19:43 Michael Gogins ha scritto:
>>
>> Based on a variety of experiments I've performed over the years, Csound is doing all but the last steps a real computer would do, yes. But in addition to compiling there is optimization and linking, including link time optimization. I think replacing the existing steps after csoundCompileTree with compilation to machine language using LLVM with LTO could double the speed of Csound. Maybe.
>>
>> On Wed, Aug 15, 2018, 12:55 Forrest Curo  wrote:
>>>
>>> If each built-in 'opcode' is a chunk of optimized code, & the 'program' that gets interpreted by a csound instance is a string of these... probably we're not very far from something a compiler would produce; we just aren't saving it in that form because we're already running extremely close to what a compiled executable would do in practice, & getting it from a general-purpose piece of software.
>>> (?)
>>>
>>> Forrest
>>> San Diego
>>>
>>> On Wed, Aug 15, 2018 at 9:49 AM, Mauro Giubileo  wrote:
>>>>
>>>> I think, in your case (waiting hours to produce a WAV file from a csd file) you used Csound as an "offline renderer", not as a "compiler". The output of a compiler should be an intermediate object code or an executable file... But a WAV file it is neither one nor the other. :-)
>>>>
>>>> Regards,
>>>> Mauro
>>>>
>>>>
>>>> Il 2018-08-15 17:09 Brian Redfern ha scritto:
>>>>
>>>> Now that csound can run in realtime even on phones it is more helpful to think of it as an interpreter but back in the late 90s running a Mac os9 machine with 24 Meg's of RAM it was a compiler you sometimes waited hours for a WAV file to be produced from your code. Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
>>>>
>>>> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
>>>
>>> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
>>
>> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
>>
>> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
>
> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
>
> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I haven't mesaured, but I would imagine '"setksmps 1" when doing DSP
code in a UDO to have additional overhead compared to computing
sample-by-sample in blocks.  Since you are implementing the
sample-by-sample code yourself, you can do the block code using a
while-loop, such as in:

https://github.com/kunstmusik/libsyi/blob/master/zdf.udo#L63-L103
https://github.com/kunstmusik/libsyi/blob/master/tdf2.udo

The code using a loop ends up looking similar to what you'd write in C
to fill up an asig variable.


On Wed, Aug 15, 2018 at 5:33 PM Mauro Giubileo
 wrote:
>
> I think that in many cases the speed increase would be much more bigger than twice. For example, from my experiments, if I use a Csound implementation of the biquad opcode instead of the native one, the performance decreases dramatically... Tens and tens of times slower... Maybe it's my Csound implementation that is wrong, so here it is my biquad udo:
>
> opcode mybiquad, a, akkkkkk
>     aXn, kb0, kb1, kb2, ka0, ka1, ka2 xin
>             setksmps 1
>
>     kXn_1   init    0 ; x[n-1]
>     kXn_2   init    0 ; x[n-2]
>     kYn_1   init    0 ; y[n-1]
>     kYn_2   init    0 ; y[n-2]
>
>     ; a0*y(n) + a1*y[n-1] + a2*y[n-2] = b0*x[n] + b1*x[n-1] + b2*x[n-2]
>     aYn     =       (kb0*aXn + kb1*kXn_1 + kb2*kXn_2 - ka1*kYn_1 - ka2*kYn_2) / ka0
>
>     ; let's prepare for next iteration:
>     kXn_2   =       kXn_1
>     kXn_1   =       aXn[0]
>     kYn_2   =       kYn_1
>     kYn_1   =       aYn[0]
>
>             xout    aYn
> endop
>
>
>
> In my experience the above code is incredibly slower than the native biquad opcode (if the global ksmps=256 it's about 20 times slower!), so, either there is something that is horribly wrong in my implementation, or the Csound tree traversal is much slower than a true native execution (and, consequently, a Csound scripts would greatly benefit from a full compilation in a binary executable).
>
> Regards,
> Mauro
>
>
> Il 2018-08-15 19:43 Michael Gogins ha scritto:
>
> Based on a variety of experiments I've performed over the years, Csound is doing all but the last steps a real computer would do, yes. But in addition to compiling there is optimization and linking, including link time optimization. I think replacing the existing steps after csoundCompileTree with compilation to machine language using LLVM with LTO could double the speed of Csound. Maybe.
>
> On Wed, Aug 15, 2018, 12:55 Forrest Curo  wrote:
>>
>> If each built-in 'opcode' is a chunk of optimized code, & the 'program' that gets interpreted by a csound instance is a string of these... probably we're not very far from something a compiler would produce; we just aren't saving it in that form because we're already running extremely close to what a compiled executable would do in practice, & getting it from a general-purpose piece of software.
>> (?)
>>
>> Forrest
>> San Diego
>>
>> On Wed, Aug 15, 2018 at 9:49 AM, Mauro Giubileo  wrote:
>>>
>>> I think, in your case (waiting hours to produce a WAV file from a csd file) you used Csound as an "offline renderer", not as a "compiler". The output of a compiler should be an intermediate object code or an executable file... But a WAV file it is neither one nor the other. :-)
>>>
>>> Regards,
>>> Mauro
>>>
>>>
>>> Il 2018-08-15 17:09 Brian Redfern ha scritto:
>>>
>>> Now that csound can run in realtime even on phones it is more helpful to think of it as an interpreter but back in the late 90s running a Mac os9 machine with 24 Meg's of RAM it was a compiler you sometimes waited hours for a WAV file to be produced from your code. Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
>>>
>>> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
>>
>> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
>
> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
>
> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I tried that too. Actually, from my experiments, the while-loop version is a little slower than the 'setksmps=1' one. This is the version with the while-loop:

opcode mybiquad, a, akkkkkk
    aXn, kb0, kb1, kb2, ka0, ka1, ka2 xin
    
    kXn_1   init    0 ; x[n-1]
    kXn_2   init    0 ; x[n-2]
    kYn_1   init    0 ; y[n-1]
    kYn_2   init    0 ; y[n-2]
    kn      =       0
    
    while (kn < ksmps) do
        ; a0 * y(n) + a1 * y[n-1] + a2 * y[n-2] = b0 * x[n] + b1 * x[n-1] + b2 * x[n-2]
        kXn     =   aXn[kn]
        kYn     =   (kb0 * kXn + kb1 * kXn_1 + kb2 * kXn_2 - ka1 * kYn_1 - ka2 * kYn_2) / ka0
        aYn[kn] =   kYn
        ; let's prepare for next iteration:
        kXn_2   =   kXn_1
        kXn_1   =   kXn
        kYn_2   =   kYn_1
        kYn_1   =   kYn
        kn      +=  1
    od
        
            xout    aYn
endop

Anyway they are both much slower than the native version.

Regards,
Mauro

Il 2018-08-19 20:06 Steven Yi ha scritto:

I haven't mesaured, but I would imagine '"setksmps 1" when doing DSP
code in a UDO to have additional overhead compared to computing
sample-by-sample in blocks.  Since you are implementing the
sample-by-sample code yourself, you can do the block code using a
while-loop, such as in:

https://github.com/kunstmusik/libsyi/blob/master/zdf.udo#L63-L103
https://github.com/kunstmusik/libsyi/blob/master/tdf2.udo

The code using a loop ends up looking similar to what you'd write in C
to fill up an asig variable.


On Wed, Aug 15, 2018 at 5:33 PM Mauro Giubileo
<mgiubileo@computeraltafed.it> wrote:

I think that in many cases the speed increase would be much more bigger than twice. For example, from my experiments, if I use a Csound implementation of the biquad opcode instead of the native one, the performance decreases dramatically... Tens and tens of times slower... Maybe it's my Csound implementation that is wrong, so here it is my biquad udo:

opcode mybiquad, a, akkkkkk
    aXn, kb0, kb1, kb2, ka0, ka1, ka2 xin
            setksmps 1

    kXn_1   init    0 ; x[n-1]
    kXn_2   init    0 ; x[n-2]
    kYn_1   init    0 ; y[n-1]
    kYn_2   init    0 ; y[n-2]

    ; a0*y(n) + a1*y[n-1] + a2*y[n-2] = b0*x[n] + b1*x[n-1] + b2*x[n-2]
    aYn     =       (kb0*aXn + kb1*kXn_1 + kb2*kXn_2 - ka1*kYn_1 - ka2*kYn_2) / ka0

    ; let's prepare for next iteration:
    kXn_2   =       kXn_1
    kXn_1   =       aXn[0]
    kYn_2   =       kYn_1
    kYn_1   =       aYn[0]

            xout    aYn
endop



In my experience the above code is incredibly slower than the native biquad opcode (if the global ksmps=256 it's about 20 times slower!), so, either there is something that is horribly wrong in my implementation, or the Csound tree traversal is much slower than a true native execution (and, consequently, a Csound scripts would greatly benefit from a full compilation in a binary executable).

Regards,
Mauro


Il 2018-08-15 19:43 Michael Gogins ha scritto:

Based on a variety of experiments I've performed over the years, Csound is doing all but the last steps a real computer would do, yes. But in addition to compiling there is optimization and linking, including link time optimization. I think replacing the existing steps after csoundCompileTree with compilation to machine language using LLVM with LTO could double the speed of Csound. Maybe.

On Wed, Aug 15, 2018, 12:55 Forrest Curo <treegestalt@gmail.com> wrote:

If each built-in 'opcode' is a chunk of optimized code, & the 'program' that gets interpreted by a csound instance is a string of these... probably we're not very far from something a compiler would produce; we just aren't saving it in that form because we're already running extremely close to what a compiled executable would do in practice, & getting it from a general-purpose piece of software.
(?)

Forrest
San Diego

On Wed, Aug 15, 2018 at 9:49 AM, Mauro Giubileo <mgiubileo@computeraltafed.it> wrote:

I think, in your case (waiting hours to produce a WAV file from a csd file) you used Csound as an "offline renderer", not as a "compiler". The output of a compiler should be an intermediate object code or an executable file... But a WAV file it is neither one nor the other. :-)

Regards,
Mauro


Il 2018-08-15 17:09 Brian Redfern ha scritto:

Now that csound can run in realtime even on phones it is more helpful to think of it as an interpreter but back in the late 90s running a Mac os9 machine with 24 Meg's of RAM it was a compiler you sometimes waited hours for a WAV file to be produced from your code. Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Interesting, suppose it's time to profile to see if there's anything
that could be done to improve the speed. Seems like we should be able
to do better than 10-20x slower than native.
On Sun, Aug 19, 2018 at 3:01 PM Mauro Giubileo
 wrote:
>
> I tried that too. Actually, from my experiments, the while-loop version is a little slower than the 'setksmps=1' one. This is the version with the while-loop:
>
> opcode mybiquad, a, akkkkkk
>     aXn, kb0, kb1, kb2, ka0, ka1, ka2 xin
>
>     kXn_1   init    0 ; x[n-1]
>     kXn_2   init    0 ; x[n-2]
>     kYn_1   init    0 ; y[n-1]
>     kYn_2   init    0 ; y[n-2]
>     kn      =       0
>
>     while (kn < ksmps) do
>         ; a0 * y(n) + a1 * y[n-1] + a2 * y[n-2] = b0 * x[n] + b1 * x[n-1] + b2 * x[n-2]
>         kXn     =   aXn[kn]
>         kYn     =   (kb0 * kXn + kb1 * kXn_1 + kb2 * kXn_2 - ka1 * kYn_1 - ka2 * kYn_2) / ka0
>         aYn[kn] =   kYn
>         ; let's prepare for next iteration:
>         kXn_2   =   kXn_1
>         kXn_1   =   kXn
>         kYn_2   =   kYn_1
>         kYn_1   =   kYn
>         kn      +=  1
>     od
>
>             xout    aYn
> endop
>
>
> Anyway they are both much slower than the native version.
>
> Regards,
> Mauro
>
>
>
>
> Il 2018-08-19 20:06 Steven Yi ha scritto:
>
> I haven't mesaured, but I would imagine '"setksmps 1" when doing DSP
> code in a UDO to have additional overhead compared to computing
> sample-by-sample in blocks.  Since you are implementing the
> sample-by-sample code yourself, you can do the block code using a
> while-loop, such as in:
>
> https://github.com/kunstmusik/libsyi/blob/master/zdf.udo#L63-L103
> https://github.com/kunstmusik/libsyi/blob/master/tdf2.udo
>
> The code using a loop ends up looking similar to what you'd write in C
> to fill up an asig variable.
>
>
> On Wed, Aug 15, 2018 at 5:33 PM Mauro Giubileo
>  wrote:
>
>
> I think that in many cases the speed increase would be much more bigger than twice. For example, from my experiments, if I use a Csound implementation of the biquad opcode instead of the native one, the performance decreases dramatically... Tens and tens of times slower... Maybe it's my Csound implementation that is wrong, so here it is my biquad udo:
>
> opcode mybiquad, a, akkkkkk
>     aXn, kb0, kb1, kb2, ka0, ka1, ka2 xin
>             setksmps 1
>
>     kXn_1   init    0 ; x[n-1]
>     kXn_2   init    0 ; x[n-2]
>     kYn_1   init    0 ; y[n-1]
>     kYn_2   init    0 ; y[n-2]
>
>     ; a0*y(n) + a1*y[n-1] + a2*y[n-2] = b0*x[n] + b1*x[n-1] + b2*x[n-2]
>     aYn     =       (kb0*aXn + kb1*kXn_1 + kb2*kXn_2 - ka1*kYn_1 - ka2*kYn_2) / ka0
>
>     ; let's prepare for next iteration:
>     kXn_2   =       kXn_1
>     kXn_1   =       aXn[0]
>     kYn_2   =       kYn_1
>     kYn_1   =       aYn[0]
>
>             xout    aYn
> endop
>
>
>
> In my experience the above code is incredibly slower than the native biquad opcode (if the global ksmps=256 it's about 20 times slower!), so, either there is something that is horribly wrong in my implementation, or the Csound tree traversal is much slower than a true native execution (and, consequently, a Csound scripts would greatly benefit from a full compilation in a binary executable).
>
> Regards,
> Mauro
>
>
> Il 2018-08-15 19:43 Michael Gogins ha scritto:
>
> Based on a variety of experiments I've performed over the years, Csound is doing all but the last steps a real computer would do, yes. But in addition to compiling there is optimization and linking, including link time optimization. I think replacing the existing steps after csoundCompileTree with compilation to machine language using LLVM with LTO could double the speed of Csound. Maybe.
>
> On Wed, Aug 15, 2018, 12:55 Forrest Curo  wrote:
>
>
> If each built-in 'opcode' is a chunk of optimized code, & the 'program' that gets interpreted by a csound instance is a string of these... probably we're not very far from something a compiler would produce; we just aren't saving it in that form because we're already running extremely close to what a compiled executable would do in practice, & getting it from a general-purpose piece of software.
> (?)
>
> Forrest
> San Diego
>
> On Wed, Aug 15, 2018 at 9:49 AM, Mauro Giubileo  wrote:
>
>
> I think, in your case (waiting hours to produce a WAV file from a csd file) you used Csound as an "offline renderer", not as a "compiler". The output of a compiler should be an intermediate object code or an executable file... But a WAV file it is neither one nor the other. :-)
>
> Regards,
> Mauro
>
>
> Il 2018-08-15 17:09 Brian Redfern ha scritto:
>
> Now that csound can run in realtime even on phones it is more helpful to think of it as an interpreter but back in the late 90s running a Mac os9 machine with 24 Meg's of RAM it was a compiler you sometimes waited hours for a WAV file to be produced from your code. Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
>
> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
>
>
> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
>
>
> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
>
> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
>
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>
> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I don't know if it's technically possible achieve performances similar to those of a native opcode execution without Just-In-Time compiling techniques. In fact, it could be very nice if the UDOs were JIT-compiled at run-time just before the execution of the score. I'm sure that this could improve very much the execution of pieces of code that need sample-by-sample computation when there isn't a native opcode that does what you want. Another thing that I think could give a nice boost to the UDOs execution is the passage of parameters by reference. I think recursion techniques would benefit much from this.

It would be even better if, from a csd file, Csound could generate an executable binary file optimized to achieve maximum execution speed. In this way it could be defined as a true compiler, without a doubt. Then the UDOs would really become optimized machine code procedures, not chained lists of pointers to routines and data structures.

Or maybe Csound could do the same thing as Faust: translate the Csound code in a C/C++ code that you can compile to generate an optimized executable binary.

Anyway, I wanted to try JIT-compiling something in Csound with the various Faust opcodes, but I'm on Windows, and on this platform actually there are some troubles in compiling the Faust library. To be honest, on Windows I'm having trouble to compile the Csound sources too! :-D

Best Regards,
Mauro

Il 2018-08-20 04:52 Steven Yi ha scritto:

Interesting, suppose it's time to profile to see if there's anything
that could be done to improve the speed. Seems like we should be able
to do better than 10-20x slower than native.
On Sun, Aug 19, 2018 at 3:01 PM Mauro Giubileo
<mgiubileo@computeraltafed.it> wrote:

I tried that too. Actually, from my experiments, the while-loop version is a little slower than the 'setksmps=1' one. This is the version with the while-loop:

opcode mybiquad, a, akkkkkk
    aXn, kb0, kb1, kb2, ka0, ka1, ka2 xin

    kXn_1   init    0 ; x[n-1]
    kXn_2   init    0 ; x[n-2]
    kYn_1   init    0 ; y[n-1]
    kYn_2   init    0 ; y[n-2]
    kn      =       0

    while (kn < ksmps) do
        ; a0 * y(n) + a1 * y[n-1] + a2 * y[n-2] = b0 * x[n] + b1 * x[n-1] + b2 * x[n-2]
        kXn     =   aXn[kn]
        kYn     =   (kb0 * kXn + kb1 * kXn_1 + kb2 * kXn_2 - ka1 * kYn_1 - ka2 * kYn_2) / ka0
        aYn[kn] =   kYn
        ; let's prepare for next iteration:
        kXn_2   =   kXn_1
        kXn_1   =   kXn
        kYn_2   =   kYn_1
        kYn_1   =   kYn
        kn      +=  1
    od

            xout    aYn
endop


Anyway they are both much slower than the native version.

Regards,
Mauro




Il 2018-08-19 20:06 Steven Yi ha scritto:

I haven't mesaured, but I would imagine '"setksmps 1" when doing DSP
code in a UDO to have additional overhead compared to computing
sample-by-sample in blocks.  Since you are implementing the
sample-by-sample code yourself, you can do the block code using a
while-loop, such as in:

https://github.com/kunstmusik/libsyi/blob/master/zdf.udo#L63-L103
https://github.com/kunstmusik/libsyi/blob/master/tdf2.udo

The code using a loop ends up looking similar to what you'd write in C
to fill up an asig variable.


On Wed, Aug 15, 2018 at 5:33 PM Mauro Giubileo
<mgiubileo@computeraltafed.it> wrote:


I think that in many cases the speed increase would be much more bigger than twice. For example, from my experiments, if I use a Csound implementation of the biquad opcode instead of the native one, the performance decreases dramatically... Tens and tens of times slower... Maybe it's my Csound implementation that is wrong, so here it is my biquad udo:

opcode mybiquad, a, akkkkkk
    aXn, kb0, kb1, kb2, ka0, ka1, ka2 xin
            setksmps 1

    kXn_1   init    0 ; x[n-1]
    kXn_2   init    0 ; x[n-2]
    kYn_1   init    0 ; y[n-1]
    kYn_2   init    0 ; y[n-2]

    ; a0*y(n) + a1*y[n-1] + a2*y[n-2] = b0*x[n] + b1*x[n-1] + b2*x[n-2]
    aYn     =       (kb0*aXn + kb1*kXn_1 + kb2*kXn_2 - ka1*kYn_1 - ka2*kYn_2) / ka0

    ; let's prepare for next iteration:
    kXn_2   =       kXn_1
    kXn_1   =       aXn[0]
    kYn_2   =       kYn_1
    kYn_1   =       aYn[0]

            xout    aYn
endop



In my experience the above code is incredibly slower than the native biquad opcode (if the global ksmps=256 it's about 20 times slower!), so, either there is something that is horribly wrong in my implementation, or the Csound tree traversal is much slower than a true native execution (and, consequently, a Csound scripts would greatly benefit from a full compilation in a binary executable).

Regards,
Mauro


Il 2018-08-15 19:43 Michael Gogins ha scritto:

Based on a variety of experiments I've performed over the years, Csound is doing all but the last steps a real computer would do, yes. But in addition to compiling there is optimization and linking, including link time optimization. I think replacing the existing steps after csoundCompileTree with compilation to machine language using LLVM with LTO could double the speed of Csound. Maybe.

On Wed, Aug 15, 2018, 12:55 Forrest Curo <treegestalt@gmail.com> wrote:


If each built-in 'opcode' is a chunk of optimized code, & the 'program' that gets interpreted by a csound instance is a string of these... probably we're not very far from something a compiler would produce; we just aren't saving it in that form because we're already running extremely close to what a compiled executable would do in practice, & getting it from a general-purpose piece of software.
(?)

Forrest
San Diego

On Wed, Aug 15, 2018 at 9:49 AM, Mauro Giubileo <mgiubileo@computeraltafed.it> wrote:


I think, in your case (waiting hours to produce a WAV file from a csd file) you used Csound as an "offline renderer", not as a "compiler". The output of a compiler should be an intermediate object code or an executable file... But a WAV file it is neither one nor the other. :-)

Regards,
Mauro


Il 2018-08-15 17:09 Brian Redfern ha scritto:

Now that csound can run in realtime even on phones it is more helpful to think of it as an interpreter but back in the late 90s running a Mac os9 machine with 24 Meg's of RAM it was a compiler you sometimes waited hours for a WAV file to be produced from your code. Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here


Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here


Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here