Smart Edition of MIDI Files

TL;DR

This paper introduces Dancing MIDI, a model for editing non-quantized MIDI files that preserves musical nuances and relationships, addressing issues caused by naive editing methods.

Contribution

The paper proposes a formal model with specific properties and operations for editing MIDI files, improving over naive methods by maintaining musical integrity.

Findings

Dancing MIDI model prevents common editing problems.

The model satisfies well-defined properties for editing operations.

Effective in real-world applications like automatic harmonization.

Abstract

We address the issue of editing musical performance data, in particular MIDI files representing human musical performances. Editing such sequences raises specific issues due to the ambiguous nature of musical objects. The first source of ambiguity is that musicians naturally produce many deviations from the metrical frame. These deviations may be intentional or subconscious, but they play an important role in conveying the groove or feeling of a performance. Relations between musical elements are also usually implicit, creating even more ambiguity. A note is in relation with the surrounding notes in many possible ways: it can be part of a melodic pattern, it can also play a harmonic role with the simultaneous notes, or be a pedal-tone. All these aspects play an essential role that should be preserved, as much as possible, when editing musical sequences. In this paper, we contribute specifically to the problem of editing non-quantized, metrical musical sequences represented as MIDI files. We first list of number of problems caused by the use of naive edition operations applied to performance data, using a motivating example. We then introduce a model, called Dancing MIDI, based on 1) two desirable, well-defined properties for edit operations and 2) two well-defined operations, Split and Concat, with an implementation. We show that our model formally satisfies the two properties, and that it prevents most of the problems that occur with naive edit operations on our motivating example, as well as on a real-world example using an automatic harmonizer.

Figures

Equations

$$\text{textsc}\mathrm{split}:{\mathbb{S}}_{\delta }\times \{0,\delta ,2\delta ,\dots ,d(S)\}$$

$$(S,t)$$

$$\text{textsc}\mathrm{concat}:{\mathbb{S}}_{\delta }\times {\mathbb{S}}_{\delta }$$

$$(S_1,S_2)$$

$$e^{+}\le t-M(S_l,t).l_l,\forall e\in S_l\text{ or }[\max \{0,t-M(S_l,t).l_l\},t]\in S_l$$

$$e^{-}\ge M(S_r,0).r_r,\forall e\in S_r\text{ or }[0,\min \{M(S_r,0).r_r,d(S_r)\}]\in S_r$$

$$e=[\max \{0,d_1-l_l\},\min \{d_1+d_2,d_1+r_r\}].$$

$$e=[\max \{0,d_1-l_l\},\min \{d1+s_2,d_1+r_r\}],$$

$$e^{-}=\max \{0,d_1-l_l\},$$

$$e^{-}=\max \{0,d_1-l_l,d_1-r_l\}.$$

$$e^{+}=\min \{d_1+d_2,d_1+r_r\}.$$

$$e^{+}=\min \{d_1+d_2,d_1+r_r,d_1+l_r\}.$$

Full text

In this paper, we contribute specifically to the problem of editing non-quantized, metrical musical sequences represented as Midi files. We first list of number of problems caused by the use of naive edition operations applied to performance data, using a motivating example. We then introduce a model, called Dancing Midi, based on 1) two desirable, well-defined properties for edit operations and 2) two well-defined operations, $\operatorname{\textsc{\small split}}$ and $\operatorname{\textsc{\small concat}}$, with an implementation. We show that our model formally satisfies the two properties, and that it prevents most of the problems that occur with naive edit operations on our motivating example, as well as on a real-world example using an automatic harmonizer.

1 Introduction

The term music performance denotes all musical artefacts produced by one or more human musicians playing music, such as a pianist performing a score or accompanying a singer, a violin section playing an orchestration of a piece or a jazz musician improvizing a solo on a given lead sheet. Music performance can be represented in various ways, depending on the context of use: printed notation, such as scores or lead sheets, audio signals, or performance acquisition data, such as piano-rolls or Midi files. Each of these representations captures partial information about the music that is useful in certain contexts, with its own limitations [4]. Printed notation offers information about the musical meaning of a piece, with explicit note names and chord labels (in, *e.g., *lead sheets), and precise metrical and structural information, but it tells little about the sound. Audio recordings render timbre and expression accurately, but provide no information about the score. Symbolic representations of musical performance, such as Midi, provide precise timings are are therefore well adapted to edit operations, either by humans or by software.

The need for editing musical performance data arises from two situations. First, musicians often need to edit performance data when producing a new piece of music. For instance, a jazz pianist may play an improvized version of a song, but this improvization should be edited to accommodate for a posteriori changes in the structure of the song. The second need comes from the rise of AI-based automatic music generation tools. These tools usually work by analyzing existing human performance data to produce new ones (see, e.g. [3] for a survey). Whatever the algorithm used for learning and generating music, these tools call for editing means that preserve as far as possible the expressiveness of original sources. We address the issue of editing musical performance data represented as Midi files, while preserving as much as possible its semantics, in a sense defined below.

