updated references

content.tex

@@ -453,7 +453,7 @@ On the other hand, in programming 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{wangChucKStronglyTimed2015}, primitive UGens are implemented in
+\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++.
@@ -602,13 +602,13 @@ 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
 example is \textbf{Extempore}, a live programming environment developed
-by Sorensen \citep{sorensenExtemporeDesignImplementation2018}. Extempore
+by Sorensen \citep{sorensen_extempore_2018}. Extempore consists of
-consists of Scheme, a LISP-based language, and xtlang, a
+Scheme, a LISP-based language, and xtlang, a meta-implementation on top
-meta-implementation on top of Scheme. While xtlang requires users to
+of Scheme. While xtlang requires users to write hardware-oriented type
-write hardware-oriented type signatures similar to those in C, it
+signatures similar to those in C, it leverages the LLVM compiler
-leverages the LLVM compiler infrastructure \citep{Lattner} to
+infrastructure \citep{Lattner} to just-in-time (JIT) compile signal
-just-in-time (JIT) compile signal processing code, including sound
+processing code, including sound manipulation, into machine code for
-manipulation, into machine code for high-speed execution.
+high-speed execution.
 
 The expressive power of general-purpose languages and compiler
 infrastructures like LLVM have given rise to an approach focused on
@@ -622,13 +622,13 @@ 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}
+Languages like \textbf{Kronos} \citep{norilo2015} and \textbf{mimium}
-\citep{noriloKronosReimaginingMusical2016} and \textbf{mimium}
+\citep{matsuura_mimium_2021}, which are based on the more general
-\citep{matsuura2021}, which are based on the more general computational
+computational model of lambda calculus, focus on PCM-based signal
-model of lambda calculus, focus on PCM-based signal processing while
+processing while exploring interactive meta-operations on programs
-exploring interactive meta-operations on programs \citep{Norilo2016} and
+\citep{Norilo2016} and balancing self-contained semantics with
-balancing self-contained semantics with interoperability with other
+interoperability with other general-purpose languages
-general-purpose languages \citep{matsuura2024}.
+\citep{matsuura_lambda-mmm_2024}.
 
 Domain-specific languages (DSLs) are constructed within a double bind:
 they aim to specialize in a particular purpose while still providing a
@@ -712,12 +712,13 @@ general.
 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{astorGwion2017};
+capabilities with features like lambda functions
-\textbf{Vult}, a DSP transpiler language created by Ruiz for his modular
+\citep{astor_gwion_2017}; \textbf{Vult}, a DSP transpiler language
-synthesizer hardware \citep{ruizVultLanguage2020}; and a UGen-based live
+created by Ruiz for his modular synthesizer hardware
-coding environment designed for web execution, \textbf{Glicol}
+\citep{ruiz_vult_2020}; and a UGen-based live coding environment
-\citep{lan_glicol_2020}. However, these efforts have not yet been
+designed for web execution, \textbf{Glicol} \citep{lan_glicol_2020}.
-adequately integrated into academic discourse.
+However, these efforts have not yet been adequately integrated into
+academic discourse.
 
 Conversely, practical knowledge of university-researched languages from
 the past, as well as real-time hardware-oriented systems from the 1980s,

main.bib

@@ -111,6 +111,18 @@
   file = {/Users/tomoya/Zotero/storage/4VMZB5ID/full-text.pdf}
 }
 
