reduced pages

content.tex

@@ -50,8 +50,7 @@ As 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 production to experience of music\citep[p1]{lyon_we_2006}. The
 necessity of using the term ``Computer Music'' to describe academic
-contexts, particularly those centered around the ICMC, has consequently
-diminished.
+contexts has consequently diminished.
 
 Holbrook and Rudi continued Lyon's discussion by proposing the use of
 frameworks like Post-Acousmatic\citep{adkins2016} to redefine ``Computer
@@ -70,14 +69,9 @@ musical expressions, it simultaneously marginalizes much of the music
 that is ``just using computers'' and fails to provide insights into this
 divided landscape.
 
-Lyon argues that defining computer music simply as music created with
-computers is too permissive, while defining it as music that could not
-exist without computers is too strict. He highlights the difficulty of
-considering instruments that use digital simulations, such as virtual
-analog synthesizers, within these definitions. Furthermore, he suggests
-that the term ``computer music'' is style-agnostic definition almost
-like ``piano music,'' implying that it ignores the style and form inside
-music produced by the instruments.
+Lyon argues that the term ``computer music'' is style-agnostic
+definition almost like ``piano music,'' implying that it ignores the
+style and form inside music produced by the instruments.
 
 However, one of the defining characteristics of computers as a medium
 lies in their ability to treat musical styles themselves as subjects of
@@ -88,17 +82,10 @@ particular musical culture. This recursive embedding of the language and
 perception constituting that musical culture into the resulting music is
 a process that goes beyond what is possible with acoustic instruments or
 analog electronic instruments. Magnusson refers to this characteristic
-of digital instruments as ``Epistemic Tools'' and points out that they
-tend to work in the direction of reinforcing and solidifying musical
-culture:
-
-\begin{quote}
-The act of formalising is therefore always an act of fossilisation. As
-opposed to the acoustic instrument maker, the designer of the composed
-digital instrument frames affordances through symbolic design, thereby
-creating a snapshot of musical theory, freezing musical culture in time.
-\citep[p173]{Magnusson2009}
-\end{quote}
+of digital instruments as ``Epistemic Tools'' and points out that the
+computer works as ``creating a snapshot of musical theory, freezing
+musical culture in time''\citep[p173]{Magnusson2009} through
+formalization.
 
 Today, many people use computers for music production not because they
 consciously leverage the uniqueness of the meta-medium, but simply
@@ -116,23 +103,15 @@ reexamined with an approach that, opposite from Lyon, takes an extremely
 style-agnostic perspective. Rather than focusing on what has been
 created with these tools, the emphasis is placed on how these tools
 themselves have been constructed. The paper centers on the following two
-topics:
-
-\begin{enumerate}
-\def\labelenumi{\arabic{enumi}.}
-\tightlist
-\item
-  A critique of the universality of sound representation using
-  pulse-code modulation (PCM), the foundational concept underlying most
-  of today's sound programming, by referencing early attempts of sound
-  generation using electronic computers.
-\item
-  An examination of the MUSIC-N family, the origin of PCM-based sound
-  synthesis, to highlight that its design varies significantly across
-  systems from the perspective of modern programming language design and
-  that it has evolved over time into a black box, eliminating the need
-  for users to understand its internal workings.
-\end{enumerate}
+topics: 1. A critique of the universality of sound representation using
+pulse-code modulation (PCM), the foundational concept underlying most of
+today's sound programming, by referencing early attempts of sound
+generation using electronic computers. 2. An examination of the MUSIC-N
+family, the origin of PCM-based sound programming, to highlight that its
+design varies significantly across systems from the perspective of
+today's programming language design and that it has evolved over time
+into a black box, eliminating the need for users to understand its
+internal workings.
 
 Ultimately, the paper concludes that programming languages for music
 developed since the 2000s are not solely aimed at creating new music but
@@ -144,10 +123,10 @@ of music created with computers.
 \section{PCM and Early Computer
 Music}\label{pcm-and-early-computer-music}
 
-Among the earliest examples of computer music research, the MUSIC I
-system (1957) from Bell Labs and its derivatives, known as MUSIC-N, are
-frequently highlighted. However, attempts to create music with computers
-in the UK and Australia prior to MUSIC I have also been
+Usually 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.
@@ -158,25 +137,24 @@ 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
 debugging method compared to visualizing them on displays or