However, editing music performance data raises specific issues related to the ambiguous nature of musical objects. The first source of ambiguity is that musicians produce many temporal deviations from the metrical frame. These deviations may be intentional or subconscious, but they play an important part in conveying the groove or feeling of a performance. Relations between musical elements are also usually implicit, creating even more ambiguity. A note is in relation with the surrounding notes in many possible ways: it can be part of a melodic pattern, it can also play a harmonic role with the simultaneous notes, or be a pedal-tone. All these aspects, although not explicitly represented in a Midi file, play an essential role that should be preserved, as much as possible, when editing such musical sequences.

The Midi format is widespread in the instrument industry and Midi editors are commonplace, for instance in Digital Audio Workstations. Paradoxically, the problem of editing Midi with semantic-preserving operations was not addressed yet, to our knowledge. Attempts to provide semantically-preserving edit operations have been made on the audio domain (e.g. [13]) but these are not transferrable to music performance data, as we explain below.

In human-computer interaction, cut, copy and paste [11] are the Holy Trinity of data manipulation. These three commands proved to be so useful that they are now incorporated in virtually every software, such as word processing, programming environments, graphics creation, photography, audio signal, or movie editing tools. Recently, they have been extended to run across devices, enabling moving text or media from, for instance, a smartphone to a computer. These operations are simple and have a clear, unambiguous semantics: cut, for instance, consists in selecting some data, say a word in a text, removing it from the text, and saving it to a clipboard for later use.

Each type of data to be edited raises its own editing issues that led to the development of specific editing techniques. For instance, edits of audio signals usually require cross fades to prevent clicks. Similarly, in movie editing, fade-in and fade-out are used to prevent harsh transitions in the image flow. Edge detection algorithms were developed to simplify object selection in image editing. The case of Midi data is no exception. Every note in a musical work is related to the preceding, succeeding, and simultaneous notes in the piece. Moreover, every note is related to the metrical structure of the music. In Section 2, we list a number of issues occurring when applying naïve edition commands to a musical stream.

In this paper, we restrict ourself to a specific type of musical performance data: non-quantized, metrical music data, i.e. performances which are recorded with free expression but with a fixed, known tempo. This includes most of MIDI files available on the web (for instance [9] ). This excludes MIDI files consisting of free improvization, or music performance with no fixed tempo. Note that these could also be included in the scope of our system, using automatic downbeat estimation methods, but we do not consider this case in this paper.

It is not possible, to our knowledge, to define a precise semantics to musical performance in general. In this paper we contribute to the problem of editing non-quantized, metrical musical sequences represented as Midi files in the following way:

We list of number of problems caused by the use of naive edition operations applied to performance data, using a motivating example; 2. 2.

We then introduce a model, called Dancing Midi, based on 1) two desirable, well-defined properties for edit operations and 2) two well-defined operations, $\operatorname{\textsc{\small split}}$ and $\operatorname{\textsc{\small concat}}$, with an implementation. These primitives can be used to create higher-level operations, such as cut, copy, or paste; 3. 3.

We show that our model formally satisfies the two properties; 4. 4.

We show additionally that our model does not create most of the problems that occur with naive edit operations on our motivating example, as well as on a real-world example using an automatic harmonizer.

2 Motivating Example

Figure 1 shows a piano roll representing five measures extracted from a Midi stream consisting of a performance capture of Johannes Brahms’s Intermezzo in B$\flat$ minor. Consider the problem of cutting the first two beats of Measure 3 and inserting these two beats at the beginning of Measure 6. Figure 2 shows the piano roll produced when these operations are performed in a straightforward way, *i.e., *when considering notes as mere time intervals. Notes that are played across the split temporal positions are segmented, leading to several musical inconsistencies. First, long notes, such as the highest notes, are split into several contiguous short notes. This alters the listening experience, as several attacks are heard, instead of a single one. Additionaly, the note velocities (a Midi equivalent of loudness) are possibly changing at each new attack, which is unmusical. Another issue is that splitting notes with no consideration of the musical context leads to creating excessively short note fragments, which we call residuals, *e.g., *at the bottom right in Figure 2. Residuals are disturbing, especially if their velocity is high, and are somehow analogous to clicks in audio signals. Finally, a side-effect of this approach is that some notes are quantized (last two beats of Measure 5). As a result, slight temporal deviations present in the original Midi stream are lost in the process. Such temporal deviations are important parts of the performance, as they convey the groove, or feeling of the piece, as interpreted by the musician.

Here is a list of musical issues occurring when raw editing a Midi stream:

Creation of residuals, *i.e., *excessively brief notes; 2. 2.

Splitting long notes, creating superfluous attacks; 3. 3.

Creating surprising, inconsistent changes in note velocities; 4. 4.

Losing small temporal deviations with respect to the metrical structure, leading to unnecessary, undesirable quantization.