+@book{clarke_inside_2020,
+  title = {{Inside Computer Music}},
+  author = {Clarke, Michael and Dufeu, Frdric and Manning, Peter},
+  year = {2020},
+  month = sep,
+  publisher = {Oxford Univ Pr},
+  address = {New York},
+  abstract = {Inside Computer Music is an investigation of how new technological developments have influenced the creative possibilities of composers of computer music in the last 50 years. This book combines detailed research into the development of computer music techniques with nine case studies that analyze key works in the musical and technical development of computer music. The book's companion website offers demonstration videos of the techniques used and downloadable software. There, readers can view interviews and test emulations of the software used by the composers for themselves. The software also presents musical analyses of each of the nine case studies to enable readers to engage with the musical structure aurally and interactively.},
+  isbn = {978-0-19-065965-3},
+  language = {英語}
+}
+
 @inproceedings{Coblenz2018,
   title = {Interdisciplinary {{Programming Language Design}}},
   booktitle = {Proceedings of the 2018 {{ACM SIGPLAN International Symposium}} on {{New Ideas}}, {{New Paradigms}}, and {{Reflections}} on {{Programming}} and {{Software}}},
@@ -126,6 +138,16 @@
   file = {/Users/tomoya/Zotero/storage/FIGKGQMH/Muller2020 (日本語).pdf;/Users/tomoya/Zotero/storage/IPSD32MQ/Coblenz et al. - 2018 - Interdisciplinary Programming Language Design(2).pdf;/Users/tomoya/Zotero/storage/P4SPTMMF/full-text.pdf}
 }
 
+@inproceedings{Dannenberg2005,
+  title = {Design {{Patterns}} for {{Real-Time Computer Music Systems}}},
+  booktitle = {{{ICMC}} 2005 {{Workshop}} on {{Real Time Systems Concepts}} for {{Computer Music}}},
+  author = {Dannenberg, Roger B and Bencina, Ross},
+  year = {2005},
+  urldate = {2021-05-11},
+  abstract = {This document contains a set of "design patterns" for real time systems, particularly for computer music systems. We see these patterns often because the problems that they solve come up again and again. Hopefully, these patterns will serve a more than just a set of canned solutions. It is perhaps even more important to understand the underlying problems, which often have subtle aspects and ramifications. By describing these patterns, we have tried to capture the problems, solutions, and a way of thinking about real-time systems design. We welcome your comments and questions.},
+  file = {/Users/tomoya/Zotero/storage/GHPQY7QA/full-text.pdf}
+}
+
 @article{Dannenberg2018,
   title = {Languages for {{Computer Music}}},
   author = {Dannenberg, Roger B.},
@@ -425,7 +447,8 @@
   publisher = {M.I.T. Press},
   urldate = {2020-03-31},
   isbn = {0-262-13050-5},
-  keywords = {Computer composition sound processing}
+  keywords = {Computer composition sound processing},
+  annotation = {Citations Key:mathews\_technology\_1969}
 }
 
 @article{mathews1963,
@@ -620,6 +643,15 @@
   file = {/Users/tomoya/Zotero/storage/THAKVEM6/m-api-574ff3be-cfe2-7867-406a-df50770bf1cb.pdf}
 }
 
+@inproceedings{Norilo2016,
+  title = {Kronos {{Meta-Sequencer}} -- {{From Ugens}} to {{Orchestra}}, {{Score}} and {{Beyond}}},
+  booktitle = {Proceedings of the {{International Computer Music Conference}}},
+  author = {Norilo, Vesa},
+  year = {2016},
+  pages = {117--122},
+  file = {/Users/tomoya/Zotero/storage/W53EPTFM/kronos-metasequencer.pdf;/Users/tomoya/Zotero/storage/WFSQ4VWI/kronos-metasequencer.pdf}
+}
+
 @article{Nyquist1928,
   title = {Certain {{Topics}} in {{Telegraph Transmission Theory}}},
   author = {Nyquist, H.},
@@ -654,6 +686,22 @@
   file = {/Users/tomoya/Zotero/storage/9QAGQSVS/writings-articles-computer-music-sucks.html}
 }
 
+@article{park_interview_2009,
+  title = {An {{Interview}} with {{Max Mathews}}},
+  author = {Park, Tae Hong},
+  year = {2009},
+  month = sep,
+  journal = {Computer Music Journal},
+  volume = {33},
+  number = {3},
+  pages = {9--22},
+  issn = {0148-9267, 1531-5169},
+  doi = {10.1162/comj.2009.33.3.9},
+  urldate = {2022-01-02},
+  language = {en},
+  file = {/Users/tomoya/Zotero/storage/YJ3P36ZU/Park - 2009 - An Interview with Max Mathews.pdf}
+}
+
 @misc{puckette_47_2020,
   title = {47 {$\bullet$} {{Miller Puckette}} {$\bullet$} {{Max}}/{{MSP}} \& {{Pure Data}}},
   author = {Reese, Ivan},
@@ -742,7 +790,7 @@
   file = {/Users/tomoya/Zotero/storage/NIULED49/Scheirer and Vercoe - 1999 - SAOL The MPEG-4 Structured Audio Orchestra Langua.pdf;/Users/tomoya/Zotero/storage/U9MFTBDB/Scheirer and Vercoe - 1999 - SAOL The MPEG-4 Structured Audio Orchestra Langua.pdf}
 }
 
-@phdthesis{sorensen_extempore:_2018,
+@phdthesis{sorensen_extempore_2018,
   title = {Extempore: {{The}} Design, Implementation and Application of a Cyber-Physical Programming Language},
   author = {Sorensen, Andrew Carl},
   year = {2018},
@@ -903,6 +951,16 @@
   howpublished = {https://toplap.org/wiki/ManifestoDraft}
 }
 
+@misc{vercoe_barry_2012,
+  title = {Barry {{Vercoe}} 4/24/2012},
+  author = {Vercoe, Barry L.},
+  year = {2012},
+  month = apr,
+  urldate = {2022-01-14},
+  language = {en-US},
+  file = {/Users/tomoya/Zotero/storage/H5B6GV4U/barry-vercoe-4242012.html}
+}
+
 @article{vercoe_computer_1983,
   title = {Computer {{Systems}} and {{Languages}} for {{Audio Research}}},
   author = {Vercoe, Barry L.},

main.md

@@ -136,7 +136,7 @@ a1    reson  a1,p5,p6,1
       endin
 ~~~
 
-On the other hand, in programming environments that inherit the Unit Generator paradigm, such as Pure Data [@puckette_pure_1997], Max (whose signal processing functionalities were ported from Pure Data as MSP), SuperCollider [@mccartney_supercollider_1996], and ChucK [@wangChucKStronglyTimed2015], 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++.
+On the other hand, in programming environments that inherit the Unit Generator paradigm, such as Pure Data [@puckette_pure_1997], Max (whose signal processing functionalities were ported from Pure Data as MSP), SuperCollider [@mccartney_supercollider_1996], and ChucK [@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 [@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.
 
@@ -170,11 +170,11 @@ McCartney, the developer of SuperCollider, once stated that if general-purpose p
 
 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 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 [@wakefield2010].
 
-Instead, an approach has emerged to create general-purpose languages specifically designed for use in music from the ground up. One prominent example is **Extempore**, a live programming environment developed by Sorensen [@sorensenExtemporeDesignImplementation2018]. 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 [@Lattner] to just-in-time (JIT) compile signal processing code, including sound manipulation, into machine code for high-speed execution.
+Instead, an approach has emerged to create general-purpose languages specifically designed for use in music from the ground up. One prominent example is **Extempore**, a live programming environment developed by Sorensen [@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 [@Lattner] to just-in-time (JIT) compile signal 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 formalized abstractions that reduce black-boxing. **Faust** [@Orlarey2009], for example, 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.
 
-Languages like **Kronos** [@noriloKronosReimaginingMusical2016] and **mimium** [@matsuura2021], which are based on the more general computational model of lambda calculus, focus on PCM-based signal processing while exploring interactive meta-operations on programs [@Norilo2016] and balancing self-contained semantics with interoperability with other general-purpose languages [@matsuura2024].
+Languages like **Kronos** [@norilo2015] and **mimium** [@matsuura_mimium_2021], which are based on the more general computational model of lambda calculus, focus on PCM-based signal processing while exploring interactive meta-operations on programs [@Norilo2016] and balancing self-contained semantics with interoperability with other general-purpose languages [@matsuura_lambda-mmm_2024].
 
 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 general-purpose programming languages.
 
@@ -194,7 +194,7 @@ For this reason, future research on programming languages for music must address
 
 It has been noted in programming language research that evaluation criteria such as efficiency, expressiveness, and generality are often ambiguous [@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 [@McPherson2020], we need to develop and share a vocabulary for understanding the value judgments we make about programming languages in general.
 
-In a broader sense, the creation of programming languages for music has also expanded to the individual level. Examples include **Gwion** by Astor, which builds on ChucK and enhances its abstraction capabilities with features like lambda functions [@astorGwion2017]; **Vult**, a DSP transpiler language created by Ruiz for his modular synthesizer hardware [@ruizVultLanguage2020]; and a UGen-based live coding environment designed for web execution, **Glicol** [@lan_glicol_2020]. However, these efforts have not yet been adequately integrated into academic discourse.
+In a broader sense, the creation of programming languages for music has also expanded to the individual level. Examples include **Gwion** by Astor, which builds on ChucK and enhances its abstraction capabilities with features like lambda functions [@astor_gwion_2017]; **Vult**, a DSP transpiler language created by Ruiz for his modular synthesizer hardware [@ruiz_vult_2020]; and a UGen-based live coding environment designed for web execution, **Glicol** [@lan_glicol_2020]. However, these efforts have not yet been adequately integrated 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 *Inside Computer Music*, which analyzes historical works of computer music, have begun [@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.
 

main.tex

@@ -32,7 +32,7 @@
 % ================ Define title and author names here ===============
 % ====================================================
 %user defined variables
-\def\papertitle{Defining Programming languages for Music through the view of ``Somewhat Weak'' Computer Music}
+\def\papertitle{Hiding What to Who? : A Critical Review of the History in Programming languages for Music}
 % \def\firstauthor{Tomoya Matsuura}
 \def\firstauthor{Anonymized for review}
 
@@ -225,7 +225,7 @@
 \input{content.tex}
 
 \begin{acknowledgments}
-At the end of the Conclusions, acknowledgments to people, projects, funding agencies, etc. can be included after the second-level heading ``Acknowledgments'' (with no numbering).
+anonymized for the review.
 \end{acknowledgments} 
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%