Introduction

L’apprentissage de la création musicale via des algorithmes d’apprentissage automatique connaît un engouement très fort ces 5 dernières années. Avec l’émergence de l’apprentissage profond (deep learning), de nombreuses architectures de réseaux neuronauxn comme les réseaux neuronaux convolutifs (convolutional neural networks, CNN), les réseaux neuronaux à mémoire court-terme et long-terme (long-short term memory networks, LSTM), et les machines de Boltzmann restreintes (restricted Boltzmann machines, RBM) sont de plus en plus prisées pour les travaux de création de musique algorithmique (pour plus d’informations, vous pouvez vous référer à ce sondage.

Dans ce rapport, nous examinerons l’article Music Transformer, de Huang et al. de Google Magenta, qui propose une architecture de génération de musique basée sur un modèle de langage de pointe. C’est l’un des tout premiers travaux à présenter les Transformers, qui ont rencontré un immense succès dans le domaine du traitement automatique du langage naturel (Natural Language Processing, NLP), au domaine de la génération de musique symbolique.

Contexte

Généralement, il existe deux approches principales pour représenter la musique dans une tâche de génération. La première approche est de représenter la musique sous forme d’ondes audio. Avec cette approche, la représentation courante des données musicales inclut des formats waveform bruts, des spectrogrammes, des spectrogrammes de Mel, des transformées à facteur de qualité constant (ou transformées à Q constant, TQC), et ainsi de suite. La deuxième approche consiste à représenter la musique sous forme de tokens d’événements symboliques. Cela peut prendre la forme d’événements MIDI (utilisée dans ce rapport), de rouleaux de piano (piano rolls), de texte (ex: notation ABC), et ainsi de suite. Un rapport W&B précédent présente JukeBox, qui utilise une approche basée sur l’audio pour générer de la musique. Dans ce rapport, nous présenterons Music Transformer, qui, lui, utilise l’approche basée sur la symbolique.

Représenter la musique de piano sous forme de tokens d’événements

Les événements MIDI mappent chaque action granulaire lorsqu’on joue du piano en tant que tokens d’événements. Dans ce travail, les 4 types d’événements suivants sont modélisés :

1. NOTE_ON - appuyer sur une note
2. NOTE_OFF - relâcher la note
3. TIME_SHIFT - avancer jusqu’au prochain intervalle de temps
4. SET_VELOCITY - paramétrer la vitesse à laquelle les notes doivent être jouées

Ici, un total de 128 événements NOTE_ON et NOTE_OFF sont introduits, ce qui correspond à 128 hauteurs de note (note pitches), ainsi que 100 événements TIME_SHIFT (de 10 millisecondes à 1 seconde), et 128 événements SET_VELOCITY qui correspondent à 128 vélocités de note différentes. Voyez ci-dessous un exemple cité dans l’article.

En utilisant cette approche, nous pouvons voir que cela correspond à la tokenisation dans le traitement automatique des langues :

• Un morceau de musique correspond à une phrase ou un paragraphe ;
• Chaque événement de note correspond à un mot dans la phrase/le paragraphe ;
• Tous les événements possibles de notes forment le "set de vocabulaire" (vocabulary set).

Il est donc tout à fait raisonnable d’utiliser les Transformers comme architecture pour notre modèle de génération, puisque nous traitons la génération de musique comme une tâche de génération de langage.

Music Transformer vs Transformer de base

Les Transformers de base (Vanilla) sont tristement connus pour leur processus de prise en charge deslongues séquences, du fait de leur prérequis de mémoire quadratique. Cela pose un énorme problème, en particulier pour la génération de musique, parce qu’une composition d’une minute peut facilement contenir des milliers de tokens d’événements MIDI. Par ailleurs, les auteurs ont fait remarquer que l’information de position relative était importante pour les applications musicales, parce que la musique consiste souvent en des phrases structurées comme les répétitions, les gammes et les arpèges. Ainsi, le modèle devrait être capable de capturer l’information de position relative d’une manière plus efficiente.

Partant de ses considérations, les auteurs de cette publication ont amélioré le modèle Transformer avec les changements suivants.

1 - Attention relative

La principale différence entre les deux Transformers réside dans le mécanisme d’attention autonome (self-attention mechanism). Les Transformers de base se reposent sur une attention par produit scalaire (scaled dot-product attention), qui peut être représentée par l’équation ci-dessous : $Attention(Q,K,V)=softmax(\frac{Q{K}^T}{\sqrt{d_k}})V$

où $Q$, $K$, $V$eprésentent respectivement les tenseurs de requête (query), de clef (key) et de valeur (value), chacun ayant une forme tenseur ($l$, $d$) qui représentent respectivement la longueur de séquence et le nombre de dimensions utilisées dans le modèle. L’attention relative, proposée par Shaw et al., permet au modèle d’être informé de la distance entre deux positions différentes dans une séquence. Pour représenter cette information, l’équation est changée comme ci-dessous :

$Attention(Q,K,V)=softmax(\frac{Q{K}^T+S_{rel}}{\sqrt{d_k}})V$

Le terme additionnel, $S_{rel}$​, est un tenseur de forme ($l$, $l$) et les valeurs dans le tenseur vi,j​ sont liées à la distance relative des positions i et j en une longueur l. Puisqu’elle est relative par nature, cela signifie que si i1 – j1 = i2, alors vi1​,j1 ​​= vi2​,j2.

Alors, comment obtenir $S_{rel}$?

1. Tout d’abord, nous initialisons un set fixe de plongements Er (embeddings) contenant un plongementer​ pour chaque distance relative $r=i–j$.
2. Ensuite, nous formons un tenseur 3D $R$ de forme $(l,l,d)$, où $R_{i,j}=e_{i-j}$​.
3. Pour finir, nous reformons $Q$ en un tenseur $(l,1,d)$, et $S_{rel}=Q{R}^T$.

2 – Une implémentation à faible consommation de mémoire

Si l’on considère le diagramme ci-dessus, il est clair que le tenseur R intermédiaire requiert une empreinte mémoire O(L2D), ce qui n’est pratiquement pas faisable pour de longues séquences. Ainsi, les auteurs ont proposé une astuce de « désalignement » (skewing) qui peut obtenir $S_{rel}$​ sans calculer $R$ et maintenir ainsi l’empreinte mémoire au niveau $O(LD)$.

Les étapes sont les suivantes :

1. Multiplier $Q$ par$E_r$ ;
2. Ajouter un vecteur factice à la colonne la plus à gauche ;
3. Redonner une forme à la matrice de sorte d’avoir une forme $(l+1,l)$:
4. Trancher la matrice pour obtenir les $l$dernières lignes, qui correspondent à $S_{rel}$

Résultats

Comme indiqué dans la publication, l’architecture Music Transformer proposée présente clairement des avantages par rapport à la musique de piano générée par les Transformers de base et un modèle basé sur des LSTM (appelé PerformanceRNN) :

1. Si l’on compare les Transformers aux LSTM, les modèles basés sur les Transformers sont généralement meilleurs pour préserver et réutiliser un motif de base. Par l’utilisation de l’attention relative, Music Transformer crée des phrases qui sont répétées et variées, alors que le Transformer de base utilise le motif de manière plus uniforme. Le modèle LSTM utilise le motif au début, mais dérive rapidement vers d’autres choses.

2. Si l’on compare le Transformer de base au Music Transformer, on peut observer que l’attention relative a été capable de se généraliser à des longueurs plus importantes que les longueursentraînées. Le Transformer de base semble se détériorer au-delà de sa longueur d’entraînement, tandis que Music Transformer reste toujours capable de générer une structure musicale cohérente.

Génération de musique

Il existe 3 différents modes de génération de musique en utilisant les modèles pré-entraînés de Music Transformer : (i) la génération à partir de rien, (ii) la génération à partir d’une mélodie de base, et (iii) la génération d’un accompagnement pour une mélodie.

Nous commençons avec le notebook Colab fourni par Google Magenta, puisqu’il prend déjà en charge le chargement de modèle pré-entraîné, l’initialisation du framework de tensor2tensor et la définition de problème. Les fichiers audios générés, ainsi que les graphiques de rouleaux de piano correspondants, sont enregistrés comme indiqué ci-dessous, en utilisant la bibliothèque de Weighs and Biaises wandb.

Reproduire les résultats avec ce Colab notebook

Générer à partir de rien

Générer à partir d’une mélodie de base

Générer un accompagnement pour une mélodie donnée

Résumé

L’article Music Transformer est une excellente documentation qui transpose la puissance d’un modèle de langage au domaine de la génération de musique symbolique, et qui permet de générer des morceaux pour piano plus longs avec une structure et un style musical cohérents. Avec l’émergence actuelle de diverstransformateurs à complexités linéaires, il sera également intéressant de se pencher sur l’impact du remplacement de l’architecture Music Transformer avec des candidats tels que Linformer et Transformers are RNNs, puisqu’ils partagent l’avantage d’un mécanisme d’attention à temps linéaire (linear-time attention mechanism).

Si vous souhaitez en savoir plus, nous vous invitons à consulter la publication originale, eet ce article de blog sur Music Transformer..

Nous serons ravis d’écouter les morceaux de musique au piano que vous aurez générés ! @gudgud96en mentionnant @weights_biases