Figure 3 shows another solution to the problem, obtained using the model presented in this article. Comparing Measure 5 in Figures 2 and 3 shows obvious differences in the two approaches: none of the issues produced with raw edits, shown in Figures 2, are present in the piano roll shown in Figures 3.

3 State of the Art

LogicPro X, the Digital Audio Workstation commercialized by Apple, features a full-featured Midi editor. As shown in Figure 4, when editing a Midi stream, the decisions regarding notes that overlap with the selected regions are left to the user who has to decide whether to split, shorten (to fit the region boundaries) or keep the notes. Figure 2 shows the piano roll produced using the first option, split. In the latter case, keep, when pasting somewhere else, the notes will be put back with their original duration, even if it exceeds the region boundaries. This forces the user to decide explicitly what to do, and the decision applies to all notes, regardless of the musical context. Besides, this strategy leads to creating overlapping notes, which create ambiguous situations as the Midi format does not have a way to handle overlapping notes with the same pitch.

The piano roll panel in Avid Pro Tools, another major Digital Audio Workstation, offers less control on Midi edits than Logic Pro X. Figure 5 shows the piano roll obtained with Pro Tools, when using the basic copy and paste functions on the motivating example. This piano roll is essentially the same as that in Figure 2, except note velocities are not displayed.

4 The Model

In this section, we present a model of temporal sequences that allows us to implement two primitives: $\operatorname{\textsc{\small split}}$ and $\operatorname{\textsc{\small concat}}$. The $\operatorname{\textsc{\small split}}$ primitive is used to break a Midi stream (or Midi file) at a specified temporal position, yielding two Midi streams: the first one contains the music played before the split position and the second one contains the music played after. The $\operatorname{\textsc{\small concat}}$ operation takes two Midi streams as inputs and returns a single stream by appending the second stream to the first one. The model is called Dancing Midi since the underlying technique (see Section 4.2) bears some similarity with the idea of Dancing Links that Donald Knuth developed in [6]

High-level edit operations, such as copy, cut, paste, or insert, may be performed by applying $\operatorname{\textsc{\small split}}$ and $\operatorname{\textsc{\small concat}}$ to the right streams. For example, to cut a Midi stream $S$ between temporal positions $t_{1}$ and $t_{2}$, we execute the sequence of primitive operations

$(S^{\prime},S_{r})\leftarrow\operatorname{\textsc{\small split}}(S,t_{2})$, *i.e., *we split $S$ at $t_{2}$; 2. 2.

$(S_{l},S_{m})\leftarrow\operatorname{\textsc{\small split}}(S^{\prime},t_{1})$, *i.e., *we split $S^{\prime}$ at $t_{1}$. 3. 3.

Return $\operatorname{\textsc{\small concat}}(S_{l},S_{r})$;

The stream $S_{m}$ is removed from $S$ and it could be stored in a Midi clipboard for later use. Similarly, to insert a Midi stream $T$ in a stream $S$ at temporal position $t$, one can perform:

$(S_{1},S_{2})\leftarrow\operatorname{\textsc{\small split}}(S,t)$, *i.e., *split $S$ at $t$; 2. 2.

Return $\operatorname{\textsc{\small concat}}\left(\operatorname{\textsc{\small concat}}\left(S_{1},T\right),S_{2}\right)$.

In our model, a continuous subdivision of time coexists with a discrete, regular subdivision of time, in, *e.g., *beats or measures, which is equivalent to the metrical frame of a musical sequence. The constant distance between discrete temporal positions is denoted by $\delta$. Musical events, *e.g., *notes, rests, chords, may occur at any continuous temporal position. On the contrary, $\operatorname{\textsc{\small split}}$ and $\operatorname{\textsc{\small concat}}$ are applicable only on discrete temporal positions, *i.e., *multiples of $\delta$. In short, musical events may be placed at any position, and take arbitrary durations, within a regularly decomposed time frame.

We made the practical choices to represent time by integers and to consider only sequences starting at time [math] and whose duration is a multiple of the segmentation subdivision, which is denoted by $\delta$. These choices aim at simplifying the implementation and clarifying the presentation without limiting the generality of the model111In Midi files, time is represented by integer numbers, based on a predefined resolution, typically 960 ticks per beats..

A (time) event $e$ is defined by its start and end times, denoted by $e^{-}$ and $e^{+}$, two nonnegative integers, with $e^{-}\leq e^{+}$. We consider sequences of non-overlapping time events. A sequence $S$ with a duration $d(S)$ is an ordered list of time events $E(S)=(e_{1},\dots,e_{n})$, such that:

• •

$d(S)\equiv 0\pmod{\delta}$, *i.e., *the duration of $S$ is a multiple of $\delta$,

• •

$e_{n}^{+}\leq d(S)$, *i.e., *all events are within the sequence, and

• •

$e_{i}^{+}\leq e_{i+1}^{-},\forall i=1,\dots,n-1$, *i.e., *there are no overlapping events.

The set of all such sequences is denoted by $\mathbb{S}_{\delta}$.