-oscilloscopes. Some computers at this time like Australia's CSIR Mark I
-(CSIRAC) often had ``hoot'' primitive instructions that emit a single
+oscilloscopes. Some computers at this time like CSIR Mark I (CSIRAC) in
+Australia often had ``hoot'' primitive instructions that emit a single
 pulse to a speaker.
 
 In 1949, the background to music played on the BINAC in UK involved
 engineer Louis Wilson, who noticed that an AM radio placed nearby could
 pick up weak electromagnetic waves generated during the switching of
-vacuum tubes, producing regular sounds. He leveraged this phenomenon by
-connecting a speaker and a power amplifier to the computer's output,
-using the setup to assist in debugging processes. Frances Elizabeth
-Holberton took this a step further by programming the computer to
-generate pulses at arbitrary intervals, creating melodies
-\citep{woltman1990}. The sound generation on BINAC and CSIR Mark I
-represents early instances of using computers to play melodies from
-existing music.
+vacuum tubes, producing sounds. He leveraged this phenomenon by
+connecting a speaker and a power amplifier to the computer's circuit, to
+assist debugging. Frances Elizabeth Holberton took this a step further
+by programming the computer to generate pulses at desired intervals,
+creating melodies \citep{woltman1990}. The early sound generation using
+computer were mostly playing melodies of existing music. represented by
+BINAC and CSIR Mark.
 
-However, not all sound generation at this timewas merely the
+However, not all sound generation at this time was merely the
 reproduction of existing music. Doornbusch highlights experiments on the
-British Pilot ACE (Prototype for Automatic Computing Engine: ACE), which
+British Pilot ACE (Prototype for Automatic Computing Engine), which
 utilized acoustic delay line memory to produce unique
 sounds\citep[p303-304]{doornbusch2017}. Acoustic delay line memory, used
 as main memory in early computers like BINAC and CSIR Mark I, employed
@@ -193,38 +171,28 @@ intentional part in choosing the notes. The music was very interesting,
 though atonal, and began by playing rising arpeggios: these gradually
 became more complex and faster, like a developing fugue. They dissolved
 into colored noise as the complexity went beyond human understanding.
-
-Loops were always multiples of 32 microseconds long, so notes had
-frequencies which were submultiples of 31.25 KHz. The music was based on
-a very strange scale, which was nothing like equal tempered or harmonic,
-but was quite pleasant.
 \end{quote}
 
 This music arose unintentionally during program optimization and was
-made possible by ``misusing'' switches installed for debugging acoustic
-delay line memory (p20). Media scholar Miyazaki described the practice
-of listening to sounds generated by algorithms and their bit patterns,
-integrated into programming and debugging, as ``Algo\emph{rhythmic}
+made possible by ``misusing'' switches installed for debugging delay
+line memory. Media scholar Miyazaki described the practice of listening
+to sounds generated by algorithms and their bit patterns, integrated
+into programming, as ``Algo- \emph{rhythmic}
 Listening''\citep{miyazaki2012}.
 
-Doornbusch warns against ignoring early computer music practices in
-Australia and the UK simply because they did not directly influence
-subsequent research\citep[p305]{doornbusch2017}. Indeed, the tendency to
-treat pre-MUSIC attempts as hobbyist efforts by engineers and post-MUSIC
-endeavors as ``serious'' research remains common even
-today\citep{tanaka_all_2017}.
-
-The sounds produced by the Pilot ACE challenge the post-acousmatic
-historical narrative, which suggests that computer music transitioned
-from being confined to specialized laboratories to becoming accessible
-to individuals, including amateurs.
+Doornbusch warns against ignoring these early computer music practices
+simply because they did not directly influence subsequent
+research\citep[p305]{doornbusch2017}. Indeed, the sounds produced by the
+Pilot ACE challenge the post-acousmatic historical narrative, which
+suggests that computer music transitioned from being democratized from
+closed electro-acoustic music laboratories to individual musicians.
 
 This is because the sounds generated by the Pilot ACE were not created
 by musical experts, nor were they solely intended for debugging
 purposes. Instead, they were programmed with the goal of producing
 interesting sounds. Moreover, the sounds were tied to the hardware of
 the acoustic delay line memory---a feature that was likely difficult to
