# Functors for Music: The Rubato Composer System

Skip other details (including permanent urls, DOI, citation information)This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 3.0 License. Please contact mpub-help@umich.edu to use this work in a way not covered by the license. :

For more information, read Michigan Publishing's access and usage policy.

Page 00000083 Functors for Music: The Rubato Composer System Guerino Mazzola and Gerard Milmeister Department of Informatics, University of Zurich guerino @ mazzola.ch milmei @ ifi.unizh.ch Abstract In abstract mathematical music theory, the data format of denotators is associated with set-valued presheaves over module categories. In this paper, we present an implementation of this concept framework in the Rubato Composer system, a Java application comprising a GUIfor manipulation and combination of rubettes. These are plug-ins that can be added and connected for communication of denotator data. Rubato Composer is a GPL software and is accessible to the computer music community for download and collaboration. In this paper the functionality, architecture, concept framework, and the implemented mathematical operators are presented and illustrated with a "functorial composition ". 1 Introduction In 1984, the principles of a music composition software were presented to Herbert von Karajan and led to the Atariapplication' presto~, used for the creation of a number of fullfledged compositions, e.g., the jazz CD SYNTHESIS (Mazzola 1991). In the sequel, our research has focused on a comprehensive environment RUBATO~ for analysis, performance, and composition, including plug-ins for specific tasks. Such a plug-in is called RUBETTE~, and we managed to realize rubettes for rhythmical, melodic, and harmonic analysis, as well as a rubette for expressive performance and one for prima-vista operations. Originally, these implementations ran on NEXTSTEP and were later ported to Mac OS X. See the Rubato homepage www. rubato.org for the different Rubato implementations and documentation. Rubato has been applied to musicological research, which is documented in ICMC papers (Mazzola and Zahorka 1994; Mazzola 1995; Zahorka 1995; Mazzola and Stange-Elbe 1995; Mazzola and Miiller 2003; Buteau 2005; Volk 2005), papers on other conferences (Buteau 2004; G6ller and Milmeister 2004; Miiller 2004; Garbers and Noll 2004; Garbers 2004), and in the systematic context of a comprehensive theory (Mazzola 2002). 1shareware, accessible via tamw. atari-users.net/presto. htm However, the compositional components of Rubato have not been implemented in the NEXTSTEP and Mac OS X versions. In the present implementation, called Rubato Composer, which is a Java application, the original presto features are reconsidered and implemented within the framework of functorial mathematical music theory as described in (Mazzola 2002). This gives the compositional tools an unprecedented conceptual power. Intuitively, complex musical objects, such as dodecaphonic series, chords consisting not of ordinary notes, but of collections of melodies, or ornaments of rhythmic patterns, and, more generally, macro-object constructions in the spirit of Schenker, can be handled as if they were ordinary notes. In his introduction to the OpenMusic book (Agon, Assayag, and Besson 2006), Miller Puckette notes: "In the future, computer music in general will have to deal with high-dimensional objects such as would specify a timbre. The dimensionality of a set such as the 'set of all possible sounds' is probably not even well defined. New techniques will be needed to describe and manipulate such quantities." We propose the present denotator concept as a three-way approach to the solution of the problems described by Puckette: (1) The introduction of addressed denotators, enabling the control of arbitrarily parametrized objects; (2) the construction of arbitrary finite limits, e.g., direct sums of modules; (3) the definition of circular concepts of arbitrary depth, used in FM synthesis, for example. The analytical and performance-theoretical tools of the preceding Rubato implementations will be reimplemented in the near future. For the time being, we focus on composition. After an overview of the functionality and architecture, we describe the universal space concept of forms and their 'points', the denotators. We then describe their implementation in Rubato Composer and give examples of denotator constructions. Next, we describe the functorial operations and illustrate their musical signification. The paper concludes with the explicit construction of a simple composition on the basis of the functorial concept framework. 83