The model handles sequences of non-overlapping time intervals (elements of $\mathbb{S}_{\delta}$), and therefore cannot directly deal with Midi streams, which contain overlapping intervals (*e.g., *chords consist of three or more overlapping intervals). Therefore, we decompose a Midi stream into individual sequences of non-overlapping events, one for each unique pitch and unique Midi channel. We show, in Section 4.5, how this approach applies to real Midi streams.

4.1 Problem Statement

We address the problem of implementing $\operatorname{\textsc{\small split}}$ and $\operatorname{\textsc{\small concat}}$ in an efficient and sensible (from a musical viewpoint) way. The $\operatorname{\textsc{\small split}}$ primitive breaks a sequence at a specific temporal position and the $\operatorname{\textsc{\small concat}}$ primitive returns a sequence formed by concatenating two sequences:

[TABLE]

where $t$ is the segmentation position, $S_{l}$ is the left part of $S$, from [math] to $t$, hence $d(S_{l})=t$, and $S_{r}$ is the right part of $S$, after position $t$, with $d(S_{r})=d(S)-t$ and

[TABLE]

where $S$ is a sequence of duration $d(S)=d(S_{1})+d(S_{2})$ constructed by appending $S_{2}$ to $S_{1}$.

The types above specify that $\operatorname{\textsc{\small split}}$ and $\operatorname{\textsc{\small concat}}$ create sequences of $\mathbb{S}_{\delta}$, *i.e., *, sequences with no overlapping events and with all events falling within the sequence’s bounds.

We call residual an event whose duration is shorter than a predefined threshold $\varepsilon$. We define two properties for $\operatorname{\textsc{\small split}}$ and $\operatorname{\textsc{\small concat}}$:

1. (P1)

$\operatorname{\textsc{\small split}}$ and $\operatorname{\textsc{\small concat}}$ are the inverse of one another, i.e.,

1. a.

$\forall S\in\mathbb{S}_{\delta},\forall t\in\{0,\delta,2\delta,\dots,d(S)\},\operatorname{\textsc{\small concat}}(\operatorname{\textsc{\small split}}(S,t))=S$ 2. b.

$\forall S,T\in\mathbb{S}_{\delta},\operatorname{\textsc{\small split}}(\operatorname{\textsc{\small concat}}(S,T),d(S))=(S,T)$ 2. (P2)

$\operatorname{\textsc{\small split}}$ and $\operatorname{\textsc{\small concat}}$ never create residuals, i.e.,

1. a.

let $S\in\mathbb{S}_{\delta},\forall t\in\{0,\delta,2\delta,\dots,d(S)\}$ and $(S_{1},S_{2})=\operatorname{\textsc{\small split}}(S,t)$, then $\forall e\in S_{1}\cup S_{2}$,

$d(e)<\varepsilon\Rightarrow e\in S$, 2. b.

$\forall S,T\in\mathbb{S}_{\delta},\forall e\in S\oplus T,d(e)<\varepsilon\Rightarrow e\in S\cup T$.222This is a simplification, as we explain in Section 4.2.3

Property (P1) states that splitting a sequence and merging back the resulting sequences produces the original sequence and, conversely, concatenating two sequences and splitting them again at the same position, returns the two original sequences. This is to ensure that no information is lost upon splitting and concatenating sequences. Additionally, as we show in Section 4.3, this property offers the benefits of a powerful, generalized undo mechanism.

Property (P2) ensures that no residual is created: the only residuals appearing in a sequence obtained using $\operatorname{\textsc{\small split}}$ or $\operatorname{\textsc{\small concat}}$ were already in the original sequence(s). Note that the second part, i.e., (P2)(2), is a bit simplified, as we explain in Section 4.2.3.

It is easy to design $\operatorname{\textsc{\small split}}$ and $\operatorname{\textsc{\small concat}}$ primitives that satisfy either (P1) or (P2). However, as we will illustrate now, it is difficult to enforce (P1) and (P2). It is the combination of these two properties that ensures that no information is lost and that no residual is created.

Figure 6 shows a simple sequence $S$ of duration $d(S)=20$, with a regular temporal subdivision $\delta=10$ time units, and containing event $e$, with $e^{-}=8$ and $e^{+}=12$. We consider the problem of splitting $S$ in its middle ($t=10$) and concatenating back the two extracted sequences.

Assuming the threshold for brief events is set to $\varepsilon=3$ time units, $\operatorname{\textsc{\small split}}$ and $\operatorname{\textsc{\small concat}}$ should not create events shorter than $3$. Figure 7 shows the result of splitting $S$ into $S_{1}$ and $S_{2}$ and concatenating $S_{1}$ and $S_{2}$, performed in a straightforward way by raw event segmentation, *i.e., *cut exactly at the specified position, and with no additional processing. The concatenation $S_{1}\oplus S_{2}$ is identical to the original sequence $S$, satisfying Property (P1). However, this approach creates two events of duration $2$ in the split sequences $S_{1}$ and $S_{2}$, which violates the residual Property (P2) for $\varepsilon=3$.