-replicate, even in modern audio programming environments.
+replicate, even in today's sound programming environments.
 
 Similarly, in the 1960s at MIT, Peter Samson took advantage of the
 debugging speaker on the TX-0, a machine that had become outdated and
@@ -235,17 +203,17 @@ evolved into the creation of a program that allowed melodies to be
 described using text strings within MIT.
 
 Building on this, Samson developed a program called the Harmony Compiler
-on the DEC PDP-1, which was derived from the TX-0. This program gained
+for the DEC PDP-1, which was derived from the TX-0. This program gained
 significant popularity among MIT students. Around 1972, Samson began
 surveying various digital synthesizers that were being developed at the
 time and went on to create a system specialized for computer music. The
 resulting Samson Box was used at Stanford University's CCRMA (Center for
 Computer Research in Music and Acoustics) for over a decade until the
 early 1990s and became a tool for many composers to create their works
-\citep{loy_life_2013}. Considering Samson's example, it is not
-appropriate to separate the early experiments in sound generation by
-computers from the history of computer music solely because their
-initial purpose was debugging.
+\citep{loy_life_2013}. Considering his example, it is not appropriate to
+separate the early experiments in sound generation by computers from the
+history of computer music solely because their initial purpose was
+debugging.
 
 \subsection{Acousmatic Listening, the premise of the Universality of
 PCM}\label{acousmatic-listening-the-premise-of-the-universality-of-pcm}
@@ -253,13 +221,12 @@ PCM}\label{acousmatic-listening-the-premise-of-the-universality-of-pcm}
 One of the reasons why MUSIC led to subsequent advancements in research
 was not simply because it was developed early, but because it was the
 first to implement sound representation on a computer based on
-\textbf{pulse-code modulation (PCM)}, which theoretically enables the
-representation of ``almost any sound.''
+\textbf{pulse-code modulation (PCM)}, which theoretically can generate
+``almost any sound''\citep[p557]{mathews1963}
 
-PCM, the foundational method of sound representation on today's
-computers, involves dividing audio waveforms into discrete intervals
-(sampling) and representing the sound pressure at each interval as
-discrete numerical values (quantization).
+PCM, the foundational sound representation on today's computers,
+involves sampling audio waveforms into discrete intervals and quantize
+the sound pressure at each interval as discrete numerical values.
 
 The issue with the universalism of PCM in the history of computer music
 is inherent in the concept of Acousmatic, which serves as a premise for
@@ -280,36 +247,33 @@ contrast\footnote{Sterne later critiques the phenomenological basis of
   assumptions\citep{sterne_diminished_2022}. Discussions of universality
   in computer music should also address ableism, as seen in the
   relationship between recording technologies and auditory disabilities.}.
-This implies that prior to the advent of recording technologies,
-listening was unmediated and holistic---a narrative that obscures the
-constructed nature of these assumptions.
+This implies that prior to the advent of sound reproduction
+technologies, listening was unmediated and holistic---a narrative that
+obscures the constructed nature of these assumptions.
 
 \begin{quote}
 For instance, the claim that sound reproduction has ``alienated'' the
 voice from the human body implies that the voice and the body existed in
 some prior holistic, unalienated, and self present relation.
-
-They assume that, at some time prior to the invention of sound
-reproduction technologies, the body was whole, undamaged, and
-phenomenologically coherent.\citep[p20-21]{sterne_audible_2003}
+\citep[p20-21]{sterne_audible_2003}
 \end{quote}
 
 The claim that PCM-based sound synthesis can produce ``almost any
-sound'' is underpinned by an ideology associated with recording
+sound'' is underpinned by an ideology associated with sound reproduction
 technologies. This ideology assumes that recorded sound contains an
 ``original'' source and that listeners can distinguish distortions or
-noise from it. Sampling theory builds on this premise 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, sampling theory ensures that all audible sounds can be
-effectively encoded.
+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,
+sampling theory ensures that all audible sounds can be effectively
+encoded.
 
 By the way, the actual implementation of PCM in MUSIC I only allowed for