Page 00000084 2 Overview The Rubato Composer system follows the classical Rubato architecture (Mazzola and Zahorka 1994): A frame application hosts a number of instantiated plug-ins, the rubettes, which perform specialized tasks. By means of a graphical user interface, rubettes are connected through input and output slots in networks. To this end, they are dragged from a repository onto a canvas representing the network, see figure 1. suspicion that many tasks in special rubettes can be decomposed into standard procedures of a logical and geometric nature. In the present setup, the functionality of rubettes is not straitjacketed into such a rigid categorization. The main objective is reuse via the universal denotator interface. This component-oriented principle dissolves the original logicogeometric operator group since any rubette may define components of this type. But it also externalizes a number of functionalities which were hardcoded in the original Metro-, Melo-, or Performance-rubettes. The difference to general component architectures is that denotators present a clear formal conceptualization and therefore offers an interoperability beyond ad hoc interfaces. 2.2 Architecture The Rubato Composer GUI and the Rubato framework are completely implemented in pure Java (JDK version 1.5), using various standard components of the JDK such as Swing for the graphical user interface, XML for the file data format and the Sound and MIDI APIs for score playing. Figure 2 visualizes the most important parts of the architecture. Composer GUI Rubette Tools for Denotators and Forms Form /Denotator Address Simple/Limit/Colimit/Power/List Diagram Module ModuleElement ModuleMorphism JDK (1.5) (XML, Swing, Sound, MIDI) Figure 2: The architecture of Rubato Composer. The bottom to top direction of the diagram reflects the passage from lower to higher levels in the architecture itself. Thus, at the bottom is the general implementation system, the JDK. The first level of Rubato Composer proper consists of the triple hierarchy of mathematical modules, elements of module spaces, and morphisms between them. The italic Figure 1: The Rubato Composer network window. The distinctive feature of this network system is that the inter-rubette communication is performed via the denotator data format exclusively. This normalization is not restrictive at all since denotators realize a universal typology, which is endorsed by the most-advanced contemporary mathematics, viz. topos theory. Therefore, communication among rubettes uses a comprehensive language which fits in the mathematical universe. In this paper, we want to demonstrate that even the most abstract category theory of functors generated by the Yoneda embedding is canonically accessible on the basis of denotators. We also want to show that such tools are of practical use to composers and music theorists alike. 2.1 Functionality A priori, the functionality of rubettes is only limited by the programmer's skill. The essential difference to the original rubette concept is the following. In the original context, we had four types of rubette tasks in mind: (1) analysis, (2) composition, (3) performance, and (4) logico-geometric operators. The fourth group was born from the insight or rather 84