On Figure 8, on the contrary, short fragments are omitted, by adding a simple filter, fulfilling Property (P2) as no residuals show up on split sequences $S_{1}$ and $S_{2}$. However, $S_{1}\oplus S_{2}$ is empty, which violates the reversibility Property (P1).

This example suggests that some memory is needed to implement the $\operatorname{\textsc{\small split}}$ and $\operatorname{\textsc{\small concat}}$ operations so they satisfy (P1) and (P2). We show in the next section how to define this operations with a minimal amount of memory.

4.2 Model Implementation

The implementation of the model is based on memory cells that store information about the events occurring at each segmentation position in a sequence.

4.2.1 Computing the Memory Cells

For a given segmentation position $t$, for each event $e$ containing $t$, i.e., $e^{-}\leq t\leq e^{+}$, we compute the length of $e$ that lies before $t$ and the length of $e$ after $t$. These two quantities are stored in two memory cells, a left and a right memory cell, as shown in Figure 9. The left cell stores only information related to events starting strictly before $t$ and, conversely, the right cell stores information related to events ending strictly after $t$. There are five possible configurations, which are shown in Figure 9. When the sequence is split at position $t$, the memory cells of $S$ at position $t$ are distributed to the resulting sequences: the left cell is associated to the left sequence, at position $t$ and the right cell is associated to the right sequence at position [math]. These values will be used to concatenate these subsequences with other sequences, using the $\operatorname{\textsc{\small concat}}$ operation. Algorithm 1 computes the two memory cells for a sequence and a specific segmentation position.

4.2.2 Implementation of $\operatorname{\textsc{\small split}}$

The $\operatorname{\textsc{\small split}}$ primitive, described by Algorithm 2, consists in distributing the intervals to the left and right sequences, $S_{l}$ and $S_{r}$, as follows: intervals occurring before the segmentation position $t$ are allocated to $S_{l}$ and intervals occurring after $t$ are allocated to $S_{r}$. The memory of the original sequence is copied to the resulting sequences in a similar way: memory cells stored before $t$ are copied to the left sequence at the same position; memory cells of $S$ stored after $t$ are copied to the right sequence, with offset $-t$ as all sequences start at position 0 (see Section 4).

A specific treatment is required at position $t$, to avoid creating residuals that could appear when splitting short intervals containing position $t$, in order to satisfy Property (P2)((P2)a.). If an event $e$ contains $t$, i.e., $e^{-}<t<e^{+}$, we consider the memory cells $l_{l}$, $l_{r}$, $r_{l}$, and $r_{r}$ stored in $M(S,t)$ to decide whether an event of length $l_{l}$ should be added at the very end of the left sequence. The event is added if it is not a residual, i.e., $l_{l}>\varepsilon$ or if it is a residual that already existed in $S$, i.e., $l_{r}=0$ and $l_{l}>0$. A similar treatment is applied to decide if an event of length $r_{r}$ is inserted at the very beginning of $S_{r}$. Note that, doing this, we ignore the actual events, and only consider the memory. This is reflected in lines 16 and 18 in Algorithm 2.

Sequence $S_{l}$ is such that the space between $t-l_{l}$ and $t$ is either empty of event or it contains a single event $[t-l_{l},t]$, possibly left-trimmed so it does not start before [math]:

[TABLE]

and $S_{r}$ is such that the space between [math] and $r_{r}$ is either empty of event or it contains a single event $[0,r_{r}]$, possibly right-trimmed so it does not exceed the sequence’s end time:

[TABLE]

Note that the way the memory is computed, see Algorithm 1, ensures that (1) and (2) are satisfied by any sequence before it is split.

4.2.3 Implementation of $\operatorname{\textsc{\small concat}}$

Concatenating two sequences $S_{1}$ and $S_{2}$ creates a new sequence $S$, whose duration $d(S)=d-1+d_{2}$, with $d_{1}=d(S_{1})$ and $d_{2}=d(S_{2})$. All events of $S_{1}$ that end strictly before $d_{1}$ are added to $S$, as well as all events of $S_{2}$ that start strictly after [math]. The only delicate operation is to decide what to do at position $d_{1}$ in $S$.

In Section 4.2.2, we have seen that all sequences satisfy (1) and (2). Therefore, to concatenate $S_{1}$ and $S_{2}$, we need to consider four cases:

$e^{+}\leq t-M(S_{1},d_{1}).l_{l},\forall e\in S_{l}$ and $e^{-}\geq M(S_{2},0).r_{r},\forall e\in S_{2}$, i.e., $S_{1}$ has no event overlapping with the temporal segment defined by $M(S_{1},d_{1}).l_{l}$, its left-memory at $d_{1}$ and, similarly, $S_{2}$ has no event overlapping with the temporal segment defined by $M(S_{2},0).r_{r}$, its right-memory at [math]; 2. 2.

