updating content

content.tex

@@ -1,7 +1,7 @@
 \section{Introduction}\label{introduction}
 
-Programming languages and environments for music such as Max, Pure Data,
-CSound, and SuperCollider has been referred to as ``Computer Music
+Programming languages and environments for music, for instance, Max, Pure Data,
+Csound, and SuperCollider, has been referred to as ``Computer Music
 Language''\citep{McCartney2002, Nishino2016, McPherson2020}, ``Language
 for Computer Music''\citep{Dannenberg2018}, and ``Computer Music
 Programming Systems''\citep{Lazzarini2013}, though there is no clear
@@ -9,7 +9,7 @@ consensus on the use of these terms. However, as the shared term
 ``Computer Music'' implies, these programming languages are deeply
 intertwined with the history of technology-driven music, which developed
 under the premise that ``almost any sound can be
-produced''\citep{mathews_acoustic_1961} through the use of computers.
+produced''\citep[p557]{mathews1963} through the use of computers.
 
 In the early days, when computers existed only in research laboratories
 and neither displays nor mice existed, creating sound or music with
@@ -26,9 +26,7 @@ and the various constraints required for real-time audio processing have
 significantly increased the specialized knowledge necessary for
 developing programming languages for music today. Furthermore, some
 languages developed after the 2000s are not necessarily aimed at
-pursuing new forms of musical expression. It seems that there is still
-no unified perspective on how the value of such languages should be
-evaluated.
+pursuing new forms of musical expression. There is still no unified perspective on how the value of those languages should be evaluated.
 
 In this paper, a critical historical review is conducted by drawing on
 discussions from sound studies alongside existing surveys, aiming to
@@ -44,7 +42,7 @@ framework tied to specific styles or communities, as represented in
 Ostertag's \emph{Why Computer Music Sucks}\citep{ostertag1998} since the
 1990s.
 
-As Lyon observed nearly two decades ago, it is now nearly impossible to
+As Eric Lyon observed nearly two decades ago, it is now nearly impossible to
 imagine a situation in which computers are not involved at any stage
 from the production to experience of music\citep[p1]{lyon_we_2006}. The
 necessity of using the term ``Computer Music'' to describe academic
@@ -125,12 +123,10 @@ The MUSIC I (1957) in Bell Labs\citep{Mathews1980} and succeeding
 MUSIC-N family are highlighted as the earliest examples of computer
 music research. However, attempts to create music with computers in the
 UK and Australia prior to MUSIC have also been
-documented\citep{doornbusch2017}. Organizing what was achieved by
-MUSIC-N and earlier efforts can help clarify definitions of computer
-music.
+documented\citep{doornbusch2017}.
 
 The earliest experiments with sound generation on computers in the 1950s
-involved controlling the intervals between one-bit pulses (on or off) to
+involved controlling the intervals of one-bit pulses to
 control pitch. This was partly because the operational clock frequencies
 of early computers fell within the audible range, making the
 sonification of electrical signals a practical and cost-effective
@@ -223,7 +219,7 @@ was not simply that it was developed early, but because it was the first
 to implement, but because it was the first to implement sound
 representation on a computer based on \textbf{pulse-code modulation
 (PCM)}, which theoretically can generate ``almost any
-sound''\citep[p557]{mathews1963}
+sound''.
 
 PCM, the foundational digital sound representation today, involves
 sampling audio waveforms at discrete intervals and quantizing the sound
@@ -268,7 +264,7 @@ noise from it. Sampling theory builds on this premise through Shannon's
 information theory by statistically modeling human auditory
 characteristics: it assumes that humans cannot discern volume
 differences below certain thresholds or perceive vibrations outside
-specific frequency ranges. By limiting representation to this range,
+specific frequency ranges. By limiting representation to the reconizable range,
 sampling theory ensures that all audible sounds can be effectively
 encoded.
 
@@ -282,16 +278,14 @@ ring modulation (RM), amplitude modulation (AM), or distortion often
 generate aliasing artifacts unless proper oversampling is applied. These
 artifacts occur because PCM, while universally suitable for reproducing
 recorded sound, is not inherently versatile as a medium for generating
-new sounds. As Puckette has argued, alternative representations, such as
-collections of linear segments or physical modeling synthesis, offer
+new sounds. As Puckette has argued, alternative representations, for instance, representation by a sequence of linear segments or physical modeling synthesis, offer
 other possibilities\citep{puckette2015}. Therefore, PCM is not a
 completely universal tool for creating sound.
 
 \section{What Does the Unit Generator
 Hide?}\label{what-does-the-unit-generator-hide}
 
