goto step via midi/osc

Hello, ça fait un moment que je cherche et que j'essaie différente manière et ca m'étonne que personne n'ai soulevé le problème :

J'utilise QLab pour commander DLight. Au départ, je faisais de simple GO via une commande MIDI manuelle puis, je me suis dis qu'utiliser les MSC était plus propre, notamment parce qu'il permette d'appeler une CUE bien spécifique... Depuis, je configure systématiquement des message MSC GO X (avec X, la cue que je désire lancer). Le problème avec cette méthode est que DLight appelle systematiquement la première occurence de la cue X dans la séquence complète. Hors, il m'arrive (souvent) d'avoir plusieurs fois un même état mais avec des temps de fade IN/OUT différents... Deux solutions alors, soit faire un simple GO sans préciser de numéro de CUE, soit faire un duplicata de la CUE pour chaque occurence mais ca n'est pas très propre en cas de changement d'une état pour une raison quelconque...

Hors, la "beauté" du MSC GO X serait de pouvoir laisser DLight en arrière plan même en répétition car il se resynchronise tout seul avec QLab, et donc, de faire un GOTO STEP et non un GOTO CUE...

J'ai essayer de préciser la CUE LIST et j'ai essayé les différents message OSC qui laissait entendre que peut-être il fonctionnerais comme cela mais je n'ai rien trouvé qui fonctionne en un seul appel... Le message /seq/goto x charge effectivement le step X mais je respecte aucun de ses timing/MLink, etc.

Au final, on est obligé de faire deux message OSC : /seq/X2 X puis /seq/go mais je ne sais pas pourquoi, chez moi, le message /seq/go ne fait absolument rien... (sous la 4.0b26, je dois faire /seq/go Y avec Y, un numéro quelconque...) Bref, pas très propre non plus selon moi car l'ordre d'arrivée n'est pas garantis (UDP si je ne me trompe) et on est obligé d'avoir un certain delai entre plusieurs message sinon, dlight a un comportement aléatoire...

Y aurait-il moyen d'avoir un message /seq/X2LoadAndFireStep X à l'image du /seq/X2LoadAndFireCue X qui fonctionne exactement que le MSC GO X? Ou utiliser un autre message MSC à cette fin?

hello

je pense que remplacer le message load and fire cue par load an fire step n'est pas la solution idéal à ton problème. qu'est-ce qui se passera si tu rajoutai un step dans la conduite ? tu devrai modifier tous tes go depuis QLab non ?

le problème comme je le vois ici c'est plutôt : comment gérer dans DLight le fait d'avoir plusieurs cues identiques dans le séquenceur, chargées dans différents pas, et de pouvoir au besoin, changer l'état de cette cue, pour tous les pas.

as-tu essayé de créer un groupe, et de le rappeler dans les cues via le MLink ?

Effectivement. J'était en train de retourner le forum pour voir les nouveautés de la beta 26 et je suis tombé sur une demande avec la même remarque...

Pour le moment, je procède en 2 temps :
1- je ne fait que des GO le temps d'avoir toute la créa lumière
2- je les change en GOTO CUE une fois que la créa est terminée (ou quasi), ce qui évite de changer tout le temps le signaux QLab

Ceci dis, il est vrais qu'on ne sait jamais et cette solution n'est pas la meilleure...

Créer un groupe, pourquoi pas... Avec le risque d'avoir plein de groupe commandé par des MLink en plus des cue manuel (j'en ai toujours au moins 2 en manuel plus les inhib et autres...) J'essayerais comme ça la prochaîne fois mais ca me semble un encodage plus fastidieux, particulièrement si on fait des changement en live... (il faut retrouver le bon groupe si on en a beaucoup d'ouvert, l'ouvrir, activer le mode de modification live pour ne pas que cela se voie de trop, faire son édition à sa guise puis tout refermer...)

J'écris ici mes rélféxions sans approfondir :