$e^{+}\leq t-M(S_{1},d_{1}).l_{l},\forall e\in S_{l}$ and $[0,\min\{M(S_{2},0).r_{r},d(S_{2})\}]\in S_{2}$, i.e., $S_{1}$ has no event overlapping with the temporal segment defined by $M(S_{1},d_{1}).l_{l}$, its left-memory at $d_{1}$ and $S_{2}$ has an event occupying the temporal segment defined by $M(S_{2},0).r_{r}$, its right-memory at [math]; 3. 3.

$[\max\{0,t-M(S_{1},d_{1}).l_{l}\},t]\in S_{l}$ and $e^{-}\geq M(S_{2},0).r_{r},\forall e\in S_{2}$ has an event occupying the temporal segment defined by $M(S_{1},d_{1}).l_{l}$, its left-memory at $d_{1}$ and $S_{2}$ has no event overlapping with the temporal segment defined by $M(S_{2},0).r_{r}$, its right-memory at [math]; 4. 4.

$[\max\{0,t-M(S_{1},d_{1}).l_{l}\},t]\in S_{l}$ and $[0,\min\{M(S_{2},0).r_{r},d(S_{2})\}]\in S_{2}$, i.e., $S_{1}$ has an event occupying the temporal segment defined by $M(S_{1},d_{1}).l_{l}$, its left-memory at $d_{1}$ and, similarly, $S_{2}$ has an event occupying the temporal segment defined by $M(S_{2},0).r_{r}$, its right-memory at [math];

These four cases correspond to the four if statements in Algorithm 3 at lines 18, 31, 33, and 35 respectively.

Case 1.

The space delimited by the memories of $S_{1}$ and $S_{2}$ does not contain any event. The question is to decide whether an event should be created, based on the values of the memories of $S_{1}$ and $S_{2}$.

If the memories of $S_{1}$ and $S_{2}$ are identical, i.e., $l_{l}=r_{l}$ and $l_{r}=r_{r}$, then we add the event

[TABLE]

We add this event, regardless of its duration, even if it is very small, i.e., $l_{l}+r_{r}<\varepsilon$, because such an short event was present at some point, before $S_{1}$ and $S_{2}$ were obtained by splitting a longer sequence. We must add this event to ensure that Property (P1) is not violated. See Figure 10.

On the contrary, if the memories of $S_{1}$ and $S_{2}$ differ, the choice will depend on the values stored in the memories of $S_{1}$ and $S_{2}$. There are several cases to consider:

If $l_{l}=0$ or $r_{r}=0$, we do nothing, as no events are recorded around the concatenation position. Otherwise, that is when $l_{l}>0$ and $r_{r}>0$, we know that $S_{1}$ (resp. $S_{2}$) had originally an event containing position $d(S_{1})$ (resp. [math]), which disappeared after a split operation. We will create an additional event

[TABLE]

if $d(e)=\min\{d_{1}+d_{2},d_{1}+r_{r}\}-\max\{0,d_{1}-l_{l}\}\geq\varepsilon$, to avoid creating a residual.

Case 2.

The space delimited by the memories of $S_{1}$ and $S_{2}$ contains an event $e$ starting at the onset of $S_{2}$. The question is whether $e$ should start earlier, *i.e., *“in $S_{1}$”, depending on the memories of $S_{1}$ and $S_{2}$.

In this case, we start $e$ at

[TABLE]

another option is to set

[TABLE]

In the second option, the algorithm will try to create an attack for the corresponding note based on the memory of $S_{2}$. Both options are equally valid, the intuition is that favoring the memory of the left sequence tends to preserve temporal deviations in attacks as they appear in the left sequence. Conversely, favoring the memory of the right sequence tends to replicate deviations of attacks as they appear in the right sequence.

Case 3.

The space delimited by the memories of $S_{1}$ and $S_{2}$ contains an event $e$ ending at the end of $S_{1}$. The question is whether $e$ should end later, “in $S_{2}$”, depending on the memories of $S_{1}$ and $S_{2}$.

One possible implementation is to systematically end $e$ at

[TABLE]

Another option is to start the event at

[TABLE]

Here again, both options are equally valid. The intuition is that favoring the memory of the left (resp. right) sequence tends to preserve temporal deviations in note durations as they appear in the left (resp. right) sequence.

Case 4.

The space delimited by the memories of $S_{1}$ and $S_{2}$ contains an event ending at the end of $S_{1}$ and another event starting at the onset of $S_{2}$. In this case, if $l_{r}>0$ and $r_{l}>0$, we merge the two events in a single one, otherwise, we do nothing.

4.3 The Model Satisfies Properties (P1) and (P2)

Properties (P1) and (P2) respectively ensure that the model enables temporal sequence editing without creating undesired residuals and with the guaranty that editing is non-destructive. Therefore the model naturally provides an undo mechanism: if two sequences that originally formed a single sequence are concatenated together in their original position, this will result in the original sequence. But this undo mechanism is more general as even if the two sequences were used for other intermediate edit operations, it will always be possible to recreate the initial sequence. This, combined with the possibility to copy sequences, gives rise to powerful sequence edition tools. This is illustrated on Midi streams in Section4.5.