-monophonic triangle waves with controllable volume, pitch, and timing
-(MUSIC II later expanded this to four oscillators)\citep{Mathews1980}.
-Would anyone today describe such a system as capable of producing
-``infinite variations'' in sound synthesis?
+monophonic triangle waves with controllable volume, pitch, and
+timing\citep{Mathews1980}. Would anyone today describe such a system as
+capable of producing ``infinite variations'' in sound synthesis?
 
 Even when considering more contemporary applications, processes like
 ring modulation (RM), amplitude modulation (AM), or distortion often
@@ -324,63 +288,57 @@ completely universal tool for creating sound.
 \section{What Does the Unit Generator
 Hide?}\label{what-does-the-unit-generator-hide}
 
-Starting with version III, MUSIC adopted the form of an acoustic
-compiler (or block diagram compiler) that takes two types of input: 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 ``Unit Generator'' means a signal processing module used by the
-user, where the internal implementation is either not open or
-implemented in a language different from the one used by the user.
+From with version III, MUSIC took the form of an acoustic compiler
+(block diagram compiler) that takes 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
+``Unit Generator'' means a signal processing modules where its
+implementation is either not open or written in a language different
+from the one used by the user.
 
-Beyond performing sound synthesis based on PCM, one of the defining
-features of the MUSIC family in the context of computer music research
-was the establishment of a division of labor between professional
-musicians and computer engineers through the development of
-domain-specific languages. Mathews explained that he developed a
-compiler for MUSIC III in response to requests for additional features
-such as envelopes and vibrato, while also ensuring that the program
-would not be fixed in a static form
-\citep[13:10-17:50]{mathews_max_2007}. He repeatedly stated that his
-role was that of a scientist rather than a musician:
+MUSIC family in the context of computer music research made success for
+performing sound synthesis based on PCM and (but) it came with the
+establishment of a division of labor between professional musicians and
+computer engineers through the development of domain-specific languages.
+Mathews explained that he developed a compiler for MUSIC III in response
+to requests for additional features for MUSIC II such as envelopes and
+vibrato by many composers, while also ensuring that the program would
+not be fixed in a specialized musical expression (Max V. Mathews 2007,
+13:10-17:50). He repeatedly stated that his role was that of a scientist
+rather than a musician:
 
 \begin{quote}
-The only answer I could see was not to make the instruments myself---not
-to impose my taste and ideas about instruments on the musicians---but
-rather to make a set of fairly universal building blocks and give the
-musician both the task and the freedom to put these together into his or
-her instruments. \citep[p16]{Mathews1980}\\
-(\ldots) When we first made these music programs the original users were
-not composers; they were the psychologist Guttman, John Pierce, and
-myself, who are fundamentally scientists. We wanted to have musicians
-try the system to see if they could learn the language and express
-themselves with it. So we looked for adventurous musicians and composers
-who were willing to experiment. (p17)
+When we first made these music programs the original users were not
+composers; they were the psychologist Guttman, John Pierce, and myself,
+who are fundamentally scientists. We wanted to have musicians try the
+system to see if they could learn the language and express themselves
+with it. So we looked for adventurous musicians and composers who were
+willing to experiment.\citep[p17]{Mathews1980}
 \end{quote}
 
 This clear delineation of roles between musicians and scientists became
 one of the defining characteristics of post-MUSIC computer music
-research. Paradoxically, the act of creating sounds never heard before
-using computers paved the way for research by allowing musicians to
-focus on their craft without needing to grapple with the complexities of
-programming.
+research. Paradoxically, the computer music research that desired
+creating sounds never heard before paved the way for research by
+allowing musicians to focus on their composition without knowing about
+cumbersome works of programming.
 
 \subsection{Example: Hiding First-Order Variables in Signal
 Processing}\label{example-hiding-first-order-variables-in-signal-processing}
 
-Although the MUSIC N series shares a common workflow of using a Score
-language and an Orchestra language, the actual implementation of each
+Although the MUSIC N series shares a common workflow of using a score
+language and an orchestra language, the actual implementation of each
 programming language varies significantly, even within the series.
 
