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

updated references

Browse Source
This commit is contained in:
松浦 知也 Matsuura Tomoya
2025-01-28 08:18:45 +00:00
parent 176122d4c1
commit 89f37284e4
5 changed files with 88 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
main.md
View File

@@ -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.