The model relies on a memory structure computed at each segmentation position. This memory consists of two memory cells, representing the left-hand and right-hand sides of the sequence at the specified position. The essential invariant in the implementation of the $\operatorname{\textsc{\small split}}$ and $\operatorname{\textsc{\small concat}}$ primitives is that

• •

the left-hand side memory of a sequence at its end position is never modified and

• •

the right-hand side memory of a sequence at position [math] is never modified.

Therefore, arbitrary editing the sequence never leads to any information loss, as the model always remembers information about the initial state of a sequence at its starting and end positions. This is what makes it possible to satisfy Properties (P1) and (P2).

We will not fully demonstrate that the model satisfies Properties (P1) and (P2). From the description of Algorithms 2 and 3, it is clear that Property (P2) on residuals is satisfied, with the subtle case discussed in the fifth case of Algorithm 3 (see Section 4.2.3). The Property (P1) on reversibility is easily checked in most cases. The only tricky case is when residuals are present in the edited sequences. A full proof requires reviewing all possible configurations, which would be too long. However, the discussion in Section 4.2.3 covers the most difficult case of split residuals which need to be recreated when concatenating two sequences that were originally forming a single sequence.

4.4 Extending the Model

The model may be extended easily to handle additional musical information. A first extension is to associate each event in a sequence to some metadata. In the case of Midi files, it is natural to store the velocity and the channel of a note-on event with the corresponding event. This is straightforward to implement by storing the metadata in the memory cells computed by Algorithms 1, and by associating the best metadata to newly created events in Algorithms 2 and 3.

Technically, each event $e$ is associated to a value $v(e)$, which may represent any metadata. A time event $e$ is therefore a 3-tuple $[e^{-},e^{+},v(e)]$. The only modifications to the algorithms are:

in Algorithm 1, each memory cell is a 3-tuple, *e.g., *the left memory cell for event $e$ is $[l_{l},l_{r},v]$; 2. 2.

in Algorithm 2, in line 12, we add event $[e^{-}-t,e^{+}-t,v(e)]$ instead of simply $[e^{-}-t,e^{+}-t]$, similarly in line 16, we add $[e^{-},t,v(e)]$ and in line 18, we add $[0,e^{+}-t,v(e)]$; 3. 3.

in Algorithm 3, events receive the value stored in the corresponding memory; when we merge two events, we systematically chose to keep the metadata associated to the left event. This decision is arbitrary and we could decide otherwise, *e.g., *use the memory of the right sequence, compute an “average” value.

In our model, residuals are defined by an absolute threshold duration $\varepsilon$. It is also natural to use a relative definition for residuals. For instance, when splitting a sequence at position $t$, if an event $e$ is such that $e^{-}=t-a$ and $e^{+}=t+b$ with $b\gg a>\varepsilon$, depending on the musical context, one may want to dismiss the part of $e$ occurring before $t$ (or length $a$), although it is not a residual in the absolute sense as $a>\varepsilon$. A typical case is a measure containing a long, whole note starting slightly before the bar line. When splitting at the bar line, the head of the note should be removed, as it obviously belongs to the measure starting at $t$, not to the measure ending at $t$. It is quite easy to extend the model to handle relative residuals, although it makes Algorithms 2 and 3 a bit longer, which is why it is not reported here.

Technically, the head (or tail) of a split event is considered a residual if its duration is shorter than $\varepsilon$ or if it is shorter than a certain ratio of the length the whole event. Typical values for the ratio range from 1/10 (a fragment shorter than a third of the original event is considered too small to exist on its own) to 1/3. This modification leads to a slight increase in the complexity of Algorithms 2 and 3 to ensure that the model still satisfies Properties (P1) and (P2).

4.5 Using the Model on Actual Music Performance

As we said in Section 4, the model handles sequences of non-overlapping events, and as such is not directly applicable to Midi files. However, in a Midi file, for a given Midi pitch and a given Midi channel, the successive note-on and note-off events form a sequence of non-overlapping time intervals. Therefore, the model is applicable to Midi files if we treat each note (fixed pitch and channel) individually. The targeted use of the model is to edit a Midi file capturing a musical performance, and therefore with non-quantized note events, but recorded with a specified tempo. The tempo may change during the piece, but we will consider it fixed here for the sake of clarity. The model is well-adapted to edit such Midi files with segmentation points set as a fraction of the meter, *e.g., *one beat, one bar, half-a-beat. The $\operatorname{\textsc{\small split}}$ and $\operatorname{\textsc{\small concat}}$ primitives were implemented with this application in mind. The way we use the memory when concatenating sequences is to ensure that temporal deviations from the metrical structure of the music are preserved as much as possible, without creating disturbing residuals, and with the flexibility of a powerful undo mechanism.