-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 implemented differently, but even the user-written Score and
-Orchestra programs were written entirely as ALGOL 60 source code.
-Similar to modern frameworks like Processing or Arduino, MUSIGOL
-represents one of the earliest examples of a domain-specific language
-implemented as an internal DSL within a library\footnote{While MUS10,
-  used at Stanford University, was not an internal DSL, it was created
-  by modifying an existing ALGOL parser \citep[p248]{loy1985}.}.
+One notable but 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 by user programs were written entirely as
+ALGOL 60 language. Like 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 MUS10, used at
+  Stanford University, was not an internal DSL, it was created by
+  modifying an existing ALGOL parser \citep[p248]{loy1985}.}.
 (Therefore, according to the definition of Unit Generator provided in
 this paper, MUSIGOL does not qualify as a language that uses Unit
 Generators.)
@@ -394,8 +352,8 @@ time steps prior \(O_{n-t}\), and an arbitrary amplitude parameter
 
 \[O_n = I_1 \cdot S_n + I_2 \cdot O_{n-1} - I_3 \cdot O_{n-2}\]
 
-In MUSIC V, this band-pass filter can be used as in \ref{lst:musicv}
-\citep[p78]{mathews_technology_1969}.
+In MUSIC V, this band-pass filter can be used as in Listing
+\ref{lst:musicv} \citep[p78]{mathews_technology_1969}.
 
 \begin{lstlisting}[label={lst:musicv}, caption={Example of the use of FLT UGen in MUSIC V.}]
 FLT I1 O I2 I3 Pi Pj;
@@ -422,20 +380,21 @@ the desired frequency characteristics\footnote{It is said that a
   \citep[p77]{mathews_technology_1969}.}, and they also had to account
 for using at least two sample memory spaces.
 
-On the other hand, in MUSIC 11, developed by Barry Vercoe, and its later
-iteration, CSound, the band-pass filter is defined as a Unit Generator
-(UGen) named \passthrough{\lstinline!reson!}. This UGen accepts four
-parameters: the input signal, center cutoff frequency, bandwidth, and Q
-factor. Unlike previous implementations, users no longer need to be
-aware of the two-sample feedback memory space for the output
-\citep[p248]{vercoe_computer_1983}. However, in MUSIC 11 and CSound, it
-is still possible to implement this band-pass filter from scratch as a
-User Defined Opcode (UDO) as in \ref{lst:reson}. Vercoe emphasized that
-while signal processing primitives should allow for low-level
-operations, such as single-sample feedback, and eliminate black boxes,
-it is equally important to provide high-level modules that avoid
-unnecessary complexity (``avoid the clutter'') when users do not need to
-understand the internal details \citep[p247]{vercoe_computer_1983}.
+On the other hand, in later MUSIC 11, and succeeding 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
+and no need to aware of the two-sample memory space. However, in MUSIC
+11 and CSound, it is possible to implement this band-pass filter from
+scratch as a User Defined Opcode (UDO) as in Listing \ref{lst:reson}.
+Vercoe emphasized that while signal processing primitives should allow
+for low-level operations, such as single-sample feedback, and eliminate
+black boxes, it is equally important to provide high-level modules that
+avoid unnecessary complexity (``avoid the clutter'') when users do not
+need to understand the internal details
+\citep[p247]{vercoe_computer_1983}.
 
 \begin{lstlisting}[label={lst:reson}, caption={Example of scratch implementation and built-in operation of RESON UGen respectively, in MUSIC11. Retrieved from the original paper. (Comments are omitted for the space restriction.)}]
       instr  1 
@@ -457,39 +416,38 @@ a1    reson  a1,p5,p6,1
       endin
 \end{lstlisting}
 
-On the other hand, in programming environments that inherit the Unit
+On the other hand, in succeeding environments that inherit the Unit
 Generator paradigm, such as Pure Data \citep{puckette_pure_1997}, Max
 (whose signal processing functionalities were ported from Pure Data as
 MSP), SuperCollider \citep{mccartney_supercollider_1996}, and ChucK
 \citep{wang_chuck_2015}, primitive UGens are implemented in
