tomoyanonymous/icmc-2025
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

proofing finished

Browse Source
This commit is contained in:
松浦 知也 Matsuura Tomoya
2025-01-29 07:48:26 +00:00
parent e0238ab50b
commit 412e2b9007
4 changed files with 285 additions and 293 deletions
Download Patch File Download Diff File Expand all files Collapse all files

495
content.tex
View File

@@ -1,9 +1,7 @@
\section{Introduction}\label{introduction}
Programming languages and environments for music have developed hand in
hand with the history of creating music using computers. Software and
systems like Max, Pure Data, CSound, and SuperCollider has been referred
to as ``Computer Music
Programming languages and environments for music such as 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
@@ -13,13 +11,13 @@ 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.
In the early days, when computers were confined to research laboratories
and neither displays nor mouse existed, creating sound or music with
computers was inevitably equal to the work of programming. Today,
however, programming as a means to produce sound on a computer---rather
than employing Digital Audio Workstation (DAW) software like Pro Tools
is not usual. In other words, programming languages for music developed
after the proliferation of personal computers are the softwares that
In the early days, when computers existed only in research laboratories
and neither displays nor mice existed, creating sound or music with
computers was inevitably equivalent to programming. Today, however,
programming as a means to produce sound on a computer---rather than
employing Digital Audio Workstation (DAW) software like Pro Tools is not
popular. In other words, programming languages for music developed after
the proliferation of personal computers are the softwares that
intentionally chose programming (whether textual or graphical) as their
frontend for making sound.
@@ -32,7 +30,7 @@ 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.
In this paper, a critical historical review is conducted by deriving
In this paper, a critical historical review is conducted by drawing on
discussions from sound studies alongside existing surveys, aiming to
consider programming languages for music independently from computer
music as the specific genre.
@@ -40,72 +38,72 @@ music as the specific genre.
\subsection{Use of the Term ``Computer
Music''}\label{use-of-the-term-computer-music}
The term ``Computer Music,'' despite its literal and potential broad
meaning, has been noted as being used within a narrowly defined
The term ``Computer Music,'' despite its literal and potentially broad
meaning, has been noted for being used within a narrowly defined
framework tied to specific styles or communities, as represented in
Ostartag's \emph{Why Computer Music Sucks}\citep{ostertag1998} since the
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
imagine a situation in which computers are not involved at any stage
from production to experience of music\citep[p1]{lyon_we_2006}. The
from the production to experience of music\citep[p1]{lyon_we_2006}. The
necessity of using the term ``Computer Music'' to describe academic
contexts has consequently diminished.
Holbrook and Rudi continued Lyon's discussion by proposing the use of
Holbrook and Rudi extended Lyon's discussion by proposing the use of
frameworks like Post-Acousmatic\citep{adkins2016} to redefine ``Computer
Music.'' Their approach incorporates the tradition of pre-computer
experimental/electronic music, situating it as part of the broader
continuum of technology-based or technology-driven
music\citep{holbrook2022}.
While the strict definition of the Post-Acousmatic music is not given
deliberately, one of its elements contains the expansion of music
production from institutional settings to individuals and the use of the
technology were diversified\citep[p113]{adkins2016}. However, while the
Post-Acousmatic discourse integrates the historical fact that declining
computer costs and access beyond laboratories have enabled diverse
musical expressions, it simultaneously marginalizes much of the music
that is ``just using computers'' and fails to provide insights into this
divided landscape.
While the strict definition of Post-Acousmatic music is deliberately
left open, one of its key aspects is the expansion of music production
from institutional settings to individuals and as well as the
diversification of technological usage\citep[p113]{adkins2016}. However,
while the Post-Acousmatic discourse integrates the historical fact that
declining computer costs and increasing accessibility beyond
laboratories have enabled diverse musical expressions, it still
marginalizes much of the music that is ``just using computers'' and
fails to provide insights into this divided landscape.
Lyon argues that the term ``computer music'' is style-agnostic
Lyon argues that the term ``computer music'' is a style-agnostic
definition almost like ``piano music,'' implying that it ignores the
style and form inside music produced by the instruments.
style and form inside music produced by the instrument.
However, one of the defining characteristics of computers as a medium
lies in their ability to treat musical styles themselves as subjects of
meta-manipulation through simulation and modeling. When creating
instruments with computers, or when using such instruments, sound
instruments with computers or when using such instruments, sound
production involves programming---manipulating symbols embedded in a
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 the
computer works as ``creating a snapshot of musical theory, freezing
musical culture in time''\citep[p173]{Magnusson2009} through
particular musical culture. This recursive embedding of language and
recognition, which construct that musical culture, into the resulting
music is a process that goes beyond what is possible with acoustic
instruments or analog instruments. Magnusson refers to this
characteristic of digital instruments as ``Epistemic Tools'' and points
out that the computer serves to ``create a snapshot of musical theory,
freezing musical culture in time'' \citep[p.173]{Magnusson2009} through
formalization.
Today, many people use computers for music production not because they
consciously leverage the uniqueness of the meta-medium, but simply
because there are no quicker or more convenient alternatives available.
Even so, within a musical culture where computers are used as a default
or reluctant choice, musicians are inevitably influenced by the
underlying infrastructures like software, protocols, and formats. As
long as the history of programming languages for music remains
intertwined with the history of computer music as it relates to specific
genres or communities, it becomes difficult to analyze music created
with computers as a passive means.
Even so, within a musical culture where computers are used as a
reluctant choice, musicians are inevitably influenced by the underlying
infrastructures like software, protocols, and formats. As long as the
history of programming languages for music remains intertwined with the
history of computer music as it relates to specific genres or
communities, it becomes difficult to analyze music created with
computers as merely a passive means.
In this paper, the history of programming languages for music is
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
reexamined with an approach that, in contrast to Lyon, adopts a
radically 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: 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
pulse-code modulation (PCM)---the foundational concept underlying most
of today's sound programming, by referencing early attempts at 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
@@ -123,10 +121,10 @@ of music created with computers.
\section{PCM and Early Computer
Music}\label{pcm-and-early-computer-music}
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
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.
@@ -137,31 +135,33 @@ 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 CSIR Mark I (CSIRAC) in
Australia often had ``hoot'' primitive instructions that emit a single
pulse to a speaker.
oscilloscopes.
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 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.
For instance, Louis Wilson, who was an engineer of the BINAC in the UK,
noticed that an AM radio placed near the computer could pick up weak
electromagnetic waves generated during the switching of vacuum tubes,
producing sounds. He leveraged this phenomenon by connecting a speaker
and a power amplifier to the computer's circuit to assist with
debugging. Frances Elizabeth Holberton took this a step further by
programming the computer to generate pulses at desired intervals,
creating melodies in 1949\citep{woltman1990}.
However, not all sound generation at this time was merely the
Also, some computers at this time, such as the CSIR Mark I (CSIRAC) in
Australia often had primitive ``hoot'' instructions that emit a single
pulse to a speaker. Early sound generation using computers, including
the BINAC and CSIR Mark I, primarily involved playing melodies of
existing music.
However, not all sound generation at this time was merely involved the
reproduction of existing music. Doornbusch highlights experiments on the
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
the feedback of pulses traveling through mercury via a speaker and
microphone setup to retain data. Donald Davis, an engineer on the ACE
project, described the sounds it produced as
follows\citep[p19-20]{davis_very_1994}:
Pilot ACE (the Prototype for Automatic Computing Engine) in the UK,
which utilized acoustic delay line memory to produce unique
sounds\citep[pp.303-304]{doornbusch2017}. Acoustic delay line memory,
used as the main memory in early computers such as the BINAC and the
CSIR Mark I, employed the feedback of pulses traveling through mercury
via a speaker and microphone setup to retain data. Donald Davis, an
engineer on the ACE project, described the sounds it produced as
follows\citep[pp.19-20]{davis_very_1994}:
\begin{quote}
The Ace Pilot Model and its successor, the Ace proper, were both capable
@@ -174,68 +174,70 @@ into colored noise as the complexity went beyond human understanding.
\end{quote}
This music arose unintentionally during program optimization and was
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}
made possible by the ``misuse'' of 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 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
research\citep[p.305]{doornbusch2017}. Indeed, the sounds produced by
the Pilot ACE challenge the post-acousmatic historical narrative, which
suggests that computer music transitioned from being democratized in
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
interesting sounds. Moreover, these sounds were tied to the hardware of
the acoustic delay line memory---a feature that was likely difficult to
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
freely available for students to use. He conducted experiments where he
played melodies, such as Bach fugues, using square waves
\citep{levy_hackers_2010}. Samson's experiments with the TX-0 later
evolved into the creation of a program that allowed melodies to be
described using text strings within MIT.
was freely available for students to use. He conducted experiments in
which he played melodies, such as Bach fugues, using ``hoot''
instruction\citep{levy_hackers_2010}. Samson's experiments with the TX-0
later evolved into the creation of a program that allowed melodies to be
described using text within MIT.
Building on this, Samson developed a program called the Harmony Compiler
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 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.
surveying various digital synthesizers that were under development 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 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}
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 can generate
``almost any sound''\citep[p557]{mathews1963}
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}
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.
PCM, the foundational digital sound representation today, involves
sampling audio waveforms at discrete intervals and quantizing 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
Post-Acousmatic. Acousmatic, introduced by Piegnot as a listening style
for tape music such as musique concrète and later theorized by
Schaeffer, refers to a mode of listening where the listener refrains
from imagining a specific sound source. This concept has been widely
applied in theories of listening to recorded sound, including Chion's
analysis of sound design in film.
is inherent in the concept of Acousmatic Listening, which serves as a
premise for Post-Acousmatic. Acousmatic, introduced by Piegnot as a
listening style for tape music such as musique concrète and later
theorized by Schaeffer\citep[p106]{adkins2016}, refers to a mode of
listening in which the listener refrains from imagining a specific sound
source. This concept has been widely applied in theories of listening to
recorded sound, including Michel Chion's analysis of sound design in
film.
However, as sound studies scholar Jonathan Sterne has pointed out,
discourses surrounding acousmatic listening often work to delineate
@@ -244,12 +246,12 @@ contrast\footnote{Sterne later critiques the phenomenological basis of
acousmatic listening, which presupposes an idealized, intact body as
the listening subject. He proposes a methodology of political
phenomenology centered on impairment, challenging these normative
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 sound reproduction
technologies, listening was unmediated and holistic---a narrative that
obscures the constructed nature of these assumptions.
assumptions \citep{sterne_diminished_2022}. Discussions of
universality in computer music should also address ableism,
particularly in relation to recording technologies and auditory
disabilities.}. 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
@@ -263,17 +265,17 @@ 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 through Shannon's
information theory, by statistically modeling human auditory
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
Incidentally, the actual implementation of PCM in MUSIC I only allowed
for 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?
capable of producing ``almost any sound''?
Even when considering more contemporary applications, processes like
ring modulation (RM), amplitude modulation (AM), or distortion often
@@ -281,32 +283,33 @@ 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, present
collections 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}
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
Beginning with version III, MUSIC took the form of an acoustic compiler
(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
``Unit Generator'' means a signal processing modules where its
``Unit Generator''refers to a signal processing module whose
implementation is either not open or written in a language different
from the one used by the user.
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:
The MUSIC family, in the context of computer music research, achieved
success for performing sound synthesis based on PCM but this success
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 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
repeatedly stated that his role was that of a scientist rather than a
musician:
\begin{quote}
When we first made these music programs the original users were not
@@ -319,26 +322,26 @@ willing to experiment.\citep[p17]{Mathews1980}
This clear delineation of roles between musicians and scientists became
one of the defining characteristics of post-MUSIC computer music
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.
research. Paradoxically, while computer music research aimed to create
sounds never heard before, it also paved the way for further research by
allowing musicians to focus on composition without having to understand
the cumbersome work of programming.
\subsection{Example: Hiding First-Order Variables in Signal
Processing}\label{example-hiding-first-order-variables-in-signal-processing}
\subsection{Example: Hiding Internal State Variables in Signal
Processing}\label{example-hiding-internal-state-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
programming language varies significantly, even within the series.
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}.}.
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
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
this paper, MUSIGOL does not qualify as a language that uses Unit
Generators.)
@@ -352,14 +355,9 @@ 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 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;
\end{lstlisting}
Here, \passthrough{\lstinline!I1!} represents the input bus, and
In MUSIC V, this band-pass filter can be used as shown in Listing
\ref{lst:musicv} \citep[p.78]{mathews_technology_1969}. Here,
\passthrough{\lstinline!I1!} represents the input bus, and
\passthrough{\lstinline!O!} is the output bus. The parameters
\passthrough{\lstinline!I2!} and \passthrough{\lstinline!I3!} correspond
to the normalized values of the coefficients \(I_2\) and \(I_3\),
@@ -371,32 +369,35 @@ from the Score, specifically among the available
case, however, these parameters are repurposed as general-purpose memory
to temporarily store feedback signals. Similarly, other Unit Generators,
such as oscillators, reuse note parameters to handle operations like
phase accumulation.
As a result, users needed to manually calculate feedback gains based on
the desired frequency characteristics\footnote{It is said that a
preprocessing feature called \passthrough{\lstinline!CONVT!} could be
used to transform frequency characteristics into coefficients
phase accumulation. As a result, users needed to manually calculate
feedback gains based on the desired frequency
characteristics\footnote{It is said that a preprocessing feature called
\passthrough{\lstinline!CONVT!} could be used to transform frequency
characteristics into coefficients
\citep[p77]{mathews_technology_1969}.}, and they also had to account
for using at least two sample memory spaces.
for at least two sample memory spaces.
On the other hand, in later MUSIC 11, and succeeding 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
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}.
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
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
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[p.247]{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.)}]
\begin{lstlisting}[caption={Example of the use of FLT UGen in MUSIC V.}, label=lst:musicv]
FLT I1 O I2 I3 Pi Pj;
\end{lstlisting}
\begin{lstlisting}[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.)}, label=lst:reson]
instr 1
la1 init 0
la2 init 0
@@ -427,27 +428,27 @@ general-purpose languages like C or C++\footnote{ChucK later introduced
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++.
implemented UGens.}. If users wish to define low-level UGens (called
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 was establish in MUSIC though the it can
be interpreted as both a cause and a result.
musicians and scientists that was established in MUSIC though 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 Max developers them selves,
ecosystem, where roles are divided among Max developers themselves,
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}.
technologies from 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
@@ -467,13 +468,13 @@ Lacking adequate knowledge of the technical system, musicians
increasingly found themselves drawn to prefabricated programs as 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}
particular type of consumer. \citep[p.89]{theberge_any_1997}
\end{quote}
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 ``metamedium''---tools that users could modify
with the vision of a ``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
@@ -484,16 +485,16 @@ extensibility through programming renders it merely a device for media
consumption \citep{kay2019}.
Although programming environments as tools for music production are not
relatively used, the UGen concept serves as a premise for today's
popular music production software and infrastructure, like audio plugin
widely used, the UGen concept serves as a premise for today's popular
music production software and infrastructure, such as 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 metaphors of modular
synthesizers for their user interface, as Vercoe said that the
before modular synthesizers \citep[p.20]{park_interview_2009}. However,
UGen-based languages have actively incorporated metaphors from modular
synthesizers for their user interfaces, as Vercoe noted 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
Buchla's distinction in plug types
\citep[1:01:38--1:04:04]{vercoe_barry_2012}.
However, adopting visual metaphors comes with the limitation that it
@@ -501,21 +502,22 @@ constrains the complexity of representation to what is visually
conceivable. In languages with visual patching interfaces like Max and
Pure Data, meta-operations on UGens are often restricted to simple
tasks, such as parallel duplication. Consequently, even users of Max or
Pure Data may not necessarily be engaging in expressions that are only
possible with computers. Instead, many might simply be using these tools
as the most convenient software equivalents of modular synthesizers.
Pure Data may not necessarily be engaging in forms of expressions that
are only possible with computers. Instead, many might simply be using
these tools as the most convenient software equivalents of modular
synthesizers.
\section{Context of Programming Languages for Music After
2000}\label{context-of-programming-languages-for-music-after-2000}
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 UGen paradigm, and
that narrow the scope of the language's role by introducing alternative
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
Languages that pursued alternative higher-level abstractions have
evolved alongside the culture of live coding, where performances are
conducted by rewriting code in real time. The activities of the live
coding community, including groups such as TOPLAP since the 2000s, were
@@ -526,7 +528,7 @@ states, ``Obscurantism is dangerous''
\citep{toplap_manifestodraft_2004}.
Languages implemented as clients for SuperCollider, such as \textbf{IXI}
(on Ruby) \citep{Magnusson2011}, \textbf{Sonic Pi}(on Ruby),
(on Ruby) \citep{Magnusson2011}, \textbf{Sonic Pi} (on Ruby),
\textbf{Overtone} (on Clojure) \citep{Aaron2013}, \textbf{TidalCycles}
(on Haskell) \citep{McLean2014}, and \textbf{FoxDot} (on Python)
\citep{kirkbride2016foxdot}, leverage the expressive power of more
@@ -538,31 +540,28 @@ can also be applied to visual patterns and other outputs, meaning it is
not inherently tied to PCM-based waveform output as the final result.
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.
rely on ad-hoc implementations for tasks like sound manipulation and
low-level signal processing, such as effects. McCartney, the developer
of SuperCollider, stated that if general-purpose programming languages
were sufficiently expressive, there would be no need to create
specialized 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 modern preemptive OS environments. For instance, dynamic
memory management techniques such as garbage collection can hinder
deterministic execution timing required for real-time processing
\citep{Dannenberg2005}.
McCartney, the developer of SuperCollider, stated that if
general-purpose programming languages were sufficiently expressive,
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
modern preemptive OS environments. For instance, dynamic memory
management techniques such as garbage collection can hinder the ability
to guarantee deterministic execution timing required for real-time
processing \citep{Dannenberg2005}.
Historically, programming in languages like FORTRAN or C served as a
universal method for implementing audio processing on computers,
independent of architecture. However, with the proliferation of
general-purpose programming languages, programming in C or C++ has
become relatively more difficult, akin to programming in assembly
Historically, programming languages like FORTRAN or C served as a
portable way for implementing programs across different architectures.
However, with the proliferation of higher-level languages, programming
in C or C++ has become relatively more difficult, akin to assembly
language in earlier times. Furthermore, considering the challenges of
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}.
portability not only across different CPUs but also diverse host
environments such as OSs and the Web, these languages are no longer as
portable as they once were. Consequently, internal DSL for music
including signal processing have become exceedingly rare, with only a
few examples such as 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
@@ -576,14 +575,14 @@ processing code, including sound manipulation, into machine code for
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 mathematical formalization that reduce
infrastructures like LLVM has given rise to an approach focused on
designing languages with mathematical formalization that reduces
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. 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.
formalization, Faust can be transpiled into various low-level languages
such as C, C++, or Rust and can also be used as external objects in Max
or Pure Data.
Languages like \textbf{Kronos} \citep{norilo2015} and \textbf{mimium}
\citep{matsuura_mimium_2021}, which are based on the more general
@@ -599,27 +598,27 @@ 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
representing time-varying values in computation. Most 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.
However, strongly formalized languages come with another trade-off.
While they allow UGens to be defined without black-boxing, understanding
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
and users, in contrast to the many but small and shallow divisions seen
in the multi-language paradigm, like SuperCollider developers, external
UGen developers, client language developers (e.g., TidalCycles),
SuperCollider users, and client language users.
Although there is no clear solution to this trade-off, one intriguing
idea is the development of self-hosting languages for music---that is,
languages where their own compilers are written in the language itself.
languages whose their own compilers are written in the language itself.
At first glance, this may seem impractical. However, by enabling users
to learn and modify the language's mechanisms spontaneously, this
approach could create an environment that fosters deeper engagement and
@@ -633,7 +632,7 @@ black-boxing tendencies of the Unit Generator paradigm. Historically, it
was expected that the clear division of roles between engineers and
composers would enable the creation of new forms of expression using
computers. Indeed, from the perspective of Post-Acousmatic discourse,
some, like Holbrook and Rudi, still consider this division to be a
some, such as Holbrook and Rudi, still consider this division to be a
positive development:
\begin{quote}
@@ -644,11 +643,11 @@ longer necessarily need mathematical and programming skills to use the
technologies.\citep[p2]{holbrook2022}
\end{quote}
However, this division of labor also creates a shared vocabulary
(exactly seen in the Unit Generator by Mathews) and works to perpetuate
However, this division of labor also creates a shared vocabulary (as
exemplified in the Unit Generator by Mathews) and serves to perpetuate
it. By portraying new technologies as something externally introduced,
and by focusing on the agency of those who create music with computers,
the individuals responsible for building the programming environments,
the individuals responsible for building programming environments,
software, protocols, and formats are rendered invisible
\citep{sterne_there_2014}. This leads to an oversight of the indirect
power relationships produced by these infrastructures.
@@ -659,10 +658,10 @@ aesthetic value within musical culture (and what forms of musical
practice they enable), as well as the social (im)balances of power they
produce.
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
The academic value of the research on programming languages for music is
often vaguely asserted, using terms such as ``general'', ``expressive'',
and ``efficient''. However, it is difficult to argue these claims when
processing speed is no longer the primary concern. Thus, as with
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.
@@ -670,15 +669,15 @@ make about music languages.
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};
abstraction, such as 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.
environment designed for web, \textbf{Glicol} \citep{lan_glicol_2020}.
However, these efforts have not yet been incorporate into academic
discourse.
Conversely, practical knowledge of past languages in 50-60s as well as
real-time hardware-oriented systems from the 80s, is gradually being
Conversely, practical knowledge of past languages in 1960s 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