Flocking: a Framework for Declarative Music-Making on the Web
Total Page:16
File Type:pdf, Size:1020Kb
Proceedings ICMC|SMC|2014 14-20 September 2014, Athens, Greece Flocking: A Framework for Declarative Music-Making on the Web Colin Clark Adam Tindale OCAD University OCAD University [email protected] [email protected] ABSTRACT JavaScript. As artists and musicians increasingly use net- worked devices, sensors, and collaboration in their work, Flocking 1 is a framework for audio synthesis and mu- these limitations take an increasing toll on the complexity sic composition written in JavaScript. It takes a unique and scalability of creative coding. approach to solving several of the common architectural Flocking is an open source JavaScript framework that problems faced by computer music environments, empha- aims to address some of these concerns by connecting mu- sizing a declarative style that is closely aligned with the sicians and artists with the cross-platform, distributed de- principles of the web. livery model of the web, and with the larger pool of li- Flocking’s goal is to enable the growth of an ecosys- braries, user interface components, and tutorials that are tem of tools that can easily parse and understand the logic available to the web development community. Further, and semantics of digital instruments by representing the it emphasizes an approach to interoperability in which basic building blocks of synthesis declaratively. This is declarative instruments and compositions can be broadly particularly useful for supporting generative composition shared, manipulated, and extended across traditional tech- (where programs generate new instruments and scores al- nical subcultural boundaries. gorithmically), graphical tools (for programmers and non- programmers alike to collaborate), and new modes of so- cial programming that allow musicians to easily adapt, ex- 1.1 Interoperability in Context tend, and rework existing instruments without having to A primary motivating concern for Flocking is that the “fork” their code. tendency towards music-specific programming languages Flocking provides a robust, optimized, and well-tested ar- shifts focus away from interoperability amongst tools and chitecture that explicitly supports extensibility and long- systems. The term “interoperability” is used here to de- term growth. Flocking runs in nearly any modern scribe a specific concept: the ability to share a single in- JavaScript environment, including desktop and mobile stance of a computer music artifact (i.e. an instrument or browsers (Chrome, Firefox, and Safari), as well as on em- score) bidirectionally amongst human coders, generative bedded devices with Node.js. or transformational algorithms, and authoring or graphi- cal tools. Bidirectionality implies that a software artifact 1. INTRODUCTION needs to preserve sufficient semantics and landmarks that it can be inspected, overridden, and extended by humans A prominent stream in computer music research over the and programs not only at creation time but throughout the past few decades has focused on the creation of special- process of being used and maintained. ized languages for expressing musical and time-based con- Today, a prospective computer musician often must structs programmatically [1, 2, 3, 4]. This emphasis on choose from the outset whether or not she wants to use a new forms of syntax and language-level expression has code-based environment (such as SuperCollider or ChucK) produced noteworthy computer music environments and or a graphical one (Max/MSP, Pd, or AudioMulch, for ex- useful results for many use cases such as live coding. ample). Since imperative programming code can’t eas- Nonetheless, there is also a risk associated with the prolif- ily be parsed, generated, and understood by tools outside eration of isolated, specialist programming languages for the chosen environment, the code and graphical paradigms music and art: an increased gap between creative coders rarely interoperate. This compounds the difficulty of col- and the resources available to mainstream software de- laborating on a musical project across modalities. velopers. For example, in many self-contained computer Interoperability amongst computer music systems has music environments, it continues to be difficult to cre- been addressed in a number of ways and to varying de- ate polished user interfaces or to connect with web-based grees. Open Sound Control [5], for example, helps sup- services and sources of data—tasks that are routinely ad- port cross-system, message-based interoperability at run- dressed in mainstream programming environments such as time. Some graphical environments such as Max and Pd 1 http://flockingjs.org/ support the embedding of programmatic “externals” within an otherwise graphical instrument. FAUST offers unidirec- Copyright: c 2014 Colin Clark et al. This is an open-access article distributed tional code generators for a variety of target languages, en- under the terms of the Creative Commons Attribution 3.0 Unported License, which abling programs to be written in the FAUST language but permits unrestricted use, distribution, and reproduction in any medium, provided deployed within other environments. The Music-N fam- the original author and source are credited. ily’s simple textual format has fostered a variety of third- - 1550 - Proceedings ICMC|SMC|2014 14-20 September 2014, Athens, Greece party compositional tools that can process and generate Flocking score and orchestra files. UGen User Some computer music environments also provide APIs Input for manipulating the language’s parsing and compila- Synth UGen tion artifacts. One of CSound 6’s new features includes Web Audio API an abstract syntax tree API, enabling a user to write C Script Audio Processor strategy Enviro UGen code that manipulates an orchestra prior to compilation Node [6]. Max/MSP’s Patcher API supports the programmatic connected to traversal and generation of a Max patch using Java or Synth UGen JavaScript code 2 . Lisp-based languages such as Extem- Scheduler pore go further towards potential interoperability, provid- UGen ing macro systems that allow for more robust generative al- gorithms to be created within the facilities of the language itself. Figure 1. A diagram showing Flocking’s primary com- Within this context, Flocking aims to provide a frame- ponents and how they relate to each other and to the Web work that supports extended interoperability via a declar- Audio API. ative programming model where the intentions of code are expressed as JavaScript Object Notation (JSON) data structures. JSON is a subset of the JavaScript language 2.2 Declarative Programming 3 that is used widely across the web for exchanging data . Above, we described Flocking as a declarative framework. Flocking’s approach combines metaprogramming with an This characteristic is essential to understanding its design. emphasis on publically-visible state and structural land- Declarative programming can be understood in the context marks that help to support the alignment, sharing, and of Flocking as having two essential aspects: extension of musical artifacts across communities of pro- grammers and tools. 1. it emphasizes a high-level, semantic view of a pro- gram’s logic and structure 2. HOW FLOCKING WORKS 2. it represents programs as data structures that can be 2.1 The Framework understood by other programs The core of the Flocking framework consists of several J.W. Lloyd informally describes declarative program- interconnected components that provide the essential be- ming as “stating what is to be computed but not neces- haviour of interpreting and instantiating unit generators, sarily how it is to be computed” [7]. The emphasis here is producing streams of samples, and scheduling changes. on the logical or semantic aspects of computation, rather Flocking’s primary components include: than on low-level sequencing and control flow. Traditional imperative programming styles are typically intended for 1. the Flocking interpreter, which parses and instanti- an “audience of one”—the compiler. Though code is of- ates synths, unit generators, and buffers ten shared amongst multiple developers, it can’t typically 2. the Environment, which represents the overall audio be understood or manipulated by programs other than the system and its configuration settings compiler. In contrast, declarative programming involves the abil- 3. Audio Strategies, which are pluggable audio output ity to write programs that are represented in a format that adaptors (binding to backends such as the Web Au- can be processed by other programs as ordinary data. The dio API or ALSA on Node.js) Lisp family of languages are a well-known example of this approach. Paul Graham describes the declarative nature 4. Unit Generators (ugens), which are the sample- of Lisp, saying it “has no syntax. You write programs in generating primitives used to produce sound the parse trees... [that] are fully accessible to your pro- grams. You can write programs that manipulate them... 5. Synths, which represent instruments and collections programs that write programs.” Though Flocking is writ- of signal-generating logic ten in ordinary JavaScript, it shares with Lisp the approach 6. the Scheduler, which manages time-based change of expressing programs within data structures that are fully events on a synth available for manipulation by other programs. Figure 1 shows the runtime relationships between these 2.3 JSON components, showing an example of how multiple synths The key to Flocking’s declarative approach is JSON, the and unit generators are composed into