-general-purpose languages like C or C++. If users wish to define
-low-level UGens (External Objects), they need to set up a development
-environment for C or C++.
-
-As an extension, ChucK later introduced ChuGen, which is equivalent to
-CSound's UDO, allowing users to define low-level UGens within the ChucK
-language itself \citep{Salazar2012}. However, both CSound and ChucK face
-performance limitations with UDOs during runtime compared to natively
-implemented UGens. Consequently, not all existing UGens are replaced by
-UDOs, which remain supplemental features rather than primary tools.
+general-purpose languages like C or C++\footnote{ChucK later introduced
+  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
+  because the runtime performance of UDO is inferior to natively
+  implemented UGens.}. If users wish to define low-level UGens (external
+objects in Max and Pd), they need to set up a development environment
+for C or C++.
 
 When UGens are implemented in low-level languages like C, even if the
 implementation is open-source, the division of knowledge effectively
 forces users (composers) to treat UGens as black boxes. This reliance on
 UGens as black boxes reflects and deepens the division of labor between
-musicians and scientists that Mathews helped establish---a structure
-that can be seen as both a cause and a result of this paradigm.
+musicians and scientists that was establish in MUSIC though the it can
+be interpreted as both a cause and a result.
 
 For example, Puckette, the developer of Max and Pure Data, noted that
-the division of labor at IRCAM between researchers, Musical
-Assistants/realizers, and composers has parallels in the current Max
-ecosystem, where the roles are divided into software developers,
-External Objects developers, and Max users \citep{puckette_47_2020}. As
-described in the ethnography of 1980s IRCAM by anthropologist Georgina
-Born, the division of labor between fundamental research scientists and
-composers at IRCAM was extremely clear. This structure was also tied to
-the exclusion of popular music and its associated technologies in
-IRCAM's research focus \citep{Born1995}.
+the division of labor at IRCAM between Researchers, Musical
+Assistants(Realizers), and Composers has parallels in the current Max
+ecosystem, where the roles are divided into Max developers them selves,
+developers of external objects, and Max users \citep{puckette_47_2020}.
+As described in the ethnography of 1980s IRCAM by anthropologist
+Georgina Born, the division of labor between fundamental research
+scientists and composers at IRCAM was extremely clear. This structure
+was also tied to the exclusion of popular music and its associated
+technologies in IRCAM's research focus \citep{Born1995}.
 
 However, such divisions are not necessarily the result of differences in
 values along the axes analyzed by Born, such as
@@ -507,8 +465,7 @@ into consumers.
 \begin{quote}
 Lacking adequate knowledge of the technical system, musicians
 increasingly found themselves drawn to prefabricated programs as a
-source of new sound material. As I have argued, however, this assertion
-is not simply a state ment of fact; it also suggests a
+source of new sound material. (\ldots)it also suggests a
 reconceptualization on the part of the industry of the musician as a
 particular type of consumer. \citep[p89]{theberge_any_1997}
 \end{quote}
@@ -516,7 +473,7 @@ particular type of consumer. \citep[p89]{theberge_any_1997}
 This argument can be extended beyond electronic music to encompass
 computer-based music in general. For example, media researcher Lori
 Emerson noted that while the proliferation of personal computers began
-with the vision of ``metamedia''---tools that users could modify
+with the vision of ``metamedium''---tools that users could modify
 themselves, as exemplified by Xerox PARC's Dynabook---the vision was
 ultimately realized in an incomplete form through devices like the
 Macintosh and iPad, which distanced users from programming by
@@ -527,16 +484,16 @@ extensibility through programming renders it merely a device for media
 consumption \citep{kay2019}.
 
 Although programming environments as tools for music production are not
-widely used, the Unit Generator concept, alongside MIDI, serves as a
-foundational paradigm for today's consumer music production software and
-infrastructure, including Web Audio. It is known that the concept of
+relatively used, the UGen concept serves as a premise for today's
+popular music production software and infrastructure, like audio plugin
+formats for DAW softwares and WebAudio. It is known that the concept of
 Unit Generators emerged either simultaneously with or even slightly
 before modular synthesizers \citep[p20]{park_interview_2009}. However,
-UGen-based languages have actively incorporated the user interface
-metaphors of modular synthesizers, as Vercoe said that the distinction
-between ``ar'' (audio-rate) and ``kr'' (control-rate) processing
-introduced in MUSIC 11 is said to have been inspired by Buchla's
-differentiation between control and audio signals in its plug type
+UGen-based languages have actively incorporated metaphors of modular
+synthesizers for their user interface, as Vercoe said that the
+distinction between ``ar'' (audio-rate) and ``kr'' (control-rate)
+processing introduced in MUSIC 11 is said to have been inspired by
+Buchla's distinction in its plug type
 \citep[1:01:38--1:04:04]{vercoe_barry_2012}.
 
 However, adopting visual metaphors comes with the limitation that it
