Event Specification

First measures of Nachtleben, Julia Blondeau, 2014.
First measures of Nachtleben, Julia Blondeau, 2014.


Events are detected by the listening machine in the audio stream. The specification of an event starts by a keyword defining the kind of event expected and some additional parameters. There are two basic event (NOTE and EVENT) and three event containers (CHORD, TRILL) and MULTI).

Here we give the general syntax of an event specification and then we details all its components.

Musical Event Specification

Event definitions must end by a carriage return. In other words, you are allowed to define only one musical event per line.

TRILL and MULTI are examples of compound events organizing a set of NOTEs in time. Thus they can accept one or several pitch_lists.

There is an additional kind of event

        EVENT d

also followed by a mandatory duration d, which correspond to a fake event triggered manually by the “nextevent” button on the graphical interface or bythe message 'nextevent' sent to the antescofo object.

We first detail the specification of a pitch, then the notation of a duration. We detail the various kinds of events before the presentation of the optional event's attributes. The last section of this chapter is devoted to the command that alters the sequencing of the score.

Pitch Specification

A pitch (used in NOTE) can take the following forms:

A minus sign - may precede the previous specification to specify that the current note is a continuation of a note with the same pitch in the preceding event:

          CHORD (C4 D5)  1
          CHORD (-C4 D3) 1/2

A pitch list is a sequence of one or more pitches (without separator). They are used for instance to define content of a CHORD. For example, the following line defines a C-Major chord composed of C4, E4 and G4:

          CHORD ( C4 64 6700 )

Duration specification

Duration is a mandatory specification for all events. The of duration an event is specified in beats either by an integer (1), the ratio of two integers (like 4/3) or a float (like 1.5).

Events as Containers

Each event keyword in Antescofo can be seen as containers with specific behavior and given nominal durations. A NOTE is a container of one pitch. A CHORD contains a vector of pitches. The figure below shows an example including simple notes and chords written in Antescofo:

chord notation

 BPM 60
 NOTE C4 1.0
 CHORD (D4 F4) 1.0
 NOTE 0  1.0  ; a silence
 NOTE G4 0.0  ; a grace note with duration zero
 NOTE F4 2.0

TRILL

Similar to trills in classical music, a TRILL is a container of events either as atomic pitches or chords, where the internal elements can happen in any specific order. Additionally, internal events in a TRILL are not obliged to happen in the environment. This way, TRILL can be additionally used to notate improvisation boxes where musicians are free to choose elements. A TRILL is considered as a global event with a nominal relative duration. Figure below shows basic examples for Trill.

trill notation

 TRILL (A4 B4) 1.0
 NOTE 0  1.0     ; a silence
 TRILL ( (C5 E5) (D5 F5) ) 2.0

The figure below shows a typical polyphonic situation on piano where the right-hand is playing a regular trill, and the left hand regular notes and chords. In this case, the score is to be segmented at each event onset as TRILL whose elements would become the trill element plus the static notes or chords in the left-hand.

trill notation

 TRILL ( (A4  A2) (B4  A2) )        1/2
 TRILL ( (A4  D3) (B4  D3) )        1/2
 TRILL ( (A4  C3 E3) (B4  C3 E3) )  1/2
 TRILL ( (A4  D3) (B4  D3) )        1/2
 TRILL ( A4 B4 )    2.0

MULTI

Similar to TRILL, a MULTI is a compound event (that can contain notes, chords or trills events) but where the order of actions are to be respected and decoded accordingly in the listening machine. They can model continuous events such as glissando.

A chord event inside a multi is specified through its pitch list between parenthesis.

To specify a trill event in a multi, it suffices to insert a ' character after the pitch list specifying the trill (between parenthesis). The figure below shows an example of glissandi between chords written by MULTI.

gliss notation
 
 

 MULTI ( (F4 C5) -> (D4 A4) ) 4.0 

Event Attributes

The attributes of a musical event are either a label or a @-keyword following the definition of the event. Attributes are optional.

Event Label

A simple identifier or a string or an integer acts as a label for this event. There can be several such labels. If the label is a simple identifier, its $-form can be used in a expression elsewhere in the score to denote the time in beats of the onset of the event.

Label: Optionally, users can define labels on events as a simple identifier, a number or a string, useful for browsing inside the score and for visualisation purposes.

For example, measure1 is an accepted label. If you intend to use white space or mathematical symbols inside your string, you should surround them with quotations such as "measure 1" or "measure-1"

Fermata, Pizzicato, Hook and Jump

There are four kinds of event attributes besides labels:

These attribute can be given in any order. For instance:

          Note D4 1 here  @fermata @jump l1, l2

defines an event labelled by here which is potentially followed by the next event (in the file) or the events labeled by l1 or l2 in the score. It has a fermata. Note that

          Note D4 1 @jump l1, l2 here

corresponds to the same specification: here is not interpreted as the argument of the jump but as a label for the event because there is no comma after l2.

Open Score and Dynamic jumps

Open Score: specifying alternative follow-ups