On pourrait changer le comportement du GOTO CUE pour qu'il charge la prochaîne occurence de cette CUE dans le sequenceur (ou la précédente si on revient en arrière) mais ça peut vite devenir le bordel en répétition et ce n'est pas très propre...

On pourrait également préciser l'occurence du CUE qu'on désire charger... Ca permet d'avoir plusieurs fois le même CUE dans le séquenceur et de dire qu'on veut charger le 3ieme pas contenant la cue X. Avec un risque de devoir décaler si on ajouter des pas avec cette même CUE mais bon, c'est plus rare...

Finalement, le problème est que les numéros du séquenceur sont forcément en suite croissante par pas de 1. En répétition, il n'est donc ni propre d'appeler un pas spécifique car il est susceptible de changer de numéro, ni d'appeler un CUE car il peut avoir plusieurs occurence. Sémantiquement, un CUE n'est pas unique. Hors, le propre d'un GOTO X est d'être certain de ce qu'on veut charger... Il faudrait donc un troisième élément numérique que je vais nommer ici Step ID qui serait, lui, unique à chaque pas de séquence (tout comme leur numéro d'ordre) mais qui aurait l'avantage de ne pas être restrain à une suite logique si ce n'est que ce numéro serait associé à son pas lors de ça création : soit à l'ouverture d'un nouveau fichier, soit par insertion de ce pas, soit lors d'un record cue qui ajoute le pas dans lequel il sera chargé. Ainsi, on pourrait charger directement un pas bien spécifique dans tout les cas. Evidemment, ce StepID, tout comme le numéro d'ordre du pas ne pourrait être modifié par l'utilisateur (ou alors, il faut des mécanismes de vérification de doublon) et, à la fin d'un création houleuse (avec beaucoup de modification de la conduite lumière), son ordre serait du genre chaotique mais ça ne serait pas grave tant qu'il reste unique...

J'avoue que j'aime assez bien cette idée du StepID car c'est clairement ce qu'il faut dans ce cas...

je suis content que tu ouvres cette discussion car effectivement je trouve que ça serait vraiment un plus de pouvoir gérer le "multi-cue"

a la place du step id, on pourrait "simplement" envisager un moyen de linker des cues entre-elles. donc on pourrait avoir des cues avec un numéro différent, mais à chaque fois le même contenu - affiché en live comme un cue normal. a l'exception qu'elles seraient linkées, donc si on en modifie une, après enregistrement, ça les modifient toutes.

le numéro de la cue deviendrai alors le step id.

Mouais, ça me paraît compliqué à mettre en parce qu'en cas de modiication "live", n'importe quelle cue devra modifier toutes les autres du coup, ça fait du code... Mais pourquoi pas... Je propose qu'on attende son avis à nico

Ou alors, il faudrait étendre les CUE et pouvoir charger des groupes dedans.... Mais comme les groupe peuvent déjà charger des CUE, c'est pas possible... Ou alors, on revient à la solution du MLink...

Je reste fan du StepID, ça me semble beaucoup plus propre d'un point de vue structurel/semantique. Ça me semble évident que chaque STEP doit avoir une référence unique et immuable, sinon, le GOTO X n'a pas d'intérêt car il prête à confusion...

En fait, je vient de tomber sur un post à toi faisant référence à la nécessité de garder les cue dans l'ordre, quitte à mettre des virgules... J'y avait jamais pensé...

Du coup, ça résout presque ce qui m'embête dans le step ID : c'est un deuxième numéro unique au step. Son seul avantage est d'être immuable contraire au numéro de pas... Imaginons que lorsqu'on insère un pas, au lieu de décaler tout les pas suivant afin de garder des numéros entiers, le pas insérer aie un numéro à virgule également... Ça permet de garder les numéros dans l'ordre tout en permettant que chaque pas de séquence garde son numéro de départ...

Donc, au lieu de passer de
S1 C1
S2 C2
S2 C1