Page 00000085 typeface in this picture indicates the existence of a class or an interface of the same name. The background of this part is discussed in section 3.2. On this concrete foundation sits the implementation of the core of Rubato Composer, namely denotators and forms. Section 3.1 deals with the details of this part. These classes are supplemented by tools for creating and manipulating forms and denotators, such as, for example, Boolean operations on denotators of type Power. The last level, most visible to application-oriented users, contains the implementation of Rubato Composer GUI including the rubette Java interface and a number of core rubettes. Essentially, the rubette interface exhibits several methods that define the operation of a rubette, namely the flow of data (denotators) from input to output. Additional, but optional, features include the definition of documentation strings and the export of a properties dialog to customize settings, as well as a view dialog for audio-visual representation of the process data. 3 Universal Spaces: Forms and Denotators Forms and denotators are the data format on which Rubato communication is based. This format is the conceptual basis of mathematical music theory. We refer to (Mazzola 2002; Mazzola 2004), where this setup has been described in extenso. We first discuss the general concept architecture (section 3.1) and the present the mathematical basis (section 3.2). 3.1 Forms, Denotators and their Implementation Forms The space format is called a form. The form F is specified by the expression NameF: IdF.TypeF(DiaF). The form name NameF is a denotator (to be defined below), the form identifier IdF is a monomorphism IdF: SpaceF FrameF of presheaves2, TypeF is one of four types: Simple, Limit, Colimit, or Power. And DiaF is a diagram of forms3. Depending on the type, the data is specified as follows. 2Presheaves are contravariant functors P:Mod -~Sets from the category Mod of modules and diaffine morphisms into the category Sets of setS 31f F, G are two forms, a morphism f: F -~G is by definition a natural transformation of their underlying spaces. For those readers that are not completely familiar with the mathematics and its notation used here, statements are included that point to the analoguous constructs of the data type model in the programming language Pascal and XML. Type Simple: The diagram degenerates to a module M, standing for the representable presheaf Hom(-, M) = @M. This space type is the mathematical basis. In Pascal, this corresponds to the primitive datatypes such character, integer, or real, but also arrays of such primitive data types. But notice, that type Simple is much more comprehensive, for example, there are also polynomials. We shall describe the category of modules and its implementation in section 3.2. In XML, only character data (PCDATA) are primitive. Type Limit: FrameF is the limit of the form spaces of the given diagram. In particular, if the diagram is discrete (i.e. no arrows), then we have the Cartesian product of a list of factors, representing a conjunction of attributes. The Pascal analogue is the record data type, which is equivalent to the special case of the Cartesian product. In the XML content model, it is known as the sequence type. If arrows are present in the diagram, the limit construction formalizes constraints upon the coordinates of the Cartesian product. This is in fact akin to constraint programming. Type Colimit: FrameF is the colimit of the form spaces of the given diagram. In particular, if the diagram is discrete (i.e. no arrows), then we have the disjoint union of a list of cofactors, representing a disjunction of attributes. In Pascal, there exists a variant record data type, which discriminates on an additional record field and corresponds to the special case of the colimit as a disjoint union. The DTD specification of XML calls this the choice type. The presence of arrows creates glueing condition on the cofactors. Type Power: The diagram has a single vertex form G and no arrow. The frame space is FrameF = SpaceG, where Q is the subobject classifier4. This corresponds to a collection of instances (i.e., denotators, see below) of the basic form G. Sets are not generally available in Pascal, except for the special case of a bitset, i.e., a data type of subsets of the set of integer values from 0 to 31. In XML, this type is absent. Denotators Based upon these form types, a denotator D is an instance of such a space given by the following data: NameD:AddD @FormD (CoordD). Here, the denotator name NameD is again a denotator, the address AddD iS a module A, the FormD iS a form F, and the 4At a given address A, this presheaf has the set of sieves, i.e., the subpresheaves of the representable presheaf @A: A@Q Sub( @A). 85