Usually, musical events are matched in sequence: after an event e, the listening machine looks to match the event that is specified textually after e in the score. So, the score is deterministic: the expected future of each musical event is well defined1.

The @jump attribute of an event is used to specify alternative “continuations” as a list of labels specifying the events that can be expected after e. This feature makes possible to escape the standard linearity of a score to specify open score where the musician may choose between several alternatives to proceed. The resulting score is not deterministic: after an event with a @jump attribute, one of the events listed in the jump list can be expected.

Obviously, the listening machine must be able to disambiguate the possible follow-ups: so, the first events of each continuation must be different.

Here is an example corresponding to the following open score organization:

          // INTRO                                       
          NOTE G3 1 INTRO                                        
          ; ...                                          
          NOTE G4 1 @jump part2, part2_alt               

          // PART2                                       
          NOTE D2 1 part2                                     
          ; ...                                       
          NOTE D3 1 end_part2 @jump next_part

          // PART2 ALT
          NOTE E3 1 part2_alt                                     
          ; ...                                       
          NOTE E5 1 end_part2_alt

          // NEXT_PART                                       
          ; NOTE E5 next_part
          ; ...          

Dynamic Jumps

Instead of a fixed list of labels, it is possible to use an Antescofo variable. This variable must refer to an event position (integer or float) or an event label (through a string) or a tab of them. This variable may change its value in the course of the performance. In this way, it is possible to achieve “dynamic open score” where the graph of the possibilities is updated during the performance, e.g. following the choices made by the musician, external events, internal computations, etc.

Dynamic changes in the score graph (through the variables appearing in the @jump attribute) impact the listening machine. The listening machine maintains a set of hypothesis about the potential events to recognize in the audio stream. If the changes in the score graph are anticipated enough with respect to the actual jumps, the listening machine will automatically accommodate these changes.

However, if the computation of the jumps are not far enough in time from the actual jumps, the listening machine must be explicitly warned to allow the revision of the hypothesis. This is done by setting true to the system variable $JUMP_UPDATED when the modifications are done. It is not easy to define what it means “far enough” because the temporal horizon used by the listening machine is adaptive.

Here is a toy example: the idea is to start with an INTRO sequence and then to finish with a NEXT_PART sequence, and in between playing at most once PART2 or PART3 followed by INTRO, in any order:

          $jumps := [ "begin_part2", "begin_part3", "next_part" ]                    
          $part2_done := false                                   
          $part3_done := false                                   

          // INTRO                                       
          NOTE G3 1 INTRO                                        
          ; ...                                          
          NOTE G4 1 @jump $jumps                                     

          // PART2                                       
          NOTE D2 1 begin_part_2                                     
             $part2_done := true                                     
          ; ...                                       
          NOTE D3 1 end_part_2 @jump INTRO                           
             $jumps := if ($part3_done) { "next_part" } 
                       else { ["begin_part3", "next_part"] }  
             $JUMP_UPDATED := true                               

          // PART3                                       
          NOTE E3 1 begin_part_3                                     
             $part3_done := true                                     
          ; ...                                       
          NOTE E5 1 end_part_3 @jump INTRO                           
             $jumps := if ($part2_done) { "next_part" } 
                       else { ["begin_part2", "next_part"] }  
             $JUMP_UPDATED := true                               

          // NEXT_PART                                       
          ; ...                                          

In this example, the musician may choose to perform one of the following five scenarios:

      INTRO  →  NEXT_PART
      INTRO  →  PART2  →  INTRO  →  NEXT_PART
      INTRO  →  PART2  →  INTRO  →  PART3  →  INTRO  →  NEXT_PART
      INTRO  →  PART3  →  INTRO  →  NEXT_PART
      INTRO  →  PART3  →  INTRO  →  PART2  →  INTRO  →  NEXT_PART

Score statement

An Antescofo text score is interpreted from top to bottom. Score statements will affect lines that follow its appearance.

The @modulate attribute can be used on a BPM specification, not on an event. It specify that the tempo must be modulated to the pro rata of the actual tempo of the performer. For example, if a BPM 60 is specified in the score, and the actual tempo of the performance if 70, then an indication of BPM 80 @modulate reset the tempo expected by the listening machine to 80 \times \frac{70}{60} \simeq 93.3.

The variance statement is used to alter the variance parameter of the listening machine. A variance is associated to each musical event. The statement change the variance of the next events for the specified quantity. Use at your own risk.

The tempo statement is used disable or to enable the tempo inference.When the tempo inference is disabled, the nominal tempo specified in the score (through BPM statment, are used.

The dummysilence statement is used to insert a special ‟ghost event” is inserted between two musical events. This can improve in some contexts, the behavior of the listening machine (and degrade this behavior in other contexts).

The pizzsection statement can be used to define a sequence of musical events (between pizzsection on and pizzsection off ) that have the @pizz attribute by default.

The @transpose statement is used to define a transpose factor used for all subsequent pitch definition.

The rubato statement is reserved for future specification.



  1. Even if the specified score is deterministic, the performance is not: musical events can be missed and the temporal relationships of the score are subject to the interpretation of the performer.