We describe here applications of our model to two real world examples.

4.5.1 Transforming a 4/4 into a 3/4 Music Piece

Consider the piano roll in Figure 11, which shows eight measures of a Midi capture of a piano performance by French pianist Lionel Gaget, in the style of American pianist Chick Corea. The time signature of this piece is 4/4. We aim at producing a 3/4 version of this piece by removing the last beat of every measure. We created two versions: Figure 12 shows a piano roll of the resulting Midi stream when performing raw edits and Figure 13 shows the resulting music when performing edits with our model.

The version in Figure 12 exhibits many musical issues that make it necessary to manually edit the resulting piano roll to preserve the groove of the original music. Here is a list of some of these issues:

• •

Split long notes, such as the B2 between measures 2 and 3;

• •

Residuals: A2 beginning of m. 4, B2 beginning of m. 5, loud E3 at end of m. 5, etc.

• •

Quantized notes: heads of B1 and F$\sharp$3 beginning of m. 2, tails of E1 and B1 at end of m. 6, etc.

• •

Inconsistent velocities: the velocity of the split B2 changes between m. 2 and m. 3.

The piano roll in Figure 13, on the other hand, does not have any of the issues of the raw edit version, and, as a result, sounds more natural and preserves the style of original music more convincingly.

4.5.2 Harmonization

Recent progress in Artificial Intelligence have led to powerful music generation systems, especially in the symbolic domain [2]. Computers have become extremely efficient at creating brief musical fragments in many styles [12, 5], but no algorithm has yet captured the art of spontaneously arranging musical material into longer convincing structures, such as songs. For instance, in the composition process using FlowMachines [8], human musicians are in charge of selecting and organizing musical material suggested by the computer to create large-scale structures conveying a sense of direction. These new ways of making music highlight the need for powerful tools to edit musical material.

One of the main strength of the Midi format is that it enables musical transformations, such as pitch-shifting (or transposition) and time-stretching, with no loss of quality. The model is naturally compatible with transpositions because the memory cells do not depend on the actual pitch of a note. This can be illustrated by integrating our model within any generative algorithm. As an illustration, we have developed a system that produces harmonizations for a given target Midi file in the style of a source Midi file. The harmonizer outputs a new Midi file with the same duration as the target file, created by editing the source file, using $\operatorname{\textsc{\small split}}$ and $\operatorname{\textsc{\small concat}}$ combined with chromatic transpositions, in such a way that the output file’s harmony matches that of the target Midi file. The harmonizer uses Dynamic Programming [1] or similar techniques, such as Belief Propagation [7], to produce a file that optimizes the harmonic similarity with the target file and, at the same time, minimizes the edits in the source file, to preserve the style of the source as much as possible. We do not fully describe the harmonizer in this article [10].

Figures 15-16 show piano rolls obtained by harmonizing 14 measures of “Autumn Leaves” (see Figure 14) using a Midi capture of a piano performance of an intermezzo by Johannes Brahms. The raw edit in Figures 15 exhibits the same type of artifacts as Figure 12. Long notes are split at each segmentation point (here, every beat), which creates dissonant chords at measures 24-25. More generally, the style of the resulting Midi file is substantially different from that of the original source. The source contains numerous long-held notes and most chords are arpeggiated. In the Midi file on Figures 15 long-held notes are broken at every beat, making most chords non-arpeggiated (notes are played all together). Many residuals are introduced, and some of them make up chords (red boxes in measure 23 and 31) that sound wrong. On the contrary, Figure 16 shows a much cleaner result, with none of these musical issues.

5 Conclusion

We have presented a model for editing non-quantized, metrical musical sequences represented as Midi files. We first listed a number of problems caused by the use of naive edition operations applied to performance data, using a motivating example. We then introduced a model, called Dancing Midi  based on 1) two desirable, well-defined properties for edit operations and 2) two well-defined operations, $\operatorname{\textsc{\small split}}$ and $\operatorname{\textsc{\small concat}}$, with an implementation. We showed that our model formally satisfies the two properties, and that our model does not create most of the problems that occur with naive edit operations on our motivating example, as well as on a real-world example using an automatic harmonizer. Our approach has limitations. First, the model requires two parameters ($\varepsilon$ and the relative ratio), which have to be set by the user. Assigning these parameters to 0.15 beats and 20% respectively turned out to work well for most music we had to deal with. However, there are cases where these parameters should be tuned, especially for non typical music (e.g. extreme tempos or very dense). More generally, the model is monophonic by nature, so it does not make any inference on groups of notes (e.g. chords). This may produce, in rare cases, strange behavior (like treating one note of a chord differently than others).

However the reversibility of the operations (no undo mechanism is required by construction) and the light weight nature of the model (complexity is linear in the number of segmentation points) makes it worth using in many cases as it clearly improves on naive editing.

acknowledgement

We thank Jonathan Donier for fruitful remarks and comments.