Page  243 ï~~TABULA VIGILANS Richard Orton, Ross Kirk Music Technology Group, University of York, YOI 5DD, UK EMail: rot, prkl @ uk.ac.york.vaxa Abstract Tabula Vigilans has emerged from a perceived requirement for storing, varying and controlling musical data under conditions of actual or simulated musical performance. (By 'simulated' we here refer to the many ways in which composers today can rehearse musical situations in studio conditions.) Its complenenuuy parts are block(s) of data organised as n-dimensional arrays of cells containing numerical data, and an extensible rule-set, which governs the relationships between them. The vigilant nature of the system is indicated by the continuous application of the rules where some data cells may be directly or indirectly altered either by reference to the rule-set or by incorporatin,- realtime performance input. Once initialised, T/'H.uk, f,Zuzs'is thus a self-maintaining and responsive system, which can be employed in a consistent and integrated fashion at many levels of the musical hierarchy of organisation. These may vary from audio-rate digital signal processing applications, tlhrough to high-level compositional control, including algorithmic processes where required. This paper introduces the theoretical basis of the system.,and discusses its application to a distributed digital signal processing network called MIDAS[ 1]. Examples of compositonal applications are given, the first showing a 'score' application, the second leading to a complete algorithmic composition. Tabula Viglfans. literally translated 'vigilalt table', is a concept which has emerged from a perceived requirement for storing, varying and controlling musical data under conditions of musical performance, either actual or simulated. It consists of two parts: a block of data, which can be organised as an n-dimensional array of celv' containing numerical data, and it set of riles; which govern the relationships between data. In T, bula VqVi ir.s, cells may 1 2 3 4 ___ 1.7 8. ___ 8.4 6.7 RuLes:. b3 suu a2 d4 bi free or 'stand-alone' or they may organised as tables of varying dimensions aud sizes. In order to explain the organisation of the data, it will be convenient to limit the discussion to a 2-dimensional array of cells, which are of a consistent type, such as 32-bit floating point values. Such an array is created in addressable memory, and the values within each cell are initialised, or 'primed' by the user's application. The values within cells are checked and maintained by a rule-base, a set of rules which ensure that certain desired relationships between the values of cells are kept. These values are not nonnally displayed. though within Thhula ki4'ialzs a 'probe' function is available in order to monitor critical cells. Thus far - apart from the lack of cell display - we have something resembling a spreadsheet. Values can be entered into the aIay, and other cells dependent upon these values are checked against the rule-base and altered if necessary to comply with the rules. For the purposes of illustration. let us take a simple, even trivial, example. Figure 1. Figure 1 shows a four-by-four grid with sixteen cells. Some of these have been primed with values as shown. Underneath is given a nile. in the form rcsul - opn, n e - -input valucs The value of cell b3 is dependent upon cells a2 and d4: it is formed from their sum. If a value within cell a2 or d4 is changed, then the valte in b3 will be changed 'automatically' to comply with the rule. This rule is an equation which may be expressel in the conventional form: b3 = a2 + d4 243

Page  244 ï~~How are the values in cells actually changed? Either by the 'automatic' action of 72Tbila [/Tizns or by some validated input from the user. The user may be given access to some cells and not to others. It is convenient to limit the user to varying 'input' cells, but some circumstances may require user control over what is normally thought of as an output. If the user can control the value of the 'result' cell b3, then we require a further rule or rules to govern the relationship between 'input' cells a2 and d4. Such strategies have in fact been built in to many of the Th'/w J,/'aw., functions. The 'vigilant' nature of the system is that any cells which can be directly or indirectly accessed by the user are continuously monitored and dependent values updated by reference to the rule-base. It is assumed that the cycles ol data-checking, rule reference and and data-updating will be sufficiently fast to permit useful musical results at witever control rates are required by the user application. The duration of a complete performance cycle will be the interval between a given cell's being checked, to the time that it is next checked. This interval will vary considerably according to the amount of processing required. In the case of large data sets and large rule-bases with complex - possibly recursive - dependencies controlling events at audio rate. considerable demands on the performance of the hardware im)lementation will be inposed. The Rule Set At the time of writing an initial set of some 30 primitive rules has been implemented, the set oeiiig in principle expandable. In this set the OpIanIe.: specifying operations, include the following: opname init copy if lim lock mean midiout mouse mull pow prop rand recip sine sum swap time opera/io initialise cell value copy value of one cell to another conditional branch limit numerical bounds (low and high) declare cell value locked average input values output a MIDI message output mouse positions x & y multiplication power function lock proportional cell values output random number (limits) reciprocal give sine of input value addition swap values of cells begin time counter exampl/ b1 init 0.0 c3 copy bl if (b >= c) a9 lim -1, 1 b5 lock 1.414 a mean b, c, d, e midioul chan, pitch, velocity, auration x, y mouse a5 mult a3, a4 d3 pow al, 2 ci prop a5, a6, a7 r rand -1, 1 a6 recip b6 a sine b B3 sum a2 d4 a swap b t time Illustrations of Applications of Tabula Vi igans Two illustrations have been chosen, in order to show how Tabula k7,riaz15' operating in different musical circumstances. The first of these Ls a straightforward implementation of a score. Illustration One: A work for solo clarinet. The first illustration uses direct data transfer from 7'ibuia ',ilazr tables to a MIDI perfoniaiice output. Cells and tables are created as follows: * Dch 6 dur' 2 terI60 1 2 3 4 5 6 7 8 9 1 11 12 B p 4 1 2 2 -7 2 -65 53 1 2 2 C 2.25.25 1.5 1.5.5 1.5.25.25 1 Figure 2 244

Page  245 ï~~Cells and tables are initialised as follows: Cell 'pch' contains the MIDI pitch initialisation value. Cell 'dur' contains the duration in beats that the pitch is to be played. Cell 'tern' contains the tempo value relating the beat to clock time. Table B contains successive pitch offsets for the melody. Table C contains successive duration values. The Rules: pch init 60 initialise pitch to middle C dur init 2 initialise duration to 2 beats tem init 60; initialise tempo to 60 beats per minute. B table 12; create table of 12 cells B filltable pitches fill table from file 'pitches' (etc).............. start: pch sum pch, B dur copy dur, C midiout 0, pch, 64, dur loop With the values given, this should produce the musical results shown below: J = MM60 Clarinet I 7 ". - [etc.] Illustration Two: Algorithmic Composition The second example shows how some algorithmic features may be employed in a Tbula Vriiw-i ruie-tile. In this case we are also using the example to discuss the implementation of Tlat h, V ia.son MIDAS [l]j. In Figure 3 we show a simplified rule-file alongside its MIDAS counterpart. The rule-file, submitted by the user to Tibul V, z?,w..;in this case makes certain constrained choices, and outputs the data to MIDI. It is, perhaps, worth emphasisini that neither Tbula,n ViYws nor MIDAS are limited to MIDI output: they are simply chosen as immediately demonstrable applications. Implementation of Tabula Vigilans on the MIDAS Computer Music Environment MIDAS [1, 2] is a multiprocessor system designed to support the signal processing algorithms commonui found in computer music applications. These algorithms. known as Unit Generator Processes (UGPs), are implemented as self contained modules which run concurrently on the processors in MIDAS. Where required, UGPs intercommunicate across a high throughput local area network, known as MILAN, which is built into the system. The fact that MIDAS is capable of truly concurrent operation of UGPs on more than one processor makes it an ideal medium for the implementation of Tabula Vigilans. The rules are written as UGPs which may be monnected to memory locations holding cell values using standard MIDAS configuration and data communication protocols [ref]. The vigilant nature of Tabula Vigilans is then automatically provided by the concurrent operation of the UGPs which implement the rules. In Fig. 3 UGPs are shown as circles, and dataflows, handled by packets on the network. are shown as directed arrows. The UGP is allowed to run only if all of its inputs are present. The data is removed by the UGP from FIFO inputs, whereas the data is left hi7 sit in registered inputs. These mechanisms provide the basic synchronisation facilities in MIDAS. 245

Page  246 ï~~A trigger packet is written into the random number generator inputs ('rand') in order to start the algoritlmiic process shown in Fig. 3. Since these inputs are addressable entities within the MIDAS system, the trigger can in principle come from any source which wishes to start a Tabula VI,'rs cycle within this algorithmic configuration. The 'rand' UGPs produce outputs "rl' and 'r2', which are constrained to lie between thew values applied to the constraint boundary registered inputs. Once 'rl' and 'r2' are available, the 'sum' and predicate ('if') UGPs can start up. The 'sum' UGP simply produces a pitch datum for the 'midiout' UGP from the random number 'ri' which is added to the base or root pitch value 'low'. The predicate UGP compares its input parameter 'r2' with a threshold value (0.5 in this case) which is held at a registered input. Depending on the result of the comparison, the value 0.5 or 2.0 is passed to the mult' UGP. This scales the current value of the parameter 'dur' which is held in a variable storage manager UGP. The result is written back to the storage manager, ready for the next cycle, and it is also sent on to the 'midiout' UGP where it is used to control the duration of the MIDI output note. It is only when both inputs ('pch' and 'dur') are placed at the input to the 'midiout' UGP that it is able to rtn, outputting the appropriate note-on, note-off MID I messaves, after which it addresses ai trigger command to the 'raid' UGPs to initiate the next cycle. trigger low init 60 0 0 dur init 1 12 start:,= FIFO input rl rand 0, 12 (rl), low r2 rand 0, 1 2 cy' = registered input if(r2 > 0.5)0.5 dur mult dur, 2 Predicate UGP else (pch) (2, 0.5) Storage Manager UGP dur mult dur, 0.5 mlt u pch sum low, rl midiout pch, dur S(dur) loop idi outMIDI out An algorithmic process described as a Tabula Vigilans script and as an equivalent network of MIDAS UGPs Figure 3 Conclusion The application of the algorithinic processes described in this paper, to the MIDAS system, was oricinally posed as an exercise to assess the compatibility between the Tabula7 Vi-'ziiaus'and MIDAS concepts. It was aLso used to assess how amenable the MIDAS architecture was to these algorithmnic processes. Our conclusion is thant with the addition of at few UGPs specialised for algorithmnic operation.s (e.g. predicates) and a new storage manager UGP, MIDAS forms an ideal vehicle to carry forward the flexible environment provided by 7'",bua l/ VT, its for algorithmnic composition antI performance. Rcfcrcnces [11 P.R.. Kirk and R. Orton, "'MIDAS: A Musical Instrument Digital Array Signal Processor"~ Proceedings of thec ICMC, Glasgow 1990. [2J Anderson, Hunt, Kirk, MeGilly, Orton and Watkinson, "From Score to Unit Generator: A Hierarchical View of MIDAS", Proceedings of the 1CMC, San Jose, 1992. 246