Page 00000086 coordinate CoordD is an element of the evaluation A @ SpaceF of the form space SpaceF of the form F of D. Observe that the definition of forms and denotators is circular in that names of forms are denotators, while denotators refer to forms. Most programming languages, including Java, accept circular definitions. However, for the implementation of these data types, circularity has two aspects: The instantation of a form-object of circular type, i.e., such that in the form's diagram, the form reappears, creates no problem, whereas operationally, the instantiation of denotators of circular type may cause endless loops. Implementation The present implementation is subject to some restrictions with respect to the mathematical theory: To begin with, the modules are not available in full generality, see the following section 3.2. Moreover, the instantiation of general Limit and Colimit typed forms is possible, but the exhibition of denotators of such forms becomes difficult if constraints or glueing conditions by diagram arrows are imposed. Currently, routines for the treatment of such constraints are not yet implemented. The novelty of the present implementation is the fairly complete realization of addressed denotators, including the techniques of address changes and space morphisms. The implementation of presheaves P works for specified arguments, i.e., the definition of sets A@P as well as set maps f@P: B@P -- A@P for given mapsf: A - B of address modules. Also, the morphisms between presheaves are given address-wise, i.e., we must specify set maps A@P -A A@Q for given presheaves P, Q in order to define a morphism P - Q. Although the definition of presheaf morphisms is not feasible in complete generality, a number of cases can be realized. To begin with, the Yoneda lemma guarantees that morphismsf: @M -- @N are bijectively related to morphisms of the underlying modules, i.e., f = @g for precisely one diaffine morphism g: M -- N. Moreover, any morphismf: colim D -- F is universally defined by the associated inductive system of morphisms f: D, -- F, whereas a morphism f: F - lim D is universally determined by its associated projective system f: F - D,. Conversely, one may define morphisms f: F - colim D by a factorization through one of the spaces 2D, and morphisms f: lim D -- F may be defined through the factorization via one of the projection spaces D,. Although this is not the general solution, we get universally defined morphisms. For example, all affine morphisms f: ~ Mi - Nj between finite direct sums of modules can be constructed by the universal properties of limits and colimits. Moreover, in the present implementation, some general, not necessarily affine, set maps can be constructed, e.g., polynomial maps, thereby invoking the larger category of modules and set maps. In contrast to the affine case, this was done without systematically accounting for category theory. With respect to the Power type forms, a very special, but usually sufficient case of denotators can be constructed: The general A-addressed denotator D with the form NameF: IdF.Power(G) has the coordinate c e A@QSpaceG = Sub(@A x Spacec). It can be shown (Mazzola 2002, ch. 7.3) that every set S of A-addressed denotators in G gives rise to a so-called objective subpresheaf S of @A x SpaceG. Coordinates of shape c = S can be constructed in the present implementation. Construction of Forms and Denotators in Rubato Composer In the discussion of the architecture (section 2.2) a collection of tools on the programming level for comfortable construction of forms and denotators is mentioned. The Rubato Composer GUI exposes a user interface to these tools. As an example consider the construction of a form of type Limit with several factors, say already defined forms with names E (onset, type Simple with module R), H (pitch, type Simple with module Q), L (loudness, type Simple with module Z) and dE (duration, type Simple with module R). Then the dialog for the construction of a form called F looks like figure 3. Figure 3: The form construction dialog. The structure of the dialog is mostly self-explaining. One first selects the type of the form to create. The layout changes according to this choice. In the case of type Limit the factor 86

Page 00000087 forms are added from a list of already defined forms (button Add) or newly created ones (Add new). The order can be changed using the Up and Down. Optionally a label may be assigned to a factor for easier referencing, here these are, in order, onset, pitch, loudness, and duration. Figure 3 also shows how one could enrich the diagram of the Limit form: A domain (From list) and a codomain (To list) are selected and a morphism between the two is created using Set morphism, here between the first factor E and the third factor L. Now, with the form F defined, the next step is to construct a denotator of this form. The intention is to build a Z 1-addressed denotator, therefore, the module of the form H being Q, a morphism m: Z11 - Q needs to be defined. To this end the module morphism builder tool is used (figure 4). constant morphisms are used. Figure 5 shows the construction of the simple denotator hi with form H. After the form H for the new denotator has been chosen, the address type is set to non-null and the previously defined morphism m is selected. Only those morphisms compatible with the form (in this case only those with codomain Q, the module of the form H) are shown in the list. Denotators el of form E, 11 of form L and del of form 9E are created similarly. Figure 4: The module morphism construction dialog. Figure 6: The Limit denotator construction dialog. The last step is the definition of the denotator nl of form F (figure 6) and is straightforward from the above discussion. 3.2 The Module Category and its Implementation The mathematics as implemented in Rubato Composer comprises the rings Z, Zn, Q, R, C, of integers, modular integers, rationals, reals, and complexes, as well as word monoids (Unicode) over the alphabet Unicode (effectively strings with Unicode characters) and monoid algebras R(Unicode) over a ring R, and in particular the polynomial rings R[X] in one variable. Finally, Cartesian products R1 x...Rn of rings R,,... Rn are also supported. Given a finite sequence M1,... Mk of modules over a ring R, the direct sum M1 e... Mk can be built. In particular, the rings as one-dimensional modules over themselves give rise to free modules Rk of dimension k, for example the real vector spaces Rk. The modules are located in a class hierarchy starting from the Java interface Module. Further down the hierarchy, interfaces like FreeModule and Ring are found that reflect the properties of particular types of modules. Thus, in contrast to the data types of most programming languages (Smalltalk being the most notable exception), a module in the Rubato Figure 5: The simple denotator construction dialog. The domain and codomain of the morphism are selected, then the type of morphism, here the choice is "affine morphism". The morphism with name m is of the form m(x) Ax + b, where A is an integer (1 x 11)-matrix and b an integer. Similarly a morphism Z11 - R for the form E is defined. For the two remaining forms (representing loudness and duration) 87

