Compositional and Analytic Applications of Automated Music Notation Via Object-Oriented Programming

Total Page:16

File Type:pdf, Size:1020Kb

Compositional and Analytic Applications of Automated Music Notation Via Object-Oriented Programming UC San Diego UC San Diego Electronic Theses and Dissertations Title Compositional and analytic applications of automated music notation via object-oriented programming Permalink https://escholarship.org/uc/item/3kk9b4rv Author Trevino, Jeffrey Robert Publication Date 2013 Peer reviewed|Thesis/dissertation eScholarship.org Powered by the California Digital Library University of California UNIVERSITY OF CALIFORNIA, SAN DIEGO Compositional and Analytic Applications of Automated Music Notation via Object-oriented Programming A dissertation submitted in partial satisfaction of the requirements for the degree Doctor of Philosophy in Music by Jeffrey Robert Trevino Committee in charge: Professor Rand Steiger, Chair Professor Amy Alexander Professor Charles Curtis Professor Sheldon Nodelman Professor Miller Puckette 2013 Copyright Jeffrey Robert Trevino, 2013 All rights reserved. The dissertation of Jeffrey Robert Trevino is approved, and it is acceptable in quality and form for publication on mi- crofilm and electronically: Chair University of California, San Diego 2013 iii DEDICATION To Mom and Dad. iv EPIGRAPH Extraordinary aesthetic success based on extraordinary technology is a cruel deceit. —-Iannis Xenakis v TABLE OF CONTENTS Signature Page .................................... iii Dedication ...................................... iv Epigraph ....................................... v Table of Contents................................... vi List of Figures .................................... ix Acknowledgements ................................. xii Vita .......................................... xiii Abstract of the Dissertation . xiv Chapter 1 A Contextualized History of Object-oriented Musical Notation . 1 1.1 What is Object-oriented Programming (OOP)? . 1 1.1.1 Elements of OOP . 1 1.1.2 ANosebleed History of OOP. 6 1.2 Object-oriented Notation for Composers . 12 1.2.1 Composition as Notation . 12 1.2.2 Generative Task as an Analytic Framework . 13 1.2.3 Computational Models of Music/Composition . 14 1.2.4 Computational Models of Notation . 16 1.2.5 Object-oriented Systems . 17 1.2.6 Graphical Object-oriented Programming Systems . 19 1.3 Design Values for Automated Notation Systems, Illus- trated with the Abjad API for Formalized Score Control . 23 1.3.1 The Abjad API for Formalized Score Control . 23 1.3.2 Design Recommendations . 27 Chapter2 Computational Modeling as Analysis . 38 2.1 The Conflation of Analysis and Composition Reveals and Posits Construction . 38 2.1.1 Formalization Reveals Metaphor . 38 2.2 Reverse Engineering as Analysis: Two Case Studies in For- malized Score Control as Analysis . 40 2.2.1 Cantus in Memory of Benjamin Britten (1977-1980) by Arvo Pärt........................ 40 2.2.2 Windungen (1976) by Iannis Xenakis . 57 vi 2.3 Revealed Strengths and Weaknesses of Formalized Score Control ............................. 81 Chapter 3 Automated Notation for the Analysis of Recorded Music . 84 3.1 Background .......................... 84 3.2 Methodology for Representing Amplitude and Onset Time as Notation........................... 85 3.3 Conclusion and Future Directions for Research . 98 Chapter4 Compositional Applications . 100 4.1 Algorithmic Tendencies,2004—2008 . 101 4.1.1 Substitute Judgment (2004) for Solo Percussionist . 102 4.1.2 Binary Experiment for James Tenney (2005) for Four Contrabasses..... .... ..... .... .... 104 4.1.3 Mobile (2005) for Tenor Saxophone . 106 4.1.4 Zoetropes (2005—6) for Bass Clarinet, Cello, and Percussion ....................... 108 4.1.5 Unit for Convenience and Better Living 003 (2006) for Solo Bass Clarinet . 110 4.1.6 Mexican Apple Soda (Consumer Affect Simulation I.1) (2006) for Contrabass and Chamber Ensemble . 111 4.1.7 Mexican Apple Soda Paraphrase (2007) for Contrabass and Live Electronics. 112 4.1.8 Perfection Factory (2008) for Two Percussonists . 112 4.2 Installation and Visual Music,2009—2010 . 114 4.2.1 Algorithmically Generated Trees (2009). 114 4.2.2 Blooms (2010)...................... 116 4.3 Computer-assisted Works,2010—2013 . 119 4.3.1 Being Pollen (2010—2011) for Solo Percussion . 119 4.3.2 +/- (2011—2012) for Twenty French Horns . 121 4.3.3 The World All Around (2013) for Harp, Clarinet, and Piano.......................... 124 4.4 Conclusion........................... 128 AppendixA Code Examples . 131 A.1 Abjad Interface to Mike Solomon’s LilyPond Woodwind Diagrams As a Function, Implemented with Basic String Functions............................ 132 A.2 Abjad Interface to Mike Solomon’s LilyPond Woodwind Diagrams As a Function, Implemented with Abjad Scheme Functions............................ 133 vii A.3 Abjad Interface to Mike Solomon’s LilyPond Woodwind Diagrams As the WoodwindDiagram Class, Inheriting from Abjad’s AbjadObject Abstract Class . 134 A.4 Processing Code for Algorithmically Generated Trees ..... 143 A.5 Catalogue of Possible Entrances Into and Exits from Clar- inet Multiphonics . 155 A.6 Clarinet Solo Material Based on Multiphonic Catalogue . 160 A.7 Prepared Piano Part for The World All Around ........ 165 A.8 Harp Part for The World All Around .............. 171 A.9 Formatted Score for The World All Around .......... 174 AppendixB Score Examples . 176 B.1 Arvo Pärt’s Cantus in Memory of Benjamin Britten (1977—80) for Bell and String Orchestra, as Rendered with the Abjad APIfor Formalized Score Control . 177 B.2 Iannis Xenakis’s Windugen (1976) for Twelve Cellos, as Rendered with the Abjad API for Formalized Score Con- trol ............................... 183 B.3 Glenn Gould’s Performances of the First Movement of We- bern’s op.27 Piano Variations . 191 B.4 The World All Around (2013) for Prepared Piano, Eb Clar- inet,and Harp ......................... 196 viii LIST OF FIGURES Figure 1.1: Abjad creates notation by scripting the LilyPond typesetting pro- gram. ................................. 24 Figure1.2: Rest-delimited notes and chords. 28 Figure 1.3: Code to slur groups of rest-delimited notes and chords in PWGL/ENP............................... 28 Figure 1.4: Slurred groups of rest-delimited notes and chords. 29 Figure 1.5: A multiphonic notation, including a woodwind diagram. 33 Figure 1.6: Graphic overrides change the appearance of a woodwind diagram. 35 Figure2.1: Afont function enables custom typefaces. 41 Figure 2.2: Modeling the bell and string staffs and their names. 42 Figure2.3: Adding string staffs to a score. 43 Figure2.4: Modeling the bell part. 44 Figure2.5: Modeling pitch as a series of scalar descents. 45 Figure 2.6: Modeling the pitches: a switch system for choosing arpeggio notes. ................................. 46 Figure 2.7: Applying the arpeggio notes to the scalar descents. 47 Figure 2.8: Recursively generating most of the string parts’ rhythms. 48 Figure 2.9: Splitting durations cyclically by the duration of one bar. 48 Figure 2.10: Manual composition of pitches and rhythms after generation. 50 Figure2.11: Splitting and finishing the viola part. 51 Figure 2.12: The cello and contrabass pitches and rhythms composed to com- pletion. ................................ 52 Figure 2.13: Placing previously generated pitches and rhythms into measures. 53 Figure 2.14: Adding dynamic markings to parts via measure indexes. 54 Figure 2.15: Adding technical and expressive markings to parts via measure indexes. ................................ 55 Figure 2.16: Defining and using a custom technical marking. 56 Figure2.17: Adding rehearsal marks. 56 Figure2.18: Document layout and formatting. 57 Figure 2.19: Modeling the rotation of material through the score. 59 Figure 2.20: A function that returns a matrix of cyclic tuples to specify which staffs the rotating music should be written on. 60 Figure2.21: Modeling Xenakis’s bookended rotations. 60 Figure2.22: From single staff to rotating staffs. 61 Figure2.23: Repitching the staff as it rotates. 62 Figure 2.24: Modeling the low-level typographical habits in the rotation sec- tion. .................................. 63 Figure 2.25: Function for creating a staff of random pitches. 64 Figure 2.26: The final stage of typographical adjustment for the rotation sec- tion. .................................. 65 ix Figure2.27: The final rotation function. 66 Figure2.28: Utility functions enable rotation. 66 Figure 2.29: Modeling the score’s first rotation with the rotation function. 67 Figure 2.30: Modeling a rotation with multiple simultaneous pitches. 68 Figure 2.31: Modeling the tutti section with randomly selected sixteenth notes. ................................. 69 Figure2.32: The tutti section as single function. 70 Figure 2.33: The first section of the score as a single encapsulation. 70 Figure 2.34: Weighted probability choice functions for the first random walk section. ................................ 71 Figure 2.35: Conditional checks to determine a clef change. 72 Figure 2.36: Applying automatic clef changes to an expression. 73 Figure2.37: Adding random walk notes to the score. 74 Figure2.38: Querying and fusing trill spanners. 75 Figure 2.39: Functions for adding drones and random walks. 76 Figure 2.40: Functions for adding the random walk gesture to score, framed by drones as specified. 77 Figure2.41: The random walk section as a single function. 78 Figure 2.42: Imposing metric hierarchy by fusing chains of small durations. 79 Figure2.43: Imposing metric hierarchy on the entire score. 80 Figure2.44: Creating the score object. 81 Figure3.1: Reading recording data from file in Python. 87 Figure3.2: Processing recording data in Python. 88 Figure3.3: Reading pitch data from the
Recommended publications
  • Och Lönsamma Öppna Kommunikationssystem
    fcldüh OSI och lönsamma öppna kommunikationssystem Dokumentation av ett seminarium sammanställd av Victor S Epstein med Gunnar Sundblad Tddüh Telestyrelsen har inrättat ett anslag med syfte att medverka tiU snabb och lättillgänglig dokumentation beträffande användningen av teleanknutna informationssystem. Detta anslag förvaltas av TELDOK och skall bidraga tiU: Dokumentation vid tidigast möjliga tidpunkt av praktiska tillämpningar av teleanknutna informationssystem i arbetslivet Publicering och spridning, i förekommande fall översättning, av annars svåråtkomliga erfarenheter av teleanknutna informationssystem i arbetslivet, samt kompletteringar avsedda att öka användningsvärdet för svenska förhållanden och svenska läsare Studieresor och konferenser i direkt anknytning till arbetet med att dokumentera och sprida information beträffande praktiska tillämpningar av teleanknutna informationssystem i arbetslivet Via TELDOK är en av de skriftserier som utges av TELDOK. Via TELDOK presenterar obearbetade tillfallighetsrapporter från seminarier, studieresor osv. Hittills har utgetts: Via TELDOK 1. OSI och lönsamma öppna kommunikationssystem. Maj 1987. Av andra publikationer från TELDOK som nyligen utkommit kan nämnas: TELDOK Kapport 24. Meddelanden att använda. November 1986. TELDOK Kapport 25. Ny teleteknik i Sverige - användning i dag. November 1986. TELDOK Kapport 26. Datorstödda kunskapssystem i framtidens kontor. December 1986. TELDOK Kapport27. Inflytande och DAtorbaserade Kommunikationssystem. April 1987. TELDOK Kapport 28. Ny informationsteknologi i Japan. April 1987. TELDOK Referens dokument G. Management, usage and effects of Office Automation. April 1987. TELDOK-info 4. Att söka i databaser. Mars 1987. Publikationema kan beställas gratis dygnet runt från TeleSvar, 08-23 00 00 (med angivande av rapportnummer). Den som i fortsättningen önskar erhålla skrifter från TELDOK får automatiskt alla TELDOK Kapport och alla TELDOK-info. Ytterligare information lämnas gärna av TELDOK Kedaktionskommitté.
    [Show full text]
  • Objects, Time and Constraints in Openmusic
    OBJECTS, TIME AND CONSTRAINTS IN OPENMUSIC Carlos Agon, Gérard Assayag, Olivier Delerue, Camilo Rueda. {agonc,assayag,delerue,crueda}@ircam.fr IRCAM - 1 Pl. Stravinsky. F-75004 Paris, France. 1. Abstract OpenMusic is a object oriented visual programming environment for music composers. It is based on Macintosh CommonLisp and Common Lisp Object System. It shows several original features, such as reflexivity, metaprogrammation capacities, handling of the duality between musical time and computational time, and provides with a framework of predefined musical objects for handling sound, midi and musical notation. Common Music Notation in OpenMusic is an extension of CMN, a public domain notation package by Bill Schottstaedt [SCO98]. 2. Objects 2.1. Underlying Object Model. Broadly speaking, basic calculus for object-oriented programming inherited the approach imposed by the precursory language Simula and its followers. The tentatives to formalize this family of object models used the concepts of parametric polymorphism or true polymorphism [CaWe85]. More recently, languages based on multiple-dispatching (methods that dispatch on a product of types rather than a single type) such as CLOS [Steel90] were also formalized [Cast98], using concepts of overloading or ad-hoc polymorphism. As OpenMusic, based on CLOS, may very well be formally described in this way, we will give here a brief summary of the λ&− calculus used by [Cast98]. We restrain to the extension of λ−calculus by the concept of generic functions which is at the base of λ&−calculus. A generic function is simply a collection of simple functions (λ−abstractions), which we will call methods. We must also distinguish the simple application indicated by «.» from the application of generic functions indicated by the operator .
    [Show full text]
  • An Implementation of Python for Racket
    An Implementation of Python for Racket Pedro Palma Ramos António Menezes Leitão INESC-ID, Instituto Superior Técnico, INESC-ID, Instituto Superior Técnico, Universidade de Lisboa Universidade de Lisboa Rua Alves Redol 9 Rua Alves Redol 9 Lisboa, Portugal Lisboa, Portugal [email protected] [email protected] ABSTRACT Keywords Racket is a descendent of Scheme that is widely used as a Python; Racket; Language implementations; Compilers first language for teaching computer science. To this end, Racket provides DrRacket, a simple but pedagogic IDE. On the other hand, Python is becoming increasingly popular 1. INTRODUCTION in a variety of areas, most notably among novice program- The Racket programming language is a descendent of Scheme, mers. This paper presents an implementation of Python a language that is well-known for its use in introductory for Racket which allows programmers to use DrRacket with programming courses. Racket comes with DrRacket, a ped- Python code, as well as adding Python support for other Dr- agogic IDE [2], used in many schools around the world, as Racket based tools. Our implementation also allows Racket it provides a simple and straightforward interface aimed at programs to take advantage of Python libraries, thus signif- inexperienced programmers. Racket provides different lan- icantly enlarging the number of usable libraries in Racket. guage levels, each one supporting more advanced features, that are used in different phases of the courses, allowing Our proposed solution involves compiling Python code into students to benefit from a smoother learning curve. Fur- semantically equivalent Racket source code. For the run- thermore, Racket and DrRacket support the development of time implementation, we present two different strategies: additional programming languages [13].
    [Show full text]
  • Processing Sound and Music Description Data Using Openmusic
    PROCESSING SOUND AND MUSIC DESCRIPTION DATA USING OPENMUSIC Jean Bresson, Carlos Agon IRCAM – CNRS UMR STMS Paris, France fbresson,[email protected] ABSTRACT graphs corresponding to functional expressions. The lan- guage provides a set of graphical control structures, such as This paper deals with the processing and manipulation of iterations and conditional controls, as well as the possibility music and sound description data using functional programs to carry out other programming concepts like abstraction, in the OpenMusic visual programming environment. We go higher-order functions or recursion [4]. through several general features and present some toolkits OM includes specialized functions and data structures created in this environment for the manipulation of different designed for musical applications. The different musical or data formats (audio, MIDI, SDIF). extra-musical objects are represented by classes (as meant by object-oriented programming) and used in the visual 1. INTRODUCTION programs by means of factory boxes, i.e. boxes generating instances of these classes and allowing to access their dif- Musical information processing often requires manipulating ferent attributes (called slots). large musical or sound description data bases. Ordering, Compared to most existing visual programming envi- sorting, renaming files, automatic indexing, contents brows- ronments, OM has the particularity to run a demand-driven ing or transformations are basic operations in compositional, execution model. In this model, the user triggers execution analytical, or other experimental applications. by evaluating a box somewhere in the visual program graph, Visual music programming environments make it possi- which recursively evaluates the upstream connected boxes ble to define specialized and personalized programs and to and returns a value.
    [Show full text]
  • Common Lispworks User Guide
    LispWorks® for the Windows® Operating System Common LispWorks User Guide Version 5.1 Copyright and Trademarks Common LispWorks User Guide (Windows version) Version 5.1 February 2008 Copyright © 2008 by LispWorks Ltd. All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of LispWorks Ltd. The information in this publication is provided for information only, is subject to change without notice, and should not be construed as a commitment by LispWorks Ltd. LispWorks Ltd assumes no responsibility or liability for any errors or inaccuracies that may appear in this publication. The software described in this book is furnished under license and may only be used or copied in accordance with the terms of that license. LispWorks and KnowledgeWorks are registered trademarks of LispWorks Ltd. Adobe and PostScript are registered trademarks of Adobe Systems Incorporated. Other brand or product names are the registered trade- marks or trademarks of their respective holders. The code for walker.lisp and compute-combination-points is excerpted with permission from PCL, Copyright © 1985, 1986, 1987, 1988 Xerox Corporation. The XP Pretty Printer bears the following copyright notice, which applies to the parts of LispWorks derived therefrom: Copyright © 1989 by the Massachusetts Institute of Technology, Cambridge, Massachusetts. Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, pro- vided that this copyright and permission notice appear in all copies and supporting documentation, and that the name of M.I.T.
    [Show full text]
  • IDE User Guide Version 7.1 Copyright and Trademarks Lispworks IDE User Guide (Unix Version) Version 7.1 September 2017 Copyright © 2017 by Lispworks Ltd
    LispWorks® IDE User Guide Version 7.1 Copyright and Trademarks LispWorks IDE User Guide (Unix version) Version 7.1 September 2017 Copyright © 2017 by LispWorks Ltd. All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of LispWorks Ltd. The information in this publication is provided for information only, is subject to change without notice, and should not be construed as a commitment by LispWorks Ltd. LispWorks Ltd assumes no responsibility or liability for any errors or inaccuracies that may appear in this publication. The software described in this book is furnished under license and may only be used or copied in accordance with the terms of that license. LispWorks and KnowledgeWorks are registered trademarks of LispWorks Ltd. Adobe and PostScript are registered trademarks of Adobe Systems Incorporated. Other brand or product names are the registered trade- marks or trademarks of their respective holders. The code for walker.lisp and compute-combination-points is excerpted with permission from PCL, Copyright © 1985, 1986, 1987, 1988 Xerox Corporation. The XP Pretty Printer bears the following copyright notice, which applies to the parts of LispWorks derived therefrom: Copyright © 1989 by the Massachusetts Institute of Technology, Cambridge, Massachusetts. Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, pro- vided that this copyright and permission notice appear in all copies and supporting documentation, and that the name of M.I.T.
    [Show full text]
  • Red Hat Enterprise Linux 8 Security Hardening
    Red Hat Enterprise Linux 8 Security hardening Securing Red Hat Enterprise Linux 8 Last Updated: 2021-09-06 Red Hat Enterprise Linux 8 Security hardening Securing Red Hat Enterprise Linux 8 Legal Notice Copyright © 2021 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js ® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
    [Show full text]
  • How Lisp Systems Look Different in Proceedings of European Conference on Software Maintenance and Reengineering (CSMR 2008)
    How Lisp Systems Look Different In Proceedings of European Conference on Software Maintenance and Reengineering (CSMR 2008) Adrian Dozsa Tudor Gˆırba Radu Marinescu Politehnica University of Timis¸oara University of Berne Politehnica University of Timis¸oara Romania Switzerland Romania [email protected] [email protected] [email protected] Abstract rently used in a variety of domains, like bio-informatics (BioBike), data mining (PEPITe), knowledge-based en- Many reverse engineering approaches have been devel- gineering (Cycorp or Genworks), video games (Naughty oped to analyze software systems written in different lan- Dog), flight scheduling (ITA Software), natural language guages like C/C++ or Java. These approaches typically processing (SRI International), CAD (ICAD or OneSpace), rely on a meta-model, that is either specific for the language financial applications (American Express), web program- at hand or language independent (e.g. UML). However, one ming (Yahoo! Store or reddit.com), telecom (AT&T, British language that was hardly addressed is Lisp. While at first Telecom Labs or France Telecom R&D), electronic design sight it can be accommodated by current language inde- automation (AMD or American Microsystems) or planning pendent meta-models, Lisp has some unique features (e.g. systems (NASA’s Mars Pathfinder spacecraft mission) [16]. macros, CLOS entities) that are crucial for reverse engi- neering Lisp systems. In this paper we propose a suite of Why Lisp is Different. In spite of its almost fifty-year new visualizations that reveal the special traits of the Lisp history, and of the fact that other programming languages language and thus help in understanding complex Lisp sys- borrowed concepts from it, Lisp still presents some unique tems.
    [Show full text]
  • MOLA Guidelines for Music Preparation
    3 MOLA Guidelines for Music Preparation Foreword These guidelines for the preparation of music scores and parts are the result of many hours of discussion regarding the creation and layout of performance material that has come through our libraries. We realize that each music publisher has its own set of guidelines for music engraving. For new or self-published composers or arrangers, we would like to express our thoughts regarding the preparation of performance materials. Using notation so!ware music publishers and professional composers and arrangers are creating scores and parts that are as functional and beautiful as traditionally engraved music. " .pdf (portable document format) is the suggested final file format as it is independent of application so!ware, hardware, and operating system. "ll ma%or notation so!ware has the option to save a file in this format. "s digital storage and distribution of music data files becomes more common, there is the danger that the librarian will be obliged to assume the role of music publisher, expected to print, duplicate, and bind all of the sheet music. &ot all libraries have the facilities, sta', or time to accommodate these pro%ects, and while librarians can advise on the format and layout of printed music, they should not be expected to act as a surrogate publisher. The ma%ority of printed music is now produced using one of the established music notation so!ware programs. (ome of the guidelines that follow may well be implemented in such programs but the so!ware user, as well as anyone producing material by hand, will still find them beneficial.
    [Show full text]
  • Computer Music
    THE OXFORD HANDBOOK OF COMPUTER MUSIC Edited by ROGER T. DEAN OXFORD UNIVERSITY PRESS OXFORD UNIVERSITY PRESS Oxford University Press, Inc., publishes works that further Oxford University's objective of excellence in research, scholarship, and education. Oxford New York Auckland Cape Town Dar es Salaam Hong Kong Karachi Kuala Lumpur Madrid Melbourne Mexico City Nairobi New Delhi Shanghai Taipei Toronto With offices in Argentina Austria Brazil Chile Czech Republic France Greece Guatemala Hungary Italy Japan Poland Portugal Singapore South Korea Switzerland Thailand Turkey Ukraine Vietnam Copyright © 2009 by Oxford University Press, Inc. First published as an Oxford University Press paperback ion Published by Oxford University Press, Inc. 198 Madison Avenue, New York, New York 10016 www.oup.com Oxford is a registered trademark of Oxford University Press All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of Oxford University Press. Library of Congress Cataloging-in-Publication Data The Oxford handbook of computer music / edited by Roger T. Dean. p. cm. Includes bibliographical references and index. ISBN 978-0-19-979103-0 (alk. paper) i. Computer music—History and criticism. I. Dean, R. T. MI T 1.80.09 1009 i 1008046594 789.99 OXF tin Printed in the United Stares of America on acid-free paper CHAPTER 12 SENSOR-BASED MUSICAL INSTRUMENTS AND INTERACTIVE MUSIC ATAU TANAKA MUSICIANS, composers, and instrument builders have been fascinated by the expres- sive potential of electrical and electronic technologies since the advent of electricity itself.
    [Show full text]
  • Macaque – a Tool for Spectral Processing and Transcription
    MACAQUE – A TOOL FOR SPECTRAL PROCESSING AND TRANSCRIPTION Georg Hajdu Center for Microtonal Music and Multimedia (ZM4) Hamburg University of Music and Theater (HfMT) Harvestehuder Weg 12 20148 Hamburg [email protected] ABSTRACT act of my opera Der Sprung – Beschreibung einer Oper [7] I used the MIDI velocity information of the transcribed note This paper describes Macaque, a tool for spectral process- events to alter the size of their note heads so that the sight- ing and transcription, in development since 1996. Macaque reading musicians had instantaneous visual feedback per- was programmed in Max and, in 2013, embedded into the taining to the dynamics of the music to be performed. In MaxScore ecosystem. Its GUI offers several choices for the other instances, I have used a technique called “velocoding” processing and transcription of SDIF partial-track files into to encode microtonal pitch deviation in eighth-tone resolu- standard music notation. At the core of partial-track tran- tion into the velocity part of a MIDI note-on message to scription is an algorithm capable of “attracting” partial modify the Enigma file in such ways that the resulting score tracks (and fragments thereof) into single staves, thereby displayed the corresponding pitch alterations. Another early performing an important aspect of “spectral orchestration.” example of using Macaque is my piece Herzstück for two player pianos from 1999 which premiered at the Cologne 1. INTRODUCTION Triennale in 2000. This piece was written for two of Jürgen Hocker’s instruments which he also used to tour Conlon Macaque is a component of the MaxScore notation soft- Nancarrow’s compositions for player piano [8].
    [Show full text]
  • The Evolution of Lisp
    1 The Evolution of Lisp Guy L. Steele Jr. Richard P. Gabriel Thinking Machines Corporation Lucid, Inc. 245 First Street 707 Laurel Street Cambridge, Massachusetts 02142 Menlo Park, California 94025 Phone: (617) 234-2860 Phone: (415) 329-8400 FAX: (617) 243-4444 FAX: (415) 329-8480 E-mail: [email protected] E-mail: [email protected] Abstract Lisp is the world’s greatest programming language—or so its proponents think. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch. Overall, the evolution of Lisp has been guided more by institutional rivalry, one-upsmanship, and the glee born of technical cleverness that is characteristic of the “hacker culture” than by sober assessments of technical requirements. Nevertheless this process has eventually produced both an industrial- strength programming language, messy but powerful, and a technically pure dialect, small but powerful, that is suitable for use by programming-language theoreticians. We pick up where McCarthy’s paper in the first HOPL conference left off. We trace the development chronologically from the era of the PDP-6, through the heyday of Interlisp and MacLisp, past the ascension and decline of special purpose Lisp machines, to the present era of standardization activities. We then examine the technical evolution of a few representative language features, including both some notable successes and some notable failures, that illuminate design issues that distinguish Lisp from other programming languages. We also discuss the use of Lisp as a laboratory for designing other programming languages. We conclude with some reflections on the forces that have driven the evolution of Lisp.
    [Show full text]