Introduction au Live Object Model

API, Live Object Model, pourquoi?

Live est un logiciel complexe et complet, mais qui ne peut pas répondre à tous les différents cas d’utilisation et tous les usages spécifiques, ni intégrer tous les périphériques matériels existant. C’est pour cela qu’Ableton a intégré dans son logiciel une « API » (Application Programming Interface), qu’il faut considérer comme une porte d’accès aux entrailles du logiciel, et un moyen supplémentaire de se l’approprier.

Cette API est utilisée par les « Scripts » de Surface de Controle (qui sont programmés grace au langage Python), et également par Max For Live. C’est à cette utilisation que nous allons nous intéresser.

Max For Live est l’intégration dans Live d’un logiciel de conception d’effets et instruments Audio et MIDI (Max/MSP). Il comporte également des « objets » qui permettent de dialoguer avec l’API de Live et de créer ses propres « Devices » (périphériques en français).

Un des intérêts de Max For Live est qu’il existe un grand nombre de périphériques disponibles, et qu’il est facile de regarder comment ils sont faits et d’en copier une partie. Il n’est donc pas nécessaire de tout savoir programmer.

Le Live Object Model

Pour pouvoir accéder aux différents éléments d’un Set Live et interagir avec eux, nous avons besoin de nous repérer dedans. C’est à ça que sert le Live Object Model (ou LOM). Il nous fournit un chemin d’accès à une grande partie des différents éléments composant Live.

On peut par exemple savoir quel est le Volume de la 3ème piste et ensuite le régler, ou bien trouver quelle est la valeur de la quantification d’enregistrement, ou bien encore régler le tempo ou lancer un Clip. Ce ne sont que quelques exemples des milliers de possibilités qu’offrent Live et Max For Live.

Pour chaque action ou valeur, il suffit de trouver le chemin d’accès au paramètre ou élément qui correspond. Le LOM nous fournit donc une carte pour se diriger dans Live.

 

Représentation des différents éléments de Live, et leur hiérarchie dans le LOM.

Il y a 3 « racines » différentes, qui se trouvent au sommet de la hiérarchie : l’Application, le Set Live, et les Surfaces de Controle. Chacune donne accès aux composants à l’intérieur. Ces composants sont appelés « Classes ».

  • L’Application concerne le programme à proprement parler, et donne par exemple accès au numéro de version de Live, aux boites de dialogue…
  • Le Set Live, qui est nommé « Song » dans le LOM, est le « chemin racine » que l’on utilise le plus souvent. Grace à lui, on peut accéder aux éléments principaux de Live: les pistes (Track), Scenes (Scene) et repères d’Arrangement (CuePoint). Enfin, comme beaucoup de composants du LOM, il a une partie appelée « View », qui donne accès à ses aspects d’affichage. Pour un Set Live, ce sera par exemple les éléments actuellement sélectionnés, est-ce que le mode Dessin est activé etc…
  • Les Surfaces de Controle, qui ont leur propre Classe, mais sont aussi accessibles par le chemin racine « Application ».

On peut constater sur le graphique que la plupart des Classes et objets découlent du chemin Song->Track. C’est parce que dans Live, presque tout repose sur les pistes: les Clips, les périphériques, le mixeur, les notes et instruments découlent tous de pistes.

Note: on commence toujours à compter les éléments en partant de 0. Donc la piste qui s’appelle 1 dans Live, s’appelle 0 dans le LOM. Cela peut paraitre bizarre, mais cela facilite beaucoup d’opérations dans MaxForLive.

Il est donc important de bien se représenter la structure d’une piste et de ses éléments:

  • Track.View: donne accès aux aspects d’affichage, par exemple:
    • Est-ce que la piste est repliée?
    • Quel est le périphérique actuellement sélectionné…
  • MixerDevice: cette classe représente le Mixeur de la piste et ses différents composants, par exemple:
    • Volume
    • Panoramique
    • Entrées/Sorties
    • VU-Metre…
  • Device: s’il y en a, les périphériques présents sur la piste, dans l’ordre. Si la piste contient des Racks, les Devices présents dans le Rack seront atteints en précisant leur numéro de chaine dans le Rack.
  • ClipSlot: les emplacements pour recevoir des Clips de la vue de Session. Un ClipSlot a des propriétés et des fonctions, même s’il ne contient pas de Clip. Il peut être lancé, arrêté, on peut enregistrer dedans. Autre exemple: quand on duplique un Clip, en fait on duplique le contenu du ClipSlot dans lequel il est. Les Scenes ne sont en fait qu’une vue horizontale des ClipSlots, avec quelques propriétés supplémentaires.

A chacun son chemin

On peut donc accéder à un élément grace à son chemin à travers la hiérarchie.

Dans l’exemple ci-dessus, si l’on veut accéder aux différentes propriétés de l’EQ8 qui se trouve sur la piste Bass, le chemin d’accès sera donc:

Set Live -> Piste 2 -> Périphérique 3

La classe correspondant à un périphérique s’appelle « Device ». Si l’on regarde dans la documentation du Live Object Model, on peut lire :

  •  
  • Device :

  • Cette classe représente un périphérique MIDI ou audio dans Live.

    • Chemin d’accès : live_set tracks N devices M
      Chemin d’accès : live_set tracks N devices M chains L devices K
      Chemin d’accès : live_set tracks N devices M return_chains L devices K

Il y a donc 3 chemin d’accès, selon que le périphérique se trouve :

  • à la position n° M directement sur la piste n° N,
  • à la position n° K sur une Chaine n° L à l’intérieur d’un Rack n° M
  • à la position n° K sur une chaine de retour n° L à l’intérieur d’un Drum Rack n° M.

Dans notre cas l’EQ8 ne se trouve pas dans un Rack, le chemin d’accès sera donc :

live_set tracks 1 devices 2 

Souvenez-vous, dans le LOM on commence à compter à partir de 0. Donc la piste 2 s’écrit track 1 et le périphérique 3, device 2.

 

Enfants, propriétés, fonctions

 

En regardant la documentation, on remarque que la plupart des classes possèdent des Enfants, des Propriétés et des Fonctions.

  • Enfants : ce sont toutes les Classes qui dérivent de la Classe étudiée. 
  • Propriétés : pour chaque Classe, il existe un certain nombre de paramètres dont on peu obtenir la valeur et/ou qui peuvent être réglés.
    • Pour changer la valeur d’une propriété, on utilise la fonction « set« . Par exemple, pour régler la position de début d’un Clip à la mesure 12, on écrira set start_marker 12.
    • Pour récupérer la valeur d’une propriété, on peut soit utiliser « get » pour « demander » la valeur, soit « observer » la valeur en temps réel. Par exemple, pour récupérer la valeur du tempo, on pourra écrire get tempo.
    • Certains paramètres peuvent uniquement être récupérés (par exemple pour savoir si une piste a une entrée audio, ou bien savoir s’il y a des actions à annuler…).
  • Fonctions : les fonctions sont utilisées pour effectuer des actions, comme par exemple lancer un Clip, créer une piste audio, quantifier un Clip MIDI… pour appeler une fonction, on utilise call puis le nom de la fonction suivi éventuellement d’arguments. Dans les exemples précédents, les appels seraient: call fire, call create_audio_track, call quantize.

Et maintenant, voyons comment cela s’intègre dans Max For Live.

Les objets Max For Live du LOM

 

Pour obtenir le controle d’un élément de Live, Max For Live dispose de 3 objets dédiés:

  • live.object permet de régler ou d’obtenir la valeur du paramètre controlé grace aux appels get et set. C’est également cet objet qui permet d’appeler les fonctions. 
  • live.observer permet d’observer en continu les changements de valeurs d’une propriété. Pour pouvoir être observée, une Propriété doit avoir « observe » dans sa section « ACCES ».
  • live.remote~ prend le controle direct d’un paramètre. C’est l’équivalent dans Live d’une Macro dans un Rack: le paramètre controlé devient grisé, il ne peut plus être mappé ni automatisé.

Chacun de ces objets doit donc savoir à qui il doit s’adresser: quel paramètre observer, à qui donner telle valeur… Pour ceci, il faut lui communiquer l’identifiant du paramètre en question. Dans Max For Live, ceci se fait sous la forme d’un message que l’on envoie dans l’entrée supérieure droite de ces objets, contenant par exemple « id 12 » si le paramètre avec lequel on veut interagir a pour numéro d’identifiant 12.

Pour connaitre le numéro d’id d’un paramètre, il faut utiliser un autre objet: live.path. C’est live.path qui va transformer le chemin d’accès « logique » du LOM en un identifiant que Max For Live va être capable de comprendre.

live.path a une seule entrée, par laquelle nous donnons le chemin d’accès sous forme de message.

Par exemple, pour obtenir le numéro d’id du Set Live, il faut envoyer 

path live_set

à l’objet live.path:

Le numéro d’id du Set Live est 1.

Si on communique ce numéro d’id à un live.object, nous avons accès à toutes les Propriétés et Fonctions de Song, autrement dit du Set Live.

Par exemple, pour récupérer le tempo, il suffit de donner l’id 1 dans l’entrée supérieure droite de live.object, et d’envoyer le message « get tempo » dans l’entrée supérieure gauche.

Pour voir un exemple concret de l’utilisation du Tempo dans Max For Live, regardez l’exemple n°1.

Autres objets MFL spécifiques à Live

 

Il existe de nombreux objets faisant le pont entre Live et MFL. Certains sont en rapport avec le LOM, d’autres sont graphiques, d’autres fonctionnels.

En voici quelques uns:

 

Retour en haut
Retour haut de page