-Beginning with version III, MUSIC took the form of an acoustic compiler
-(block diagram compiler) that processes two input sources: a score
+Beginning with version III, MUSIC took the form of a block diagram compiler that processes two input sources: a score
 language, which represents a list of time-varying parameters, and an
 orchestra language, which describes the connections between \textbf{Unit
 Generators} such as oscillators and filters. In this paper, the term
@@ -307,7 +301,7 @@ domain-specific languages. Mathews explained that he developed a
 compiler for MUSIC III in response to requests from many composers for
 additional features in MUSIC II, such as envelopes and vibrato, while
 also ensuring that the program would not be restricted to a specialized
-form of musical expression (Max V. Mathews 2007, 13:10-17:50). He
+form of musical expression\citep[13:10-17:50]{mathews_max_2007}. He
 repeatedly stated that his role was that of a scientist rather than a
 musician:
 
@@ -338,8 +332,8 @@ One notable but often overlooked example is MUSIGOL, a derivative of
 MUSIC IV \citep{innis_sound_1968}. In MUSIGOL, not only was the system
 itself but even the score and orchestra defined by user were written
 entirely as ALGOL 60 language. Similar to today's Processing or Arduino,
-MUSIGOL is one of the earliest examples of a programming language for
-music implemented as an internal DSL (DSL as a library)\footnote{While
+MUSIGOL is one of the earliest internal DSL (Domain-specific languages) for
+music, which means implemented as an library \footnote{While
   MUS10, used at Stanford University, was not an internal DSL, it was
   created by modifying an existing ALGOL parser \citep[p.248]{loy1985}.}.
 (Therefore, according to the definition of Unit Generator provided in
@@ -377,14 +371,14 @@ characteristics\footnote{It is said that a preprocessing feature called
   \citep[p77]{mathews_technology_1969}.}, and they also had to account
 for at least two sample memory spaces.
 
-On the other hand, in later MUSIC 11, and its successor CSound by Barry
+On the other hand, in later MUSIC 11, and its successor Csound by Barry
 Vercoe, the band-pass filter is defined as a Unit Generator (UGen) named
 \passthrough{\lstinline!reson!}. This UGen takes four parameters: the
 input signal, center cutoff frequency, bandwidth, and Q
 factor\citep[p248]{vercoe_computer_1983}. Unlike previous
 implementations, users no longer need to calculate coefficients
 manually, nor do they need to be aware of the two-sample memory space.
-However, in MUSIC 11 and CSound, it is possible to implement this
+However, in MUSIC 11 and Csound, it is possible to implement this
 band-pass filter from scratch as a User-Defined Opcode (UDO) as shownin
 Listing \ref{lst:reson}. Vercoe emphasized that while signal processing
 primitives should allow for low-level operations, such as single-sample
@@ -423,10 +417,10 @@ Generator paradigm, such as Pure Data \citep{puckette_pure_1997}, Max
 MSP), SuperCollider \citep{mccartney_supercollider_1996}, and ChucK
 \citep{wang_chuck_2015}, primitive UGens are implemented in
 general-purpose languages like C or C++\footnote{ChucK later introduced
-  ChuGen, which is similar extension to CSound's UDO, allowing users to
+  ChuGen, which is similar extension to Csound's UDO, allowing users to
   define UGens within the ChucK language itself \citep{Salazar2012}.
   However, not all existing UGens are replaced by UDOs by default both
-  in CSound and ChucK, which remain supplemental features possibly
+  in Csound and ChucK, which remain supplemental features possibly
   because the runtime performance of UDO is inferior to natively
   implemented UGens.}. If users wish to define low-level UGens (called
 external objects in Max and Pd), they need to set up a development
@@ -569,8 +563,8 @@ example is \textbf{Extempore}, a live programming environment developed
 by Sorensen \citep{sorensen_extempore_2018}. Extempore consists of
 Scheme, a LISP-based language, and xtlang, a meta-implementation on top
 of Scheme. While xtlang requires users to write hardware-oriented type
-signatures similar to those in C, it leverages the LLVM compiler
-infrastructure \citep{Lattner} to just-in-time (JIT) compile signal
+signatures similar to those in C, it leverages the LLVM\citep{Lattner}, the compiler
+infrastructure to just-in-time (JIT) compile signal
 processing code, including sound manipulation, into machine code for
 high-speed execution.
 
@@ -592,7 +586,7 @@ processing while exploring interactive meta-operations on programs
 interoperability with other general-purpose languages
 \citep{matsuura_lambda-mmm_2024}.
 
-Domain-specific languages (DSLs) are constructed within a double bind:
+DSLs are constructed within a double bind:
 they aim to specialize in a particular purpose while still providing a
 certain degree of expressive freedom through coding. In this context,
 efforts like Extempore, Kronos, and mimium are not merely programming