Page 00000088 framework is itself an object. Some module classes, such as ZRing (Z), have only the singleton instance, others, such as ZnRing (Zn), may have many instances. The Module interface exports several useful methods, including those for querying attributes, such as whether the module is a ring, or for creating objects such as the zero element in the specific module. Strictly parallel to the class hierarchy of modules, there is a hierarchy of classes representing elements in modules. These are the values, numbers and vectors, their classes reflecting the corresponding classes in the module hierarchy, for example, ZElement or FreeElement. The ModuleElement interface exports a comprehensive set of operations on module elements, such as addition and scalar multiplication. A third hierarchy is rooted at the interface ModuleMorphism and collects morphisms between modules. Diaffine morphisms feature prominently, as well as special morphisms such as complex conjugation. Morphisms may be added, composed and raised to a natural power, as long as respective domains and codomains satisfy the requirements. Although the functionality of this class framework is extensive, at least regarding module theory, it is not meant to aspire to a full-featured computer algebra system. Apart from the usual linear algebra (e.g., determinants or Gauss elimination), no algorithms for the solutions of systems are implemented, and polynomials support only the module theoretic operations as well as evaluation. Of course such functionality is useful and may be provided by a rubette that embodies a direct implementation or connects to packages such as Maple, Mathematica, or Maxima. 4 Functoriality and its Application to Musical Operations The functorial approach is a threefold methodology, providing us with a powerful toolbox for the manipulation of musical objects. First method: address changes A given denotator D with data ND: A@F(c) and any address change f B -- A are used to generate a new denotator Df with NDf: B@F(c of), whose coordinate is the image c o f of c under the map f@SpaceF. A typical example is the evaluation of a denotator at elements a e A of its address. Such an element is addressed by the constant map f: 0 - A: f(0) = a from the zero address B = 0. For example, we take A = Zn, F: Id.Limit(E, H, L, OE), the Cartesian product form composed of the four above Simple forms: E: Id.Simple(R) (onset), H: Id.Simple(Q) (pitch), L: Id.Simple(Z) (loudness), OE: Id.Simple(R) (duration), over the Z-modules Z, Q, R. If the address change is one of the canonical basis vectors ei = (0, 0,..., 0, 1,0,..., 0), i = 1,... n or the zero vector eo 0, then the n + 1 evaluations ci = Ce yield the images of the basis vectors in F. This means that we obtain a sequence of n + 1 canonical "note" denotators Di = Dei associated with the Zn-addressed denotator D. Conversely, every such n + 1-tuple (Di)i defines a unique Zn-addressed denotator D giving rise to the n + 1 -tuple, since Zn is free. Musically, this means that one may now consider n + 1-tuples of ordinary notes as one "note" living at the free address Zn. If we take as address change any automorphism f of Zn induced by a permutation of the n + 1 vectors ei, i = 0,... n, then the new denotator Cf is just a reordering of the given sequence of ordinary, i.e., zeroaddressed, notes following the given permutation. Second method: space transformations In this case, not the domain address A of D is changed, but its form space. Given a morphism h: F -- G of forms, the denotator coordinate c e A@SpaceF is mapped to a coordinate he = A@h(c) of a new denotator hD defined by NhD: A@G(hc). In our previous example, of course each projection pE: F -- E,p H: F -- H,PL: F -- L, andpOE: F -- OE gives rise to the corresponding coordinate denotators ED = ED, HD = pHD, LD = pLD, and OED = PED. A second typical example is a standard transformation in music on the form F, such as a retrograde inversion R I defined by (1) a pitch inversion I(x) = h-x on Q and (2) a time inversion R(x) t - x on R, and leaving the other coordinates fixed. This approach is in fact independent of the given address and works at any address. Therefore the musical application may be thought as an operation on A-addressed denotators as if they were ordinary zero-addressed notes. Summarizing, every couple of an address changef: B A and a form morphism h: F -- G gives rise to a new denotator hDf with address B and form G. Third method: set-theoretic constructions On Power type forms, one has the common Boolean operations C U D, C n D, and C - D for denotators C, D at the same address. Attention: absolute negation and implication of Boolean logic are not possible within the context of finite power denotators. Moreover, if a denotator D has Power type 88