à
S1 C1
S2 C1.5
S3 C2
S4 C1

Ce qui a pour seul intérêt de garde le auto_load_cue correct mais qui n'a aucun intérêt dans la suite et le goto cue, au aurait :
S1 C1
S2 C2
S3 C1

devient
S1 C1
S1.5 C1.5
S2 C2
S3 C1

Du coup, on garde les cue dans l'ordre pour l'auto_cue_load mais on garde également les numéro de pas. (Si je ne m'abuse, l'insertion est le seul cas ou on décale les numéros de séquences...)

--> ça résout le problème sans introduire de StepID car on rend le numéro de séquence immuable...

yo,
c'est cool les reflexions collectives...

l'histoire des cues référentes, j'y ai bien pensé, mais ça résolvait pas le pb du cue goto et ça complexifiait pas mal l'écriture des cues (en tout cas dans la version imaginée).
et le coup du stepID c'est pas mal...

les steps doivent être contigus et de nombre entier. je m'en sers pour l'indexation de la séquence et pour pas pénaliser la rapidité d'exécution de DL, on va laisser ça comme ça.

par contre on peut imaginer une nouvelle colonne dans le séquentiel (entre Step et Cue) appelée ID.
cette ID pourrait être composée de numéros à virgule (indispensable dans le cas d'insertion), initialisée à -1 (pas d'iD pour ce step) et également comme pour les steps unique dans ses références.
c'est a dire que par exemple, la séquence serait:
S1 ID1 Q1
S2 ID2 Q1.5
S3 ID3 Q1
S4 ID4 Q2

du coup je rajoute des messages OSC:
/seq/X2LoadIDAndLaunchGO
/seq/X2LoadID
/seq/X1LoadID

un raccourci clavier goto_ID

dites moi ce que vous en pensez, mais en tout cas bravo pour cette réflexion...
++

C'était exactement ce que je voulais dire avec le StepID sauf que j'imaginais des nombre entier qui pouvait être dans le désordre (pour l'insertion) mais permettre des virgule revient au même en gardant l'ordre donc c'est mieux...

Enfin je pense parce que je vois pas ou ça colle avec ton exemple... Les ID corresponde toujours avec les Step... Ou alors, imaginons qu'on ajoute une cue 1.5 entre la step 3 et 4, ça donnerait alors :
S1 ID1 Q1
S2 ID2 Q1.5
S3 ID3 Q1
S4 ID3.5 Q1.5
S5 ID4 Q2

C'est ce que tu voulais dire? Dans ca cas, c'est super

Et quand tu veux pour les reflexions collectives... Ça me manque un peu l'informatique pour le moment alors

j'ai l'impression que le concept du step ID et le numéro de cue peut être une et une seule information.

le fait de pouvoir créer un cue référente (appelons la cue 5) et de pouvoir la linker a n'importe quelle cue ( par exemple à la cue me parait le plus ergonomique.

en quoi ça pénalise le problème du cue goto ?

si je fais cue goto cue 8, je vais à la cue 8 ( pas à la 5), donc j'évolue dans l'arborescence de ma séquence.

en ce qui concerne le changement en live, si la cue est chargé dans fenêtre circuit, on a accès aux circuits et on peut les modifier à la volée. après si on enregistre l'état, il faudra trouver un moyen que cela enregistre la cue référente.

mais ce processus de modifier et d'enregistrer un cue à la volée existe déjà et fonctionne bien. resterai a trouver un moyen de linker tout ça (peut-être à la manière d'un "bus", comme avec une table de mixage son...)


enfin je sais pas, peut-être un détail m'échappe. mais j'ai l'impression qu'on pourrait utiliser le numéro des cues comme step id.
et de plus le auto_load_cue est quand même bien pratique. ça serait dommage de le sacrifier

Pas d'accord, parce que tu es toujours obliger de dupliquer l'information dans plusieurs CUE reelles avant de les linker... Et ce n'est pas propre... C'est ton pas qui est unique et non ta cue...

