DOCSLIB.ORG

Flocking: a Framework for Declarative Music-Making on the Web

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Flocking: a Framework for Declarative Music-Making on the Web 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
Load more

Recommended publications
  • Flocking: a Framework for Declarative Music-Making on the Web
    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.
    [Show full text]
  • The Early History of Music Programming and Digital Synthesis, Session 20
    Chapter 20. Meeting 20, Languages: The Early History of Music Programming and Digital Synthesis 20.1. Announcements • Music Technology Case Study Final Draft due Tuesday, 24 November 20.2. Quiz • 10 Minutes 20.3. The Early Computer: History • 1942 to 1946: Atanasoff-Berry Computer, the Colossus, the Harvard Mark I, and the Electrical Numerical Integrator And Calculator (ENIAC) • 1942: Atanasoff-Berry Computer 467 Courtesy of University Archives, Library, Iowa State University of Science and Technology. Used with permission. • 1946: ENIAC unveiled at University of Pennsylvania 468 Source: US Army • Diverse and incomplete computers © Wikimedia Foundation. License CC BY-SA. This content is excluded from our Creative Commons license. For more information, see http://ocw.mit.edu/fairuse. 20.4. The Early Computer: Interface • Punchcards • 1960s: card printed for Bell Labs, for the GE 600 469 Courtesy of Douglas W. Jones. Used with permission. • Fortran cards Courtesy of Douglas W. Jones. Used with permission. 20.5. The Jacquard Loom • 1801: Joseph Jacquard invents a way of storing and recalling loom operations 470 Photo courtesy of Douglas W. Jones at the University of Iowa. 471 Photo by George H. Williams, from Wikipedia (public domain). • Multiple cards could be strung together • Based on technologies of numerous inventors from the 1700s, including the automata of Jacques Vaucanson (Riskin 2003) 20.6. Computer Languages: Then and Now • Low-level languages are closer to machine representation; high-level languages are closer to human abstractions • Low Level • Machine code: direct binary instruction • Assembly: mnemonics to machine codes • High-Level: FORTRAN • 1954: John Backus at IBM design FORmula TRANslator System • 1958: Fortran II 472 • 1977: ANSI Fortran • High-Level: C • 1972: Dennis Ritchie at Bell Laboratories • Based on B • Very High-Level: Lisp, Perl, Python, Ruby • 1958: Lisp by John McCarthy • 1987: Perl by Larry Wall • 1990: Python by Guido van Rossum • 1995: Ruby by Yukihiro “Matz” Matsumoto 20.7.
    [Show full text]
  • Real-Time Multimedia Composition Using
    Real-time Multimedia Composition using Lua W esley Smith Graham W akefield Media Arts and Technology Program Media Arts and Technology Program University of California Santa Barbara University of California Santa Barbara [email protected] [email protected] ABSTRACT 1.2 Lua In this paper, a new interface for programming multimedia compositions in Max/MSP/Jitter using the Lua scripting Lua is a powerful, efficient scripting language based on language is presented. Lua is extensible and efficient making associative tables and functional programming techniques. it an ideal choice for designing a programmatic interface for Lua is ideally suited for real-time multimedia processing multimedia compositions. First, we discuss the distinctions because of its flexible semantics and fast performance; it is of graphical and textual interfaces for composition and the frequently used for game logic programming (e.g. World of requirements for a productive compositional workflow, and Warcraft [24]) and application extension (e.g. Adobe then we describe domain specific implementations of Lua Lightroom) [11]. bindings as Max externals for graphics and audio in that order. 1.3 jit.gl.lua and lua~ Categories and Subject Descriptors H.5.1 [Information Interfaces and Presentation] Multimedia The jit.gl.lua (for OpenGL graphics) and Lua~ (for audio DSP) Information Systems - animations; H.5.5 [Information extensions allow a new range of expressive control in which Interfaces and Presentation] Sound and Music Computing - arbitrary, dynamic data structures and behaviors can be methodologies & techniques, modeling, signal synthesis and generated, whilst interfacing with the convenient graphical processing; I.3.7 [Computer Graphics] Three-Dimensional interface and libraries of Max/MSP/Jitter.
    [Show full text]
  • SAOL: the MPEG-4 Structured Audio Orchestra Language
    Eric D. Scheirer and Barry L. Vercoe Machine Listening Group SAOL: The MPEG-4 E15-401D MIT Media Laboratory Cambridge, Massachusetts 02139-4307, USA Structured Audio [email protected] [email protected] Orchestra Language Since the beginning of the computer music era, The Motion Pictures Experts Group (MPEG), tools have been created that allow the description part of the International Standardization Organiza- of music and other organized sound as concise net- tion (ISO) finished the MPEG-4 standard, formally works of interacting oscillators and envelope func- ISO 14496, in October 1998; MPEG-4 will be des- tions. Originated by Max Mathews with his series ignated as an international standard and published of “Music N” languages (Mathews 1969), this unit in 1999. The work plan and technology of MPEG-4 generator paradigm for the creation of musical represent a departure from the previous MPEG-1 sound has proven highly effective for the creative (ISO 11172) and MPEG-2 (ISO 13818) standards. description of sound and widely useful for musi- While MPEG-4 contains capabilities similar to cians. Languages such as Csound (Vercoe 1995), MPEG-1 and MPEG-2 for the coding and compres- Nyquist (Dannenberg 1997a), CLM (Schottstaedt sion of audiovisual data, it additionally specifies 1994), and SuperCollider (McCartney 1996b) are methods for the compressed transmission of syn- widely used in academic and production studios thetic sound and computer graphics, and for the today. juxtaposition of synthetic and “natural” (com- As well as being an effective tool for marshalling pressed audio/video) material. a composer’s creative resources, these languages Within the MPEG-4 standard, there is a set of represent an unusual form of digital audio com- tools of particular interest to computer musicians pression (Vercoe, Gardner, and Scheirer 1998).
    [Show full text]
  • Computer Music (So Far)
    Computer Music (So Far) Part I. Mainframes Computers have made noises since Eniac was rolled out in 1947. It seems one of the problems with programming the early systems was knowing that everything was operating properly. That's why you see computers in 50s science fiction movies covered in lights. A common trick was to connect a loudspeaker to a key component in the main processor -- this would give tones of various pitches as data moved in and out of the accumulator. As long as a program was running, the tones would change in a random sort of way. A steady pitch meant the program was caught in a loop and needed to be shut down. That's how beedle beep became the signifier of computer operation. The first real music program was written by Max Mathews in the early 1960s. He was working at Bell labs, a research center run by AT&T when they were the phone company. Max was primarily developing more practical things for the phone company (he invented the little square plug, for instance). But he worked on music software in his spare time. He called his software MUSIC, with the different versions indicated by Roman numerals. MUSIC made its first sound in 1957, playing single line tunes. MUSIC II, a year later, had four part polyphony. These ran on the most powerful computer of the day, and took something like an hour of computing time to generate a minute of music. The sound was similar to the tunes played by some wristwatches today. In 1960, MUSIC III introduced the concept of a "unit generator", a subroutine that would create a specific kind of sound and only needed a few numbers from the composer.
    [Show full text]
  • Towards a Functional-Aesthetic Sonification Design Framework A
    Composing and Decomposing Electroacoustic Sonifications: Towards a Functional-Aesthetic Sonification Design Framework A Dissertation Presented to The Academic Faculty by Takahiko Tsuchiya In Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy in the School of Music Georgia Institute of Technology May 2021 Copyright © 2021 by Takahiko Tsuchiya Composing and Decomposing Electroacoustic Sonifications: Towards a Functional-Aesthetic Sonification Design Framework Approved by: Dr. Jason Freeman, Advisor Dr. Claire Author School of Music School of Music Georgia Institute of Technology Georgia Institute of Technology Dr. Grace Leslie Dr. Hiroko Terasawa School of Music Faculty of Library, Information and Georgia Institute of Technology Media Science University of Tsukuba Dr. Carrie Bruce Date Approved: February 1, 2021 School of Interactive Computing Georgia Institute of Technology ACKNOWLEDGEMENTS This thesis was only made possible by the tremendous help from my advisors, mentors, colleagues and friends. Dr. Jason Freeman has supported me and this research for so many years with genuine care. His guidance ensured that both scientific vigor and creative / aesthetic values unique in music technology are present in this research. Dr. Grace Leslie took generous time to understand my research goals and complexity, providing many practical advices and resources for the experimental design. Dr. Claire Author shared with me examples on conducting an online listening test as well as meticulous feedback on the manuscript. Dr. Carrie Bruce was also extremely helpful with constructive suggestions and insights on qualitative user studies. Perhaps more importantly, she first introduced me to a sonification project that ultimately grew into the present thesis. Dr. Hiroko Terasawa’s research in timbre and sonification was a direct inspiration for my thesis.
    [Show full text]
  • A Declarative Metaprogramming Language for Digital Signal
    Vesa Norilo Kronos: A Declarative Centre for Music and Technology University of Arts Helsinki, Sibelius Academy Metaprogramming PO Box 30 FI-00097 Uniarts, Finland Language for Digital [email protected] Signal Processing Abstract: Kronos is a signal-processing programming language based on the principles of semifunctional reactive systems. It is aimed at efficient signal processing at the elementary level, and built to scale towards higher-level tasks by utilizing the powerful programming paradigms of “metaprogramming” and reactive multirate systems. The Kronos language features expressive source code as well as a streamlined, efficient runtime. The programming model presented is adaptable for both sample-stream and event processing, offering a cleanly functional programming paradigm for a wide range of musical signal-processing problems, exemplified herein by a selection and discussion of code examples. Signal processing is fundamental to most areas handful of simple concepts. This language is a good of creative music technology. It is deployed on fit for hardware—ranging from CPUs to GPUs and both commodity computers and specialized sound- even custom-made DSP chips—but unpleasant for processing hardware to accomplish transformation humans to work in. Human programmers are instead and synthesis of musical signals. Programming these presented with a very high-level metalanguage, processors has proven resistant to the advances in which is compiled into the lower-level data flow. general computer science. Most signal processors This programming method is called Kronos. are programmed in low-level languages, such as C, often thinly wrapped in rudimentary C++. Such a workflow involves a great deal of tedious detail, as Musical Programming Paradigms these languages do not feature language constructs and Environments that would enable a sufficiently efficient imple- mentation of abstractions that would adequately The most prominent programming paradigm for generalize signal processing.
    [Show full text]
  • Deubois New Edit
    Extension 5: Sound Text by R. Luke DuBois Excerpt from Processing: a programming handbook for visual designers and artists Casey Reas and Ben Fry The history of music is, in many ways, the history of technology. From developments in the writing and transcription of music (notation) to the design of spaces for the performance of music (acoustics) to the creation of musical instruments, composers and musicians have availed themselves of advances in human understanding to perfect and advance their professions. Unsurprisingly, therefore, we find that in the machine age these same people found themselves first in line to take advantage of the new techniques and possibilities offered by electricity, telecommunications, and, in the last century, digital computers to leverage all of these systems to create new and expressive forms of sonic art. Indeed, the development of phonography (the ability to reproduce sound mechanically) has, by itself, had such a transformative effect on aural culture that it seems inconceivable now to step back to an age where sound could emanate only from its original source. The ability to create, manipulate, and losslessly reproduce sound by digital means is having, at the time of this writing, an equally revolutionary effect on how we listen. As a result, the artist today working with sound has not only a huge array of tools to work with, but also a medium exceptionally well suited to technological experimentation. Composers adopted digital computers slowly as a creative tool because of their initial lack of real‐time responsiveness and intuitive interface. Although the first documented use of the computer to make music occurred in 1951 on the CSIRAC machine in Sydney, Australia, the genesis of most foundational technology in computer music as we know it today came when Max Mathews, a researcher at Bell Labs in the United States, developed a piece of software for the IBM 704 mainframe called MUSIC.
    [Show full text]
  • Computational Composition Strategies in Audiovisual Laptop Performance
    Computational composition strategies in audiovisual laptop performance Alo Allik The University of Hull This thesis is submitted for the degree of Doctor of Philosophy to accompany a portfolio of audiovisual performances and the software systems used in the creation of these works PhD supervisors: Dr. Robert Mackay and Dr. Joseph Anderson This project was supported by the University of Hull 80th Anniversary Scholarship. April 2014 Acknowledgements I would like to take this opportunity to thank everyone who has supported this project throughout its duration. I am very grateful to my supervisor Rob Mackay who not only has been a very supportive and knowledgeable mentor, but also an amazingly accommodating friend during my time at the Creative Music Technology program at the University Hull Scarborough campus. I am also indebted to my first supervisor Jo Anderson for encouragement, lengthy conversations and in-depth knowledge, particularly in Ambisonic spatializa- tion, allowing me to test the early versions of the Ambisonic Toolkit. This project would not have been possible without the University of Hull funding this project over the course of 3 years and providing means to attend the ISEA symposium in Istanbul. I am grateful for the financial support from the School of Arts and New Media for attending conferences - NIME in Oslo, IFIMPAC in Leeds, and ICMC in Ljubljana - which has provided opportunities to present aspects of this research in the UK and abroad. These experiences proved to be instrumental in shaping the final outcome of this project. I owe a great deal to the dedication and brilliance of the performers and collaborators Andrea Young, Satoshi Shiraishi, and Yota Morimoto, the latter two also for sowing the seeds for my interest and passion for audiovisual per- formances while working together on ibitsu.
    [Show full text]
  • Chugens, Chubgraphs, Chugins: 3 Tiers for Extending Chuck
    CHUGENS, CHUBGRAPHS, CHUGINS: 3 TIERS FOR EXTENDING CHUCK Spencer Salazar Ge Wang Center for Computer Research in Music and Acoustics Stanford University {spencer, ge}@stanford.edu ABSTRACT native compiled code, which is precisely the intent of ChuGins. The ChucK programming language lacks straightforward mechanisms for extension beyond its 2. RELATED WORK built-in programming and processing facilities. Chugens address this issue by allowing programmers to Extensibility is a primary concern of music software of implement new unit generators in ChucK code in real- all varieties. The popular audio programming time. Chubgraphs also allow new unit generators to be environments Max/MSP [12], Pure Data [8], built in ChucK, by defining specific arrangements of SuperCollider [6], and Csound [4] all provide mechanisms for developing C/C++-based compiled existing unit generators. ChuGins allow a wide array of sound processing functions. Max also allows control-rate high-performance unit generators and general functionality to be encapsulated in-situ in the form of functionality to be exposed in ChucK by providing a Javascript code snippets. Csound allows the execution of dynamic binding between ChucK and native C/C++- Tcl, Lua, and Python code for control-rate and/or audio- based compiled code. Performance and code analysis rate manipulation and synthesis. A thriving ecosystem shows that the most suitable approach for extending revolves around extensions to popular digital audio workstation software, in the form of VST, RTAS, ChucK is situation-dependent. AudioUnits, and LADSPA plugins developed primarily in C and C++. In general-purpose computing 1. INTRODUCTION enivornments, JNI provides a highly flexible binding between native machine code and the Java virtual Since its introduction, the ChucK programming machine-based run-time environment [5].
    [Show full text]
  • Subsynth: a Generic Audio Synthesis Framework for Real-Time Applications
    Iowa State University Capstones, Theses and Retrospective Theses and Dissertations Dissertations 1-1-2002 Subsynth: A generic audio synthesis framework for real-time applications Kevin August Meinert Iowa State University Follow this and additional works at: https://lib.dr.iastate.edu/rtd Recommended Citation Meinert, Kevin August, "Subsynth: A generic audio synthesis framework for real-time applications" (2002). Retrospective Theses and Dissertations. 20166. https://lib.dr.iastate.edu/rtd/20166 This Thesis is brought to you for free and open access by the Iowa State University Capstones, Theses and Dissertations at Iowa State University Digital Repository. It has been accepted for inclusion in Retrospective Theses and Dissertations by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Subsynth: A generic audio synthesis framework for real-time applications by Kevin August Meinert A thesis submitted to the graduate faculty in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE Major: Computer Engineering Program of Study Committee: Carolina Cruz-Neira, Major Professor Daniel Ashlock AnneDeane Julie Dickerson Govindarasu Manimaran Iowa State University Ames, Iowa 2002 Copyright © Kevin August Meinert, 2002. All rights reserved. 11 Graduate College Iowa State University This is to certify that the master's thesis of Kevin August Meinert has met the thesis requirements of Iowa State University Signatures have been redacted for privacy
    [Show full text]
  • From Live Coding to Virtual Being
    Live Coding and Machine Listening Nick Collins Durham University, Department of Music [email protected] ABSTRACT Live coding control of machine listening processes, or more radically, machine listening control of live coding, provides an exciting area of crossover between two research frontiers in computer music. is article surveys the state of the art, and reports a number of experimental projects that point to potentially productive further directions. 1. Introduction Live coding has established itself as a viable and productive method of computer music performance and prototyping, embracing the immedicacy of modern computer programming languages (Collins et al. 2003; Ward et al. 2004; Blackwell and Collins 2005; Brown and Sorensen 2009; Collins 2011; McLean 2011; Magnusson 2014). New avenues in interfacing for programming are being embraced, including tangible computing of unit generator graphs and musical sequences (see for example Mónica Rikić’s buildacode), natural language processing (e.g., Craig Laa’s oth) and computer vision (e.g., Nik Hanselmann’s bodyfuck (2009) brainfuck interface). Performance ventures range from the current vogue for algoraves, showcasing generative and interactive creation of electronic dance music (Collins and McLean 2014) to contemporary dance and live arts. Complementing existing work, this paper explores the interaction of live coding with machine listening, from listening functionality within existing performance systems towards the use of live audio analysis as programming interface itself.
    [Show full text]