Groupes répétitifs et réservoirs

Comme nous l’avons vu au chapitre 4, l’orchestration consiste à définir des groupes de patterns qui seront activés et désactivés par cette orchestration. L’activation consiste à signifier à l’audience à travers une interface Web accessible depuis des smartphones, des tablettes ou des ordinateurs quels sont les patterns disponibles. Les membres de l’audience peuvent alors sélectionner des pat- terns qui seront joués par des synthétiseurs ou des musiciens.

Il y a peu de contraintes pour la conception d’un groupe. Un groupe peut contenir un ou plusieurs patterns. On peut retrouver le même pattern dans plusieurs groupes. On peut mettre des patterns d’instruments différents dans un même groupe.

Nous avons introduit rapidement au chapitre 4, deux catégories de groupe : la catégorie groupe répétitif ou la catégorie réservoir. Comme nous l’avons vu dans ce chapitre, un groupe répétitif est un ensemble de pat- terns qui peuvent être sélectionnés à la demande de l’audience sans contrainte. Un réservoir est un en- semble de patterns où chaque pattern sélectionné est enlevé de l’ensemble. Dans un groupe répétitif, le même pattern peut être sélectionné plusieurs fois, dans un réservoir le même pattern ne peut être sélec- tionné qu’une seule fois. Il est aisé de saisir de façon intuitive l’intérêt de l’un ou l’autre modèle. Pour un

groupe de patterns conséquent et utilisé pour maintenir une atmosphère, un groupe répétitif est bien adapté. Pour des patterns en petit nombre qui doivent avoir un rôle de ponctuation du dis- cours, de type percussion explosive, dont le but et de provoquer une rupture de contexte par exemple, on préfèrera un réservoir pour éviter que les patterns se répètent et posent une atmos- phère stable.

Nous avons expérimenté ces deux types de groupes, on peut en imaginer d’autres comme des ré- servoirs autorisant un nombre limité de répétitions par exemple. Ces groupes de patterns sont le matériel de base de l’orchestration. Comme nous l’avons vu, l’activation d’un groupe signifie qu’il devient accessible à l’audience et qu’avec une interface homme-machine adaptée, les individus de l’audience pourront demander l’activation d’un pattern appartenant à ce groupe. Les activations sont déclenchées en HipHop.js à l’aide des signaux se terminant par « OUT ». Nous en avons croi- sées dans les exemples précédents liés au langage HipHop.js.

Comme nous l’avons vu, l’art de l’orchestration est de définir quelles seront les règles d’activation et de désactivation des groupes de patterns. Pour définir ces règles, le compositeur devra tenir compte de ce que pourrait faire l’audience, donc gérer des durées au sens où ce qui définira le déroulement sera la perception de l’œuvre en cours par l’audience, donc les consciences qui cons- tituent l’audience. Nous sommes dans une forme de durée proche de la définition de Bergson au service de l’œuvre ouverte d’Eco [23]. La principale façon de tenir compte du comportement de

74

l’audience que nous avons imaginée, est de prendre en compte l’émission de signaux liés aux groupes de patterns comme nous l’avons vu au chapitre 4. Un signal correspondant à un groupe de

patterns sera émis à chaque sélection par l’audience d’un pattern dans ce groupe. La mise en œuvre

se fait au moyen des signaux se terminant par « IN » dans les exemples précédents. Notons que si le compositeur tient explicitement à identifier un pattern particulier et non pas un groupe, il lui suffit de définir un groupe avec un seul pattern. Nous avons retenu l’idée de groupe car elle permet une bonne ouverture et n’est pas restrictive puisqu’un groupe peut être un singleton. Voyons com- ment ces groupes se mettent en œuvre avec HipHop.js.

6.2.2.1 Le codage des groupes répétitifs

Pour mettre en œuvre un « groupe répétitif » (que nommerons simplement « groupe » pour faire plus court) nous avons besoin de trois choses : la liste des patterns qui constitue ce groupe, un signal d’activation/désactivation, un signal correspondant à une demande de pattern de ce groupe par l’audience. Ces différents signaux sont construits à partir de fichiers de configuration associés à chaque pièce musicale. Rappelons-nous l’instruction implements vue dans nos exemples au cha- pitre 5.2, Programmer avec HipHop.js.

1. hiphop module trajetModule3(in start, stop, tick, abletonON)

2. implements ${nuceraInt.creationInterfaces(par.groupesDesSons[2])} {

Cette instruction permet d’intégrer des signaux dans un module en suivant le modèle exposé dans la construction dynamique de programme. Voici le code de la fonction creationInterfaces() :

1. "use hiphop"

2. "use hopscript"

3.

4. const hh = require( "hiphop" );

5.

6. function creationInterfaces(groupes) {

7. return <hh.interface>

8. ${ groupes.map( function(k) {

9. return <hh.signal name=${ k[0] + "OUT"}

10. direction="out" value=${ [false, -1] } />;

11. }

12. )}

13. ${ groupes.map( function(k) {

14. return <hh.signal name=${ k[0] + "IN"}

15. direction="in" value=${ [0] } /> ;

16. }

17. )}

18. </hh.interface>;

19. }

20. exports.creationInterfaces = creationInterfaces;

Nous utilisons dans cette fonction une syntaxe intermédiaire de HipHop.js, sous un format XML. La balise interface est un élément de syntaxe utilisée par l’instruction implements pour prendre en compte une liste de signaux. Nous voyons qu’à partir du tableau groupes nous créons, avec l’ins- truction JavaScript map() deux types de signaux pour chaque élément du tableau. Un signal : nomDuGroupeOUT([false, -1]);

Où la valeur false, signifie que le groupe est par défaut inactif, -1 signifie qu’aucun groupe d’utilisa- teurs n’est concerné par ce signal par défaut. Et un signal :

75 nomDuGroupeIN();

qui sera reçu par l’orchestration à chaque fois que quelqu’un dans l’audience aura demandé un pattern du groupe nomDuGroup.

L’activation d’un groupe répétitif se traduira donc par une commande du type :

emit groupeOUT([true, 255]);

sa désactivation par :

emit groupeOUT([false, 255]);

le 255 signifie que tous les groupes sont concernés, nous aurions pu préciser un sous-groupe avec une valeur inférieure à 255.

6.2.2.2 Le codage des réservoirs

La mise en place d’un réservoir suit le même processus qu’un groupe répétitif pour la création des signaux. La différence est dans sa gestion à l’intérieur de l’orchestration. Il s’agit à l’intérieur d’un réservoir de désactiver chaque pattern après sa sélection par l’audience. Un réservoir est donc techniquement un sur-ensemble de groupes répétitifs avec dans chaque groupe répétitif un seul pattern. Voici la fonction de création d’un réservoir :

1. function makeReservoir(instrument) {

2. return hiphop

3. laTrappe: {

4. abort immediate (stopReservoir.now) { 5. // Début demake réservoir

6.

7. ${instrument.map( function(val) {

8. return <hh.emit ${ val + "OUT" } value=${ [true,255] } />

9. })

10. }

11. hop { gcs.informSelecteurOnMenuChange(255,instrument[0], true); }

12.

13. ${makeAwait(instrument)}

14. // Fin naturelle du réservoir

15. break laTrappe;

16. }

17. ${instrument.map( function(val) {

18. return <hh.emit ${ val + "OUT" } value=${ [false,255] } />

19. })

20. }

21. hop { gcs.informSelecteurOnMenuChange(255,instrument[0], false); }

22. hop {

23. // Abort du réservoir

24. // et message la gestion des réservoirs dans l'affichage de la partition

25. hop.broadcast('killTank', instrument[0] );

26. }

27. }

28. }

Cette fonction reçoit un tableau contenant la liste des instruments. Nous avons ici le principe de génération de code rencontré précédemment pour les interfaces avec le code HipHop.js dans son format XML. Nous retrouvons la syntaxe HipHop.js précédée de balises hh. Le abort de la ligne 4 introduit un moyen de stopper le déroulement d’un réservoir en cours de performance. Le module faisant appel au réservoir pourra à tout moment émettre le signal stopReservoir qui activera le

76

abort et mettra fin au réservoir. En ligne 25 nous voyons apparaitre une commande Hop.js,

hop.broadcast(). Nous utilisons régulièrement cette commande lorsqu’il s’agit de diffuser une information vers plusieurs clients. Ici l’information diffusée concerne l’affichage de l’orchestration que nous verrons plus loin.

Voici le code de la fonction makeAwait() appelé en ligne 13 :

1. function makeAwait(instrument) {

2. return <hh.parallel>

3. ${instrument.map( function(val) {

4. var code =

5. <hh.sequence>

6. <hh.await ${ val + "IN" } />

7. <hh.emit ${ val + "OUT" } value=${ [false,255] } />

8. <hh.atom apply=${function() {

9. gcs.informSelecteurOnMenuChange(255, val, false); }

10. } /> 11. </hh.sequence> 12. return code; 13. }) 14. } 15. </hh.parallel> 16. }

Il s’agit une fois de plus de code généré dynamiquement qui met en parallèle des commandes await

(ligne 6) sur des sélections de patterns et désactive avec emit (ligne 7) le « groupe » composé d’un seul élément qui correspond à ce pattern.

Nous avons rencontré plusieurs fois :

hop {gcs.informSelecteurOnMenuChange(255,instrument[0], true);}

C’est une commande nécessaire à la mise à jour de l’affichage sur les terminaux clients. Cette com- mande n’est pas lancée de façon automatique pour permettre au compositeur de contextualiser le message correspondant à l’activation d’un groupe de patterns.