Results 1 - 10
of
10
Block Jam: A Tangible Interface for Interactive Music
, 2003
"... In this paper, we introduce Block Jam, a Tangible User Interface that controls a dynamic polyrhythmic sequencer using 26 physical artifacts. These physical artifacts, that we call blocks,are anew type of input device for manipulating an interactive music system. Theblocks' functional and topological ..."
Abstract
-
Cited by 24 (0 self)
- Add to MetaCart
In this paper, we introduce Block Jam, a Tangible User Interface that controls a dynamic polyrhythmic sequencer using 26 physical artifacts. These physical artifacts, that we call blocks,are anew type of input device for manipulating an interactive music system. Theblocks' functional and topological statuses are tightly coupled to an ad hoc sequencer, interpreting the user's arrangement of the blocks as meaningful musical phrases and structures.
at Seventeen
- Computer Music Journal
, 2002
"... I have worked for many years on a computer environment for realizing works of live electronic music, which I named in honor of Max Mathews. Three currently supported computer programs—Max/MSP, Jmax, and Pd—can be considered as extended implementations of a common paradigm I’ll refer to here as “Max. ..."
Abstract
-
Cited by 14 (0 self)
- Add to MetaCart
I have worked for many years on a computer environment for realizing works of live electronic music, which I named in honor of Max Mathews. Three currently supported computer programs—Max/MSP, Jmax, and Pd—can be considered as extended implementations of a common paradigm I’ll refer to here as “Max.” The Max paradigm appears to be stable enough now that a printed description of it no longer risks becoming too quickly outdated. We can now usefully assess what Max (the paradigm) does well, what it does less well, and what we can all learn from the experience. The Dartmouth Symposium on the Future of Music Software, organized by Eric Lyon, offers a perfect occasion to start this project. I’ll apologize in advance if, for obvious reasons, parts of this article might not seem perfectly objective or impartial. The many others who have worked in or on Max in its various forms and stages should all now get a chance to voice their opinions too. The Max paradigm can be described as a way of combining pre-designed building blocks into configurations useful for real-time computer music performance.
Gestural Control of Music
"... Digital musical instruments do not depend on physical constraints faced by their acoustic counterparts, such as characteristics of tubes, membranes, strings, etc. This fact permits a huge diversity of possibilities regarding sound production, but on the other hand strategies to design and perform th ..."
Abstract
-
Cited by 12 (1 self)
- Add to MetaCart
Digital musical instruments do not depend on physical constraints faced by their acoustic counterparts, such as characteristics of tubes, membranes, strings, etc. This fact permits a huge diversity of possibilities regarding sound production, but on the other hand strategies to design and perform these new instruments need to be devised in order to provide the same level of control subtlety available in acoustic instruments. In this paper I review various topics related to gestural control of music using digital musical instruments and identify possible trends in this domain.
The Use of Hierarchy and Instance in a Data Structure for Computer Music
- Computer Music Journal
, 1978
"... ..."
Arctic: A Functional Language for Real-Time Control
- In 1984 ACM Symposium on LISP and Functional Programming
, 1984
"... Arctic is a langu-~ge for tile specification and imp!ementation of real-time control systems. Unlike more conventional languages for real-time control, which emphasize concurrency, Arctic is a stateless language in which the relationships between system inputs, outputs and intermediate terms are exp ..."
Abstract
-
Cited by 9 (3 self)
- Add to MetaCart
Arctic is a langu-~ge for tile specification and imp!ementation of real-time control systems. Unlike more conventional languages for real-time control, which emphasize concurrency, Arctic is a stateless language in which the relationships between system inputs, outputs and intermediate terms are expressed as operation. ~ on time-varying functions. Arctic allows discrete events or conditions to invoke and modify responses asynchronously, but because programs have no state, synchronization problems are greatly simplified. Furthermore, Arctic programs are non-sequential, and the timing of system responses is notated explicitly. This eliminates the need for the programmer to be concerned with the execution sequence, which accounts for much of the difficulty in real-time programming. 1.
Grammar Based Music Composition
"... L-Systems have traditionally been used as a popular method for the modelling of spacefilling curves, biological systems and morphogenesis. In this paper, we adapt string rewriting grammars based on L-Systems into a system for music composition. ..."
Abstract
-
Cited by 5 (0 self)
- Add to MetaCart
L-Systems have traditionally been used as a popular method for the modelling of spacefilling curves, biological systems and morphogenesis. In this paper, we adapt string rewriting grammars based on L-Systems into a system for music composition.
A Brief Survey of Music Representation Issues, Techniques, and Systems
"... ly, there is a mathematical function that maps beat numbers to time and an inverse function that maps time to beats. (Some special mathematical care must be taken to allow for music that momentarily stops, instantaneously skips ahead, or is allowed to jump backwards, but we will ignore these details ..."
Abstract
-
Cited by 4 (0 self)
- Add to MetaCart
ly, there is a mathematical function that maps beat numbers to time and an inverse function that maps time to beats. (Some special mathematical care must be taken to allow for music that momentarily stops, instantaneously skips ahead, or is allowed to jump backwards, but we will ignore these details.) One practical representation of the beat-to-time function is the set of times of individual beats. For example, a performer can tap beats in real time and a computer can record the time of each tap. This produces a finitely sampled representation of the continuous mapping from beats to time, which can be interpolated to obtain intermediate values. MIDI Clocks, which are transmitted at 24 clocks per quarter note, are an example of this approach. The Mockingbird score editor [Maxwell 84] interface also supported this idea. The composer would play a score, producing a piano-roll notation. Then, downbeats were indicated by clicking with a mouse at the proper locations in the piano roll score....
Expressing Temporal Behavior Declaratively
"... The programming language Arctic specifies real-time behavior declaratively by using temporal control constructs and by indicating starting times and durations explicitly, much the way timing is specified in a cue sheet or a musical score. Values in Arctic are functions of time, which may be combined ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
The programming language Arctic specifies real-time behavior declaratively by using temporal control constructs and by indicating starting times and durations explicitly, much the way timing is specified in a cue sheet or a musical score. Values in Arctic are functions of time, which may be combined with various arithmetic and logical operators. Since Arctic is a single assignment language, the execution order is implied by data dependencies, simplifying synchronization problems for the programmer. Arctic supports behavioral abstraction, in which a single program module gives rise, through various transformations, to a class of behaviors. An implementation of Arctic is described, and experience with the declarative approach to real-time control is discussed. 1. Introduction For the most part, traditional programming languages have been designed for applications where control over the timing of execution is not a primary concern. Users usually want their programs to run as fast as poss...
The Role of Time in Engineering Computer Music Systems
, 2005
"... Discussion of time in interactive computer music systems engineering has been largely limited to data acquisition rates and latency. Since music is an inherently time-based medium, we believe that time plays a more important role in both the usability and implementation of these systems. In this pap ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
Discussion of time in interactive computer music systems engineering has been largely limited to data acquisition rates and latency. Since music is an inherently time-based medium, we believe that time plays a more important role in both the usability and implementation of these systems. In this paper, we present a time design space, which we use to expose some of the challenges of developing computer music systems with time-based interaction. We describe and analyze the time-related issues we encountered whilst designing and building a series of interactive music exhibits that fall into this design space. These issues often occur because of the varying and sometimes conflicting conceptual models of time in the three domains of user, application (music), and engineering. We present some of our latest work in conducting gesture interpretation and frameworks for digital audio, which attempt to analyze and address these conflicts in temporal conceptual models.

