Épisode 8 : La cuelist, nerf de la guerre
Si, à l’aide des palettes et submasters que nous avons vus dans les précédents tutoriels, on peut réaliser un éclairage « à la volée » d’un concert ou d’un événementiel (chose que nous développerons dans un prochain tutoriel), il est plus compliqué d’utiliser ces outils pour restituer un spectacle qui doit être le même à chaque représentation, comme une pièce de théâtre par exemple. C’est précisément le rôle de la cuelist.
Littéralement « liste de cues », ce dernier terme anglais désigne un « signal », un « moment » (that’s my cue, c’est mon tour de jouer), la cuelist désigne donc une suite d’événements qui vont avoir plusieurs noms possibles. En effet, si vous suivez ces tutoriels depuis quelque temps déjà, vous avez compris que chaque fabricant de consoles aime avoir son propre lexique, quitte à ne pas faciliter la transition d’une console à l’autre pour les utilisateurs.
On trouve donc les termes « séquence », « séquentiel », « conduite », « liste de mémoire »… pour la cuelist et « cue », « tableau », « mémoire »… pour les états lumineux qu’elle contient.
La construction, une question de philosophie
Deux grandes philosophies de programmation de conduites s’opposent.
- Les consoles à mémoire
Dans ces pupitres, qui ont fait les grands jours du théâtre en France (Congo/Cobalt Avab et ETC, Liberty/Freedom ADB, D-Light…), les tableaux sont imperméables (sauf quelques exceptions). Chacun est un état lumineux propre et ne sera pas dépendant des mémoires précédentes. L’inconvénient est que pour modifier le niveau d’un circuit dans plusieurs tableaux consécutifs, il faut éditer toutes les mémoires une par une.
- Les consoles tracking
Apparus avec l’avènement des asservis, les pupitres qui suivent la philosophie tracking sont sensibles au changement. Les cues sont dépendantes les unes des autres. Si j’allume un circuit dans la cue 1, il va rester allumé tant que je ne change pas son état dans une cue plus loin. Les seules valeurs réellement enregistrées dans la conduite sont celles existantes dans les tableaux qui contiennent des changements. Entretemps, les valeurs sont dites trackées. Si, après l’encodage, je viens faire une modification d’un niveau dans le premier tableau, la valeur du circuit impacté est modifiée dans toutes les cues consécutives jusqu’au prochain changement.
L’idée est que les projecteurs asservis ne changent pas forcément d’état à tous les tableaux. Parfois, ils conservent la même couleur, position ou état pendant plusieurs cues. Autant alors n’avoir qu’une seule cue à modifier pour changer toutes les suivantes.
Une conduite tracking est donc plus rapide à éditer, mais il faut pour cela bien maîtriser sa console et son spectacle, car un seul changement peut impacter toute la cuelist.
Des options nombreuses
Bien sûr, des outils existent pour modifier ce comportement comme les Blocks, qui verrouillent une cue et empêchent qu’elle ne soit modifiée par un update de cue précédente, ou Cueonly, une fonction qui permet de ne modifier que la cue actuelle et pas la suivante. Selon les consoles, on va appliquer ceux-ci directement en tant qu’option de la cuelist (GrandMA…) ou au cas par cas lors des modifications (Eos).