@@ -554,9 +511,9 @@ as the most convenient software equivalents of modular synthesizers.
 Based on the discussions thus far, music programming languages developed
 after the 2000s can be categorized into two distinct directions: those
 that narrow the scope of the language's role by attempting alternative
-abstractions at a higher level, distinct from the Unit Generator
-paradigm, and those that expand the general-purpose capabilities of the
-language, reducing black-boxing.
+abstractions at a higher level, distinct from the UGen paradigm, and
+those that expand the general-purpose capabilities of the language,
+reducing black-boxing.
 
 Languages that pursued alternative abstractions at higher levels have
 evolved alongside the culture of live coding, where performances are
@@ -584,9 +541,9 @@ On the other hand, due to their high-level design, these languages often
 rely on ad hoc implementations for tasks like sound manipulation and
 low-level signal processing, such as effects.
 
-McCartney, the developer of SuperCollider, once stated that if
+McCartney, the developer of SuperCollider, stated that if
 general-purpose programming languages were sufficiently expressive,
-there would be no need to create specialized languages
+there would be no need to create special languages
 \citep{McCartney2002}. This prediction appears reasonable when
 considering examples like MUSIGOL. However, in practice, scripting
 languages that excel in dynamic program modification face challenges in
@@ -605,7 +562,7 @@ portability across not only different CPUs but also diverse host
 environments such as operating systems and the Web, these languages are
 no longer as portable as they once were. Consequently, systems targeting
 signal processing implemented as internal DSLs have become exceedingly
-rare, with only a few examples like LuaAV \citep{wakefield2010}.
+rare, with only a few examples like LuaAV\citep{wakefield2010}.
 
 Instead, an approach has emerged to create general-purpose languages
 specifically designed for use in music from the ground up. One prominent
@@ -620,15 +577,13 @@ high-speed execution.
 
 The expressive power of general-purpose languages and compiler
 infrastructures like LLVM have given rise to an approach focused on
-designing languages with formalized abstractions that reduce
-black-boxing. \textbf{Faust} \citep{Orlarey2009}, for example, is a
+designing languages with mathematical formalization that reduce
+black-boxing. \textbf{Faust} \citep{Orlarey2009}, for instance, is a
 language that retains a graph-based structure akin to UGens but is built
-on a formal system called Block Diagram Algebra. This system integrates
-primitives for reading and writing internal states, which are essential
-for operations like delays and filters. Thanks to its formalization,
-Faust can be transpiled into general-purpose languages such as C, C++,
-or Rust and can also be used as an External Object in environments like
-Max or Pure Data.
+on a formal system called Block Diagram Algebra. Thanks to its
+formalization, Faust can be transpiled into general-purpose languages
+such as C, C++, or Rust and can also be used as an External Object in
+environments like Max or Pure Data.
 
 Languages like \textbf{Kronos} \citep{norilo2015} and \textbf{mimium}
 \citep{matsuura_mimium_2021}, which are based on the more general