Page 00000089 form F: Id.Power(G), where G is also a Power type, then the union of the elements of D (which are sets) yields a denotator U D of form G, the address being unchanged. Suppose that we are given an A-addressed denotator D in the form F. If we are given a Power-typed denotator S with Ns: B@H(c), where H: Id.Power(G) for a Simple form G with NG: Id.Simple(A), then we have c C B@A, i.e., c = {c: B -- A,... Ck: B - A} is a set of address changes from A to B. Therefore, we may apply each such change to D and then get the Power-typed denotator Ds with coordinate set {Dc1,... DCk } at address B over the form F. This method is particularly useful in order to generate zero-addressed Power-typed denotators (B = 0) from more abstract A-addressed ones. For example, the manipulation of A = Z11-addressed denotators, which may represent dodecaphonic series, will then yield sets of "ordinary notes" associated with the given series. 5 A Functorial Composition with Dodecaphonic Series It remains to demonstrate how the theoretical musings of section 4 are put into practice. The basis for the example developed presently are the forms as constructed in the example of section 3.1. However, the names are chosen to be a little longer for the sake of clarity: Pitch = H, Onset = E, Loudness = L, Duration = OE, and Note = F. Assuming that the forms have been created we proceed in several steps. The reader is invited to compare these steps to the procedures described in section 4. 1. Two Z1'-addressed denotators ni and n2 of form Note are created. To this end, a pair of denotators for each of the forms Pitch, Onset, Duration and Loudness has to be constructed. Duration and Loudness can be dealt with quickly, i.e., by using a meaningful, but for this purpose immaterial, constant morphism. For the denotators of form Onset, a diaffine morphism h: Z11 - R is defined as the composition h2 o hi, where h: Z11 -- Z, such that h (x) = Ax + b, where A = [1,2, 3, 4,5, 6,7, 8, 9, 10, 11] and b = 0, and h2: Z --R is the embedding of integers in the reals. The morphism for the pitch of the first note ni is f(x) = Afx + bf, where A = [1, -3,2, 3,5,7,4,-1, -2, -4, -5], b = 60. The pitch for the second note n2 is defined by g(X) Agx + bg, where Ag = [1,2, 3, 6, 5, 4, -1, -2, -3, -4, -5], bg = 67. 2. A Z -addressed denotator s of form Score (set of Notedenotators in a Power-type form deduced from Note) with elements ni and n2 is created. Illustrative screenshots are omitted since this was already shown above. 3. On a new network a Source rubette that outputs denotator s is placed (figure 7). Figure 7: A Source rubette. 4. To perform an inversion, a morphism I: Q --- Q is created with I(x) = 126 - x. A ModuleMap rubette is introduced that performs I on the Pitch part of s (figure 8). Figure 8: A ModuleMap rubette. 5. To perform a retrograde, a morphism R: R -- R is created with R(x) = 11 - x. Another ModuleMap rubette is placed in the network that performs R on the Onset part of the previous result. 6. The next computation involves the evaluation of the result at an address. The address space is Z11. We choose to evaluate at the basis vectors eo, el... ell using an AddressEval rubette (figure 9). The result is a set of Score denotators, i.e., a denotator of the Power-typed form ScoreSet. 7. To get a Score denotator again, the previous result is piped into a Set rubette to apply the big union operator described in section 4 (third method). 8. To make things a little more interesting, the original denotator s is evaluated at the same address and united with the transformed one through a union. 89

