LISTSERV mailing list manager LISTSERV 16.5

Help for CSOUND Archives


CSOUND Archives

CSOUND Archives


CSOUND@LISTSERV.HEANET.IE


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Monospaced Font

LISTSERV Archives

LISTSERV Archives

CSOUND Home

CSOUND Home

CSOUND  August 2018

CSOUND August 2018

Subject:

Re: Csound is a compiler?

From:

Michael Gogins <[log in to unmask]>

Reply-To:

A discussion list for users of Csound <[log in to unmask]>

Date:

Wed, 15 Aug 2018 10:46:03 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (137 lines)

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
<[log in to unmask]> 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
> <[log in to unmask]> 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 [log in to unmask] 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
> [log in to unmask]
> 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 [log in to unmask] 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
[log in to unmask]
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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015

ATOM RSS1 RSS2



LISTSERV.HEANET.IE

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager