A Allombert

G Assayag

Ircam M Desainte-Catherine

C Rueda

CONCURRENT CONSTRAINTS MODELS FOR SPECIFYING INTERACTIVE SCORES

We propose a formalism for the construction and performance of musical pieces composed of temporal structures involving discrete interactive events. The occurrence in time of these structures and events is partially defined according to constraints, such as Allen temporal relations. We represent the temporal structures using two constraint models. A constraints propagation model is used for the score composition stage, while a non deterministic temporal concurrent constraint calculus (NTCC) is used for the performance phase. The models are tested with examples of temporal structures computed with the GECODE constraint system library and run with a NTCC interpreter.

INTRODUCTION

Composing an interactive musical piece often necessitates the construction of several musical parts, before binding them to interactive events or computing programs. On the one hand, existing systems for writing music propose very limited real-time interaction; on the other hand, programming languages, such as MAX (or pd) do not provide the composer with very sophisticated tools for composition.

We claim that a new kind of systems is needed for composing interactive musical pieces. Such systems would provide a composition environment for building musical parts as well as programming tools for specifying computations of interaction.

In this paper, we propose a formalism for writing musical pieces involving discrete interactive events. As in [START_REF] Dessainte-Catherine | Specification of temporal relations betwenn interactive events[END_REF], we shall call interactive score a musical score involving static and interactive events, that are bound by some logical properties. In this paper, we limit our study to temporal relations, such as the Allen's ones. After the presentation of what is exactly an interactive score, we propose an operational model based on concurrent constraints models, and wich provides a sound specification of any interactive score. Our model comprises a compositional phase and a performance phase. For the first one we propose an incremental constraints propagation model based on the GECODE constraints library, and for the second one a non deterministic temporal concurrent constraints calculus. Our preliminary tests show this model to be appropriate both for score editing and for our real-time requirements, but more experiments are needed for this to be conclusive.

BACKGROUND

Temporal structures

An interactive score is a set of musical objects (such as notes and events) that are bound by temporal relations. In this set, some events are chosen to be interactive. That means that they will happen in real-time. In the general case, temporal relations specify in a partial way the musical piece, so that several editions off the pieces can be obtained during performance, according to the real-time events coming in input. This indeterminism provides a kind of degree of freedom to the musicians, at the same time the resulting piece still satisfies the composer's requirements.

The whole process requires the two following consecutive steps.

1. The compositional process: the composer builds his interactive score by creating his musical objects, binding them with temporal relations, and choosing his interactive events;

2. The performance process: the interactive score is no more edited. The system executes and decides at each step which object must start, continue or stop. These decisions are made according to the asynchronous real-time events coming from the input, and the indeterminism in the score.

Concurrent constraints models

Concurrent constraint programming (CCP [START_REF] Saraswat | Concurrent Constraint Programming The[END_REF]) is intended as a model of concurrent systems. In CCP, a concurrent system is modeled in terms of constraints over the variables of the system. A constraint is a formula representing partial information about the values of some of the variables. For example, in a system with variables pitch 1 , pitch 2 taking MIDI values, the constraint pitch 1 > pitch 2 + 2 specifies possible values for pitch 1 and pitch 2 (where pitch 1 is at least a tone higher than pitch 2 ). The CCP model includes a set of (basic) constraints, and a so-called entailment relation |= between constraints. This relation gives a way of deducing a constraint from the information supplied by other constraints. For example,

pitch 1 > pitch 2 + 2, pitch 2 > 60 |= pitch 1 > 48.
Computation in the CCP model proceeds by accumulating information (i.e. constraints) in a store. The information specifies all that is known about the values of the variables at a given moment. Information on the store may increase but it cannot decrease. Concurrent processes interact with the store either telling new information, or asking whether some constraint can be deduced (entailed) from the information therein. It may well happen that the constraint cannot be entailed. In this case the interacting process is said to block until some other processes tell enough information to the store to deduce its constraint.

Basic constraints in a CCP model are chosen so that entailment can be efficiently computed. In programming systems based on the CCP model the user can compute with more complex (non-basic) constraints. These systems provide a propagator for each different type of user constraint. The role of the propagator is to translate a given asserted constraint into a collection of basic constraints supplying the same information. For example, assuming basic constraints are all of the form x ∈ [a..b], and a store containing {pitch 1 ∈ [36..72], pitch 2 ∈ [60..80]}, a propagator for the constraint pitch 1 > pitch 2 + 2 would tell constraints pitch 1 ∈ [63..72] and pitch 2 ∈ [60..69]. A good CCP language provides the user with efficient propagators for a rich collection of constraint types. A wellknown example is the distinct type of constraint, used for asserting that the values of some collection of variables must pairwise be all distinct.

As can be seen in the above example, the action of propagators narrows down the set of possible values for each variable (its so-called domain). This, however, does not guarantee that it will eventually be inferred a single value to each variable. CCP languages thus include in general search engines. The purpose of a search engine is to choose additional basic constraints to tell into the store until all variables have reduced their domain into a single value. For example, a search engine might choose to tell constraint pitch 1 ∈ [72..72] in the example discussed above. This will allow the propagator for pitch 1 > pitch 2 + 2 to infer constraint pitch 2 ∈ [69..69] and thus all variables will be assigned a single value. It may so happen, of course, that the constraint chosen by the search engine leads to a contradiction. The search engine then backs up, and chooses a different constraint.

A system providing many efficient propagators and powerful user controllable search engines is GECODE ( [START_REF] Schulte | Views and Iterators for Generic Constraint Implementations[END_REF]). We describe below how to use it to model a temporal structure interaction system.

One drawback of the CCP model as presented above is that information is always accumulated. There is no way to eliminate it. This poses difficulties for modeling reactive systems, in which information on a given variable changes, depending on the interactions of the system with its environment, as is the case, for example, in interactive performance systems. Different extensions on the CCP model have been proposed to handle reactive systems. One such model is the non-deterministic temporal concurrent constraint calculus (NTCC, [START_REF] Palamidessi | A Temporal Concurrent Constraint Programming Calculus[END_REF]). This calculus introduces the notion of time, seen as a sequence of time slots. At each time slot a CCP computation takes place, starting with an empty store (or one that has been given some information by the environment). Concurrent constraints agents operate on this store as in the usual CCP model to accumulate information into the store. As opposed to the CCP model, the agents can schedule processes to be run in future temporal slots. Since at the beginning of each time slot a new store is created, information on the value of a variable can change (e.g. it can be forgotten) from one slot to the next. The computational agents of NTCC are describe in Table 1 1. NTCC agents tell(c) adds informatrion c to the store of the current time unit. This information can then be used to deduce other constraints. Agent when c do A asks whether c can be deduced to hold from the current store, and if so, execute agent A. Computed information that is to remain local to an agent is defined by local x in P . Here, information on x added by P is only seen by itself, or by its subprocesses (if any). Reciprocally, any existing global information on x cannot be seen by P . The parallel composition agent A B runs A and B in parallel. Agent next A schedules A to be run at the next time unit. Notice that an agent next tell(c) adds information c to the store of the next time unit. Notice that this store might initially be empty or contain some information provided externally by the environment (e.g. as the result of the system interacting with a musical device), but is completely independent of the store of the current time unit. Agent unless c next A offers the possibility of performing activity on the basis of absence of information. When constraint c cannot be deduced from the store of the current time unit, action A is performed in the next time unit. It should be noted that in NTCC, this means that entailment checking of c is performed when all other processes have finished, i.e. when it is certain that c cannot be deduced in the current time unit.

The choice agent i∈I when c i do P i non deterministically runs some process P i such that its guard c i can be deduced from the current store. Several of the c i 's could hold, but only one P i is non deterministically chosen. Agent * P schedules P to be run either now, or at some unspecified time in the future. In practice, a more controlled version of this agent, denoted * [i,j] P , is used. This schedules P to be run at some time within the (closed) interval [i, j]. This version can be encoded in standard NTCC. In NTCC, agents are ephemeral. Their life span is just the time unit in which they run. Agent ! P adds persistence. It launches process P at the current time unit and at all future time units.

The following example illustrates computation in NTCC.

SY ST

def = ! tell(start > 20) CHECK P LAY * [50,200] tell(play(done))
BEAT (0)

P LAY def = ! i∈{1,2,3} when play(on) do N OT E i CHECK def = unless beat < start next play(on) unless play(done) next CHECK BEAT (i) def = tell(beat = i) next BEAT (i + 1)
The system asserts (persistently) that the value of start is greater than 20 and runs in parallel three processes P LAY , CHECK and BEAT . It also launches a process that is to stop performance at some unspecified time unit in the range 50..200. Process P LAY non deterministically chooses one of three notes when playing is on. Process CHECK asserts that playing is on once it can be deduced that the beat counter is greater than or equal to the starting time. It does so repeatedly until the stop playing signal arrives. The BEAT process is simply a counter (recursive process definition can be encoded in the standard NTCC calculus. See [START_REF] Palamidessi | A Temporal Concurrent Constraint Programming Calculus[END_REF]).

The NTCC calculus has an associated linear temporal logic. Desirable properties of an NTCC model can be expressed as a formula in this logic. A proof system allows to verify whether the NTCC model satisfies the property.

The NTCC calculus has been used to model musical improvisation processes ( [START_REF] Rueda | Proving musical properties Using a temporal Concurrent Constraints calculus[END_REF]). We use it here to account for the interaction with a composer (or device) during performance as a hierarchical temporal process that's constrained in various ways is run.

THE MODEL

In this section, we present our model of interactive scores on which we base our study. This model directly stems from the model presented in [START_REF] Dessainte-Catherine | Interactive Scores : A Model for Specifying Temporal Relations between Interactive and Static Events[END_REF].

Interactive Score

Intuitively, a score is a representation where a set of temporal objects (TO) are disposed in time. Temporal objects have a start time and a duration (or an end time) . If the score is to be executed in real-time by a computer, an associated process is attached to temporal objects, giving them a musical/sound content. A note, for example, is a particularly simple temporal object to which conventional graphical notations may apply, and for which the associated process could be a simple Midi note-on / note-off triggering mechanism. In the general case, the associated process might be much more complex and involve for example, starting a synthesis engine and controlling its parameters in real-time. Or, it could involve the processing of an incoming stream of events or sound. In this case the score will be said to be interactive, as its execution depends on asynchronous informations from the outside. Musical processes attached to TOs are beyond the scope of this paper. We see three levels of representations for scores in a computer environment : graphical, structural and temporal. These representations establish a complex network of relationships over the TOs. The graphical level provides a set of surface representations and graphical edition tools that may include conventional music notation (where it may apply) or hierarchical boxing representations such as in OpenMusic Maquettes [START_REF] Assayag | Computer Assisted Composition at IRCAM: From PatchWork to OpenMusic[END_REF] or Boxes [START_REF] Beurivé | Un logiciel de composition musicale combinant un modle spectral, des structures hirarchiques et des contraintes[END_REF]. For a given structural and temporal representation, several graphical representations may interchange, that reveal more or less the structural / temporal details. Structural representations encompass diverse structural relationships such as hierarchical ones (a son TO may belong to a father TO) or functional ones (the process linked to a TO may provide input informations to another TO/process). Temporal representation expresses all the temporal relationships between TOs, such as before, meets etc. This paper is mostly focused on the the temporal representation, which is enough to understand the propagation and exploration processes that takes place during score composition, as well as performance/execution time. For instance hierarchical relationships, usually represented as boxes inside boxes in graphical scores, although they are necessary for the composer to have a synthetic view of his musical sketch at the graphical/structural level, can be for our purpose easily translated at the temporal level into automatically generated basic relations : a son TO will always be linked by a during relation to its father. Although we will for the sake of clarity represent hierarchical information in the graphical representations, only information at the temporal level will be actually processed by the constraint engines described.

So, at the temporal level, we will describe the structure of an interactive score as such :

A score is defined by a tuplet s = t, r , where t is a set of temporal objects, and r is a set of temporal relations. A temporal relation is defined by r = a, t 1 , t 2 where a belongs to A, the set of Allen relations [START_REF] Allen | Maintaining Knowledge about Temporal Intervals[END_REF], and t 1 and t 2 are temporal objects.

A temporal object is defined by t = s, d, p, c where s is the start time d is the duration, p is an attached process, c is a constraint attached to t (i.e. its local store).

The local store will be useful later for assigning musical attributes and configuring classes of temporal objects. It can also serve to assert "value fixing" relations (e.g. s = 20, or d > 50).

When creating new temporal objects, there is the facility to choose it among four classes that differ in the role they play in the score and the constraints in their store. The four classes are : event, texture, interval, and controlpoint.

• An event has the constraint d = 0. Events model discrete interactive actions. Their attached process is specialized in "listening" to the environment and waiting a triggering signal to happen.

• A texture has the constraints d ∈ [d 1 , d 2 ], 0 < d 1 ≤ d 2
, which gives its duration an authorized range of variation. If we force d 1 and d 2 to be equal to the texture's initial duration, then it is considered rigid. Otherwise it is considered supple. A texture has a generative process.

• An interval is exactly like a texture, except it has no generative process. Intervals are used as blank placeholders in the score. They help to refine Allens relations with respect to authorized time intervals.

• A control-point p is always created in relation with a texture/interval q. A relation p during q is automatically added to the score. Control points help to express a time relation between any TO and a particular point inside a texture or an interval.

The class information is kept at the structural representation level, as is the hierarchical information ; as for the temporal level, objects are handled in a unified fashion.

Temporal relations

The composer can bind the temporal objects with temporal relations based on the Allen relations. He can define the relations before, meets, overlaps, starts, finishes, during between temporal objects ; as mentioned before, to maintain the temporal hierarchy of the score, a during relation is automaticaly added between a TO and its sons. Allens relations are only qualitative, while all inital temporal positions and durations are quantitatively specified in the score. Thus, we keep this information, and use it for expressing quantitative temporal properties that may, in certain cases, put restrictions on the Allen relations. For example, a TO defined as rigid will be obliged to keep the duration it is given when created. The temporal relations are used to keep the organization of the score whenever the composer changes the characteristics of a TO (duration, start time ) at score edition time. The new values are propagated through the score and the TOs are moved or stretched as necessary in order to respect the constraints.

Interactive events

We call an interactive event a particular event that is not to be played by the score player. Rather, it models a discrete, asynchronous event that is supposed to happen at performance time in the external environment, and to enter the system through an input channel. Such an event could be related to the triggering of a pedal, or the detection of an instrumentist who begins to play, the recognition of a certain pitch played by a musician etc. The composer can define temporal relations between events and any other TO, including events. The meets relation will generally be used to synchronize TO's with the arrival of an interactive event, and therefore explicitly represents the way an external control will be able drive the execution of the score at performance time. The process associated to an event will run from the origin of time in the score until the event actually happens. When it does happen, a special constraint will be added to the store, informing the execution machine that it is time to check all the constraints relating this event to other TOs. This will in turn condition the execution of the TOs (start a TO, stop a TO, etc.) that depend on the event. It must be understood that interactive events may well happen at a certain distance from the date to which they are assigned in the score, because of expressive choices or even mistakes. Thus the event date in the score is only the ideal date, and the Allen relations will be used to maintain the score coherence whatever the anticipation or delay. Of course this must stay within reasonable limits : an exagerated anticipation or delay should be interpreted as a mistake or a time out. Such limits can be expressed by setting a before relation between an interactive event and other TOs, in order to prevent the event from happening outside of a certain region in the score. One can also use the intervals we have introduced sooner.

By defining an interval as being supple or rigid, by giving it a duration range, one can control the authorized region for an event (see example further). In case of anticipation errors or time outs, decisions have to be made, the simplest of which is to just ignore the event. This can lead to difficulties : due to the web of dependencies between TOs, from it could result in preventing the entire score remaining from being executed. Adressing this problem is beyond the scope of the paper. So, the general philosophy behind all this, at performance time, is "keep as much as possible the coherence of the time structure planned in the score, while taking into account, and accepting up to a certain limit, the expressive freedom of the external agents." An interactive score is shown in Figure 1. In this example, we have 8 temporal objects T 0 to T 7. Objects T 0 to T 6 are embedded into T 7, which means they all have an implicit during relation to T 7. By convention we will call s i and ∆ i the variables defining the start time and duration of temporal object T i.

T 0, T 3, T 6 are intervals (drawn as arrows) T 1, T 2 are textures (drawn as rectangles) T 5 is an interactive event (drawn as a circle) T 4 is a control-point associated to T 1 (drawn as a black circle) T 0, T 1 and T 6 are rigid (shown by a bold line) T 3 is supple and has a duration range of [∆ min , ∆ max ] T 2 is supple.

The Allen relations are :

T 0 starts T 7 T 0 meets T 1 T 4 meets T 2 T 1 overlaps T 2 T 5 meets T 2 T 3 starts T 1 T 3 meets T 5 T 2 meets T 6 T 6 meets T 7
The relations involving an interval (e.g. T 0 meets T 1) have not been drawn as the arrow symbol is quite explicit. The interpretation of this score is as follow :

T 7 is a complex texture that controls the occurrence of a certain number of substructures. From the beginning of execution of T 7, wait for a duration equal to ∆ 0 . Then begin playing T 1. From that point, after duration ∆ min has elapsed, we begin to expect an external event (T 5) that should happen before duration ∆ max has elapsed. As soon as T 5 has been detected, start playing T 2. When duration ∆ 0 + ∆ 1 has elapsed since the beginning of T 7, stop T 1. Now the end of T 2 will depend on the status of T 7. If T 7 is rigid, it has a certain duration defined by the composer and the end of T 2 will occur after duration ∆ 7 -∆ 6 has elapsed since the beginning. If T 7 is not constrained, then T 2 will last an undetermined time after T 1 has finished. Object T 7 will end ∆ 6 units of time after T 2 has finished. The Allen relations are :

T 3 starts T 0 T 3 meets T 1 T 1 meets T 4 T 4 meets T 2 T 5 meets T 7 T 6 starts T 1 T 3 meets T 5 T 0 f inishes T 2

The propagation model

In this section we present how we solve the constraints problem we face during the composition when the composer changes the values of the dates of a TO, and we have to propagate it through the score to maintain consistency in the relations. A score can be translated into a constraint problem where the variables are the start dates and durations of the TOs, and the constraints are equations deduced from the temporal relations. For example for two TO n 1 and n 2 linked by a relation n 1 meets n 2 we have the constraint s 1 + ∆ 1 = s 2 with s 1 the starting time of n 1 , ∆ 1 the duration of n 1 , and s 2 the starting time of n 2 . This leads to a linear constraints problem with a cyclic constraint graph. Since many constraint-propagation algorithms do not permit cyclic constraints graphs, we use GECODE [START_REF] Schulte | Views and Iterators for Generic Constraint Implementations[END_REF], a a very efficient multi-engine constraintssatisfaction library written by Christian Schulte. Conceptually, GECODE divides the constraint graph into several parts with structural particularities, before treating each part with a specific domain filtering algorithm. GECODE also propagates intervals of values instead of single values, which makes it admit cyclic constraints graphs.

For the example in Figure 1, the constraints set is (d0, d1 and d6 are locked values fixed by the composer):

∆ 0 = d0, ∆ 1 = d1, ∆ 6 = d6 s 1 = s 7 + ∆ 0 ∆ min ≤ ∆ 3 ≤ ∆ max s 1 + ∆ 3 = s 5 s 2 = s 5 s 2 + ∆ 2 > s 1 + ∆ 1 s 2 + ∆ 2 + ∆ 6 = ∆ 7
We also add constraints with minor priority imposing that each variable is equal to its current value. The level of "soft" constraints is provided in GECODE by means of constraint "reification". In this scheme, instead of posting some property c, a constraint b ↔ c is posted. This asserts that b is the boolean value of the result of posting c. If b = f alse is deduced, then c is inconsistent. The branch and bound search engine of GECODE is used to find a solution maximizing the number of b's with the value true. In our case, this scheme gives a way of getting, after a pertubation, the solution closest to that before the pertubation. Remember that we always have a solution before pertubation since the composer designs the score and therefore gives a value to each variable when he creates and places the TOs (we suppose here that he cannot create inconsistencies).

The NTCC model

The score and TOs are represented by NTCC processes. A score is a NTCC process that launches in parallel all its TO's and asserts a conjunction, r, of temporal relations over the TO variables. We use i∈I P i , where I is finite, to denote the parallel composition of all P i . We also write ( r) for the conjunction of all constraints in the set r. A score t, r is the process

Score def = ( i∈t T O i,[Pi,ci] ) ! tell( r)
Each element of r is a temporal relation. Allen relations are naturally expressed as constraints. Three of them are shown below:

Bef ore (ob1,ob2) def = (dat ob1 + dur ob1 < dat ob2 ) Starts (ob1,ob2) def = (dat ob1 = dat ob2 ) ∧ (dur ob1 < dur ob2 )
Overlaps (ob1,ob2) def = (dat ob1 < dat ob2 ) ∧ (dat ob1 + dur ob1 < dat ob2 + dur ob2 ) ∧ (dat ob2 < dat ob1 + dur ob1 )

The score process above defines permanent relations, but they could as well have been defined to hold only for specific time intervals.

Each temporal object s i , d i , P i , c i is a process launching itself at the right time:

T O i,[Pi,ci] def = ! tell(c i ) ! unless clock + 1 < s i next (tell (clock ≥ s i ) P i ) ! when clock ≥ s i do next ( Same i unless clock ≥ s i + ∆ i next P i )
Notice that if there is not enough information to conclude that the TO should not start, it sets its starting time, s i , to the (next) current value of the clock. This would cause the TO to launch its activity at the next instant (this is represented by process P i ). This also include cases where s i has not been constrained to some specific value, and its information on it is not enough to infer that its value should be greater than the current value of the clock. It can be seen that T O i schedules itself to finish process P i at the right time, unless there is no information on its duration, in which case it just continues acting forever. Objects linked to the occurrence of a particular event have a somewhat different behavior in that they have to wait for the event to arrive before displaying any activity:

EV i,[ci] def = ! when event i (on) do ( ! tell(c i ) ! unless clock + 1 < s i next tell (clock ≥ s i ) ! when clock ≥ s i do next Same i )
A very powerful feature of the calculus is illustrated in the above example: the ability to compute on the basis of absence of information. Notice that not being able to deduce, say, clock < s i is not the same as being able to infer clock ≥ s i . In fact, there could be insufficient information to deduce the former and also the latter. In interactive music environments it is frequent that the time of occurrence (if any) or the type of interaction is not known in advance, and it might be useful in this case that the computation continues on the assumption that such an interaction will not take place once an appropriate amount of time has elapsed.

Process Same i transmitting the current value of s i to the next time slot (n stands for the duration of the whole piece).

Same

i def = v∈[0..n] when s i = v do next tell (s i = v)
The above process first finds out the current value of s i , then just tells that the same value will hold for the next time unit.

The whole system is defined as follows:

System def = Score CLOCK(0)
The clock simply beats time.

CLOCK(v) def = tell (clock = v) next CLOCK(v+1)
Interaction results in adding (or changing) information on the starting time of certain TO's. Interactions are modeled as processes:

T rigger i def = * [0..n] tell(event i (on))
The above represents the result of some device eventually triggering some signal at some unspecified moment within the time span of the piece (from 0 to n). A somewhat more elaborate model would involve a composer performing several interactions, each one fixing some s to some particular value. This could also be easily modeled in NTCC:

Interaction i def = ! (Same i + k∈[0..n] when k > clock do T ry i (k) ) T ry i (k) def = unless s i ≤ clock ∨ k ≥ s i + ∆ i next tell (s i = k) when s i ≤ clock ∨ k ≥ s i + ∆ i do Same i
In the above definition two kind of choices are performed. First, a choice is made on whether to do nothing (i.e. keeping the same current starting time values), or to try changing one s value. In the latter case we use the summation construct of NTCC to non-deterministically choose some time value k. The T ry i process then tries to assign k to s i provided T O i has not started playing yet.

We proceed now to model the example of Figure 1. Textures are represented by the above T O i process. Intervals and control points are T O i processes such that P i = skip, the null process. Let t = {0, 1, ..., 7} r = {Starts 0,7 , M eets 0,1 , ..., M eets 6,7 , During ! tell( r) T rigger 5

The example of figure 2 is modeled in a similar way. Temporal object and event frameworks are as given above. The difference is in the set r of Allen relations used: ! tell( r) T rigger 5

t = {0,

CONCLUSIONS AND FUTURE WORK

We described in this paper how interactive scores could be conveniently represented in a concurrent constraints model. We used a constraints propagation scheme for the interactive editing composition phase and a temporal concurrent constraints calculus for the interactive performance phase. Preliminary results of implementations of some test cases is encouraging.

In the near future we plan to pursue the work presented here in several directions. Both the editing and performance phases are to be integrated as a music modeling tool within the Open Music environment. This will require devising an efficient two way interface between the GECODE library and Common Lisp. Even though NTCC seems to be a good choice for the performance phase, we plan to assess the behavior of NTCC in real-time contexts where complex interactions may occur. The examples presented in this paper were run in an experimental NTCC interpreter implemented in the Mozart programming language [START_REF] Smolka | The Oz Programming Model[END_REF]. We plan to build from an existing Linux version running in C [START_REF] Hurtado | Programming Robotic Devices with a Timed Concurrent Constraint Language[END_REF] to develop an efficient implementation for the Mac OS X platform.

Figure 1 .

 1 Figure 1. An example of an interactive score

Figure 2 .

 2 Figure 2. An second example of an interactive score In this example 2, we have 8 temporal objects T 1 to T 7 are embedded into T 0 ;

  4,1 , ...} The score is T O 0,[skip,∆0=d0] T O 1,[P1,∆1=d1] T O 2,[P2,true] T O 3,[skip,∆min≤∆3≤∆max] T O 4,[skip,true] EV 5,[skip,true] T O 6,[skip,∆6=d6] T O 7,[skip,true]

  1, 2, 3, 4, 5, 6} r = {Starts 3,0 , M eets 3,1 , Bef ore 1,2 , M eets 1,4 , M eets 4,2 , F inishes 2,0 , F inishes 5,1 , M eets 6,5 Bef ore 0,6 } and the score T O 0,[skip,∆0=d0] T O 1,[P1,true] T O 2,[P2,∆2=d2] T O 3,[skip,true] T O 4,[skip,∆4,min≤∆4≤∆4,max] EV 5,[skip,true] T O 6,[skip,∆6,min≤∆6≤∆ 6,max]