Page 00000090 7PZ Thwole set00000 shw 00000 re 0. 40 4................a Figu~oRUETT9 An AddesspetveinMtmacal rubette 9..Theoresl ca be.. displaye msin Onabiano. r Thewhoeau seuCs. hw in05.utfaigur 10.i nayincuig Thiseample i Sihmples but ilusregLates the Purosle' and powrofeRubato ComposIner.nBeiondl thosmplictyrdisplayonedbynth Inetworktiof ruete liesnaulotofuprecisely fRmulatedIn matemais.etvsi ahmtclMscTerp.222. AgOnC. G.ic Assnayagadk. Bso(20)ThOMCm posber's, Book, V...ol. One0). Pari tou..I MoopU TT.IPespectives in Mathematical Music Terp.3941 ps Theory, pp.n330-34. epsmsc sarik Butea, C.(2005.-Auomati-Motvic-Aalyss-Incudin Meloic Smilaity-or-Dffeent-ontor-Cadinaitie:-Aplicaton toSchumnn's 'f Forign-Lnds-an-Peope'.-I Procedingsof th Intenatioal-CoputerMusicConfeence.----International--------Computer-----Music----Association. ----- G arbers, J. (2004). U ser Participation in Softw are C onfiguration''ýýý''ýýý''ýýý'''ýý'''ýý'''ýýý''ýýý'''ýý'''ýý'''ýýý''ýýý''ýýý'''ýý'''ýýý''ýýý''ýýý'''ýý'''ýý'''ý--------- spcivsinur M:Ath ddemaialMsic Th teorp.39-1.es muicnOsndpabrdtuick te. cr~a rbt Figure 10: The complete network and the ScorePlay view. Giller, S. and G. Milmeister (2004). Distributed RUBATO: Foundation and Multimedia Rendering. In Perspectives in Mathematical Music Theory, pp. 282-299. epOs music, Osnabrtck. Mazzola, G. (1991). SYNTHESIS. Zurich: SToA music. Mazzola, G. (1995). Inverse Performance Theory. In Proceedings of the International Computer Music Conference, pp. 533 -540. International Computer Music Association. Mazzola, G. (2002). The Topos of Music. Basel: Birkhduser. Mazzola, G. (2004). Towards a Galois Theory of Concepts. In Perspectives in Mathematical Music Theory, pp. 78-88. epOs music, OsnabrUck. Mazzola, G. and S. MUller (2003). Constraint-based Shaping of Gestural Performance. In Proceedings of the International Computer Music Conference. International Computer Music Association. Mazzola, G. and J. Stange-Elbe (1995). Cooking a Canon with RUBATO-Performance Aspects of J.S. Bach's Kunst der Fuge. In Proceedings of the International Computer Music Conference, pp. 179-186. International Computer Music Association. Mazzola, G. and 0. Zahorka (1994). The RUBATO Performance Workstation on NeXTSTEP. In Proceedings of the International Computer Music Conference, pp. 102-108. International Computer Music Association. MUller, S. (2004). Parametric Gesture Curves: A Model for Gestural Performance. In Perspectives in Mathematical Music Theory, pp. 106-116. epOs music, Osnabrtck. Volk, A. (2005). Modeling a Processive Perspective on Meter in Music. In Proceedings of the International Computer Music Conference. International Computer Music Association. Zahorka, 0. (1995). PrediBase-Controlling Semantics of Symbolic Structures in Music. In Proceedings of the International Computer Music Conference, pp. 203-206. International Computer Music Association. 90