@@ -640,25 +595,25 @@ interoperability with other general-purpose languages
 
 Domain-specific languages (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 programming. In this
-context, efforts like Extempore, Kronos, and mimium are not merely
-programming languages for music but are also situated within the broader
-research context of Functional Reactive Programming (FRP), which focuses
-on representing time-varying values in computation. Most computer
-hardware lacks an inherent concept of real time and instead operates
-based on discrete computational steps. Similarly, low-level
-general-purpose programming languages do not natively include primitives
-for real-time concepts. Consequently, the exploration of computational
-models tied to time---a domain inseparable from music---remains vital
-and has the potential to contribute to the theoretical foundations of
+certain degree of expressive freedom through coding. In this context,
+efforts like Extempore, Kronos, and mimium are not merely programming
+languages for music but are also situated within the broader research
+context of functional reactive programming (FRP), which focuses on
+representing time-varying values in computation. Most of computing
+models lack an inherent concept of real time and instead operates based
+on discrete computational steps. Similarly, low-level general-purpose
+programming languages do not natively include primitives for real-time
+concepts. Consequently, the exploration of computational models tied to
+time ---a domain inseparable from music--- remains vital and has the
+potential to contribute to the theoretical foundations of
 general-purpose programming languages.
 
 However, strongly formalized languages come with their own trade-offs.
 While they allow UGens to be defined without black-boxing, understanding
-the design and implementation of these languages often requires advanced
-knowledge. This can create a significant divide between language
-developers and users, in contrast to the more segmented roles seen in
-the Multi-Language paradigm---such as SuperCollider developers, external
+the design and implementation of these languages often requires expert
+knowledge. This can create a deeper division between language developers
+and users, in contrast to the many but small and shallow division seen
+in the Multi-Language paradigm, like SuperCollider developers, external
 UGen developers, client language developers (e.g., TidalCycles),
 SuperCollider users, and client language users.
 
@@ -686,10 +641,7 @@ Most newer tools abstract the signal processing routines and variables,
 making them easier to use while removing the need for understanding the
 underlying processes in order to create meaningful results. Composers no
 longer necessarily need mathematical and programming skills to use the
-technologies. These abstractions are important, as they hide many of the
-technical details and make the software and processes available to more
-people, and form the basis for what can arguably be seen as a new folk
-music. \citep[p2]{holbrook2022}
+technologies.\citep[p2]{holbrook2022}
 \end{quote}
 
 However, this division of labor also creates a shared vocabulary
@@ -707,31 +659,28 @@ aesthetic value within musical culture (and what forms of musical
 practice they enable), as well as the social (im)balances of power they
 produce.
 
-It has been noted in programming language research that evaluation
-criteria such as efficiency, expressiveness, and generality are often
-ambiguous \citep{Markstrum2010}. This issue is even more acute in fields
-like music, where no clear evaluation criteria exist. Thus, as McPherson
-et al.~have proposed with the concept of Idiomaticity
-\citep{McPherson2020}, we need to develop and share a vocabulary for
-understanding the value judgments we make about programming languages in
-general.
+The academic value of the research of programming languages for music is
+often vaguely claimed, like the word of ``general'', ``expressive'', and
+``efficient'' but it is difficult to argue these claims when the
+processing speed is no more the primary issue. Thus, as like
+Idiomaticity \citep{McPherson2020} by McPherson et al., we need to
+develop and share a vocabulary for understanding the value judgments we
+make about music languages.
 
-In a broader sense, the creation of programming languages for music has
-also expanded to the individual level. Examples include \textbf{Gwion}
-by Astor, which builds on ChucK and enhances its abstraction
-capabilities with features like lambda functions
-\citep{astor_gwion_2017}; \textbf{Vult}, a DSP transpiler language
-created by Ruiz for his modular synthesizer hardware \citep{Ruiz2020};
-and a UGen-based live coding environment designed for web execution,
-\textbf{Glicol} \citep{lan_glicol_2020}. However, these efforts have not
-yet been adequately integrated into academic discourse.
+In a broader sense, the development of programming languages for music
+has also expanded to the individual level. Examples include
+\textbf{Gwion} by Astor, which is inspired by ChucK and enhances its
+abstraction capabilities like lambda functions \citep{astor_gwion_2017};
+\textbf{Vult}, a DSP transpiler language created by Ruiz for his modular
+synthesizer hardware \citep{Ruiz2020}; and a UGen-based live coding
+environment designed for web environment, \textbf{Glicol}
+\citep{lan_glicol_2020}. However, these efforts have not yet been
+included into academic discourse.
 
-Conversely, practical knowledge of university-researched languages from
-the past, as well as real-time hardware-oriented systems from the 1980s,
-is gradually being lost. While research efforts such as \emph{Inside
-Computer Music}, which analyzes historical works of computer music, have
-begun \citep{clarke_inside_2020}, an archaeological practice focused on
-the construction of computer music systems will also be necessary in the
-future. This includes not only collecting primary resources, such as
-oral archives from those involved, but also reconstructing the knowledge
-and practices behind these systems.
+Conversely, practical knowledge of past languages in 50-60s as well as
+real-time hardware-oriented systems from the 80s, is gradually being
+lost. While research efforts such as \emph{Inside Computer Music}, which
+analyzes historical works of computer music, have begun
+\citep{clarke_inside_2020}, an archaeological practice focused on the
+construction of computer music systems themselves will also be
+necessary.