En plus, on ne sacrifie pas les cue_auto_load en ajouter un ID...

Mais si je regarde ce que tu propose, je ne pense pas non plus que ça pose problème pour le cue goto. Par contre, je ne connais pas le code de dlight (forcément) mais mon expérience me dis que c'est beaucoup moins propre et plus complexe à implémenter... Ne fusse que parce que tu dois retrouver toutes les cue qui lui sont linkée... Soit tu dois avoir une structure mémoire pour les retrouver rapidement, soit tu dois assigner un numéro unique par "groupe de cue"...

Ceci dis, ça pourraît aussi être intéressant de pouvoir linker des cue qui ne sont pas forcément identique, un peu à l'image des bang dans QLab... Ça permettrait de faire 2 modification en 1 coup sans devoir passer par le track et ne selectionner que les cue qui nous intéresse... (mais je ne vois pas un cas ou ça pourraît vraiment être utile sans rendre tout confus)

ok je rajoute quelques détails

x dans mon idée en linkant la cue 8 a la cue 5, le contenu de la cue 5 était automatiquement chargé dans la cue 8. pas besoin de copier le contenu, juste à indiquer un lien vers la source.

et on pourrai rajouter une sorte de flag pour savoir qui est avec qui.

x le auto_cue_load serait sacrifié si on ne garde pas les cues dans l'ordre numéraire - ça marche nettement moins bien

qu'est-ce t'en pense ?

En plus, tu pourrais très bien imaginer un cas particulier :

Tu a un cue "plein feu general" qui est linker avec plusieurs autre cue. Et puis, pour une raison particulière, pour un pas bien donner, tu veux modifier ce plein feu... Tu as alors le choix entre délinker la cue (mais il faut que tu te souviennes qu'elle est linkée, elle ne l'est pas forcément suivant ta construction initiale sous peine tout changer et de sauver sans t'en rendre compte) ou changer la cue pour en mettre une autre. Et du coup, tu dois aller modifier ton QLab (et tout ce qui dépend éventuellement de cette information...)

EDIT : tu ferais un enregistrer sous en rentrant le numéro de cue actuel. et là comme par magie dlight te propose : "cette cue est linké, voulez-vous rompre le lien avec la cue XX ? - ou alors tu le fais manuellement

réponse simultanée

Tu peux tout à fait garder les CUE dans l'ordre numéraire... Je vois pas en quoi c'est incompatible...

Enfin, je dois aller bosser, j'ai 1h30 de route avant de jouer ce soir alors...

j'ai répondu trop vite de toute façon.

la reflexion ne fais que commencer et ça s'annonce intéressant

les deux sont possibles.
on peut créer des Q référentes avec des Q linkées ou des StepID
les deux sont intéressantes.
donc au regard du code pur et dur:
- les Q linkées sont pas forcément hyper pénalisantes en termes de performances car comme l'a dit Aroom (qui pourrait un jour se mettre à coder) elles sont une listes de 'pointeurs' vers la Q référente.
et DL à quelques bonnes routines bien performantes pour pouvoir faire ça.
c'est la solution qui impacte le moins DL dans ce qu'il est ou tend à être en ce moment... pour autant il faut imaginer un système de flag rapide et pas lourd visuellement

-les StepID.
ya un truc séduisant là dessous et moins opaque que les Qlinkées.
qui peut éventuellement plus tard resservir pour des nouveaux trucs genre on charge dans un sub un extrait du séquentiel du StepID x au StepID y et on rejoue cette partie en boucle.
c'est pas faisable avec les steps car comme vous le savez tous les deux les steps évoluent vachement pendant le travail de conduite. C'est galère avec les Q et problématique si on en vient à supprimer une cue 'clé'
les stepID rajoutent une info visuelle dans le séquentiel....

perso j'aime bien les StepID mais c'est plus de boulot pour moi...
to be continued...

++