"request" associé au prg change midi

Bonjour,
J'utilise beaucoup l'assignation midi de prg change à des pas du séquentiel (via Live) et je remarque (depuis le début de cette fonction) 2 points qui manquent de souplesse :
1/ L'insertion d'un nouveau pas ne décale pas les n° de pas associés à un n° de prg change, il faut donc tout reprendre manuellement et tout re-vérifier car on peut insérer beaucoup d'erreurs sans s'en rendre compte, de plus...
2/ le prg change 1 étant associé au pas 0, il est facile de se mélanger les pinceaux 1>1, 2>2, 3>3 serait plus naturel. Peut-être qu'une option d'offset pourrait accorder tout le monde.
Ceci me fait penser indirectement à une autre idée pour pallier à des erreurs de régie : 1 go-go back associé au "load_step_X2"

@Fodor,
hello,

1/ L'insertion d'un nouveau pas ne décale pas les n° de pas associés à un n° de prg change, il faut donc tout reprendre manuellement et tout re-vérifier car on peut insérer beaucoup d'erreurs sans s'en rendre compte, de plus...

DL ne peut pas décaler les ProgChge car ils n'appartiennent pas aux pas de séquence.
par contre, ce que je pourrais ajouter c'est le controle des StepID par les ProgChge.
Ce faisant t'aurais plus d'histoire de décalage quand tu insères des nouveaux pas de séquence car les StepID appartiennent aux steps (et donc se décalent automatiquement) et sont uniques.
Si tu veux dores et déjà essayer les stepID tu peux utiliser le MidiShowControl (MSC) ou passer en OSC.

2/ le prg change 1 étant associé au pas 0, il est facile de se mélanger les pinceaux 1>1, 2>2, 3>3 serait plus naturel. Peut-être qu'une option d'offset pourrait accorder tout le monde.

disons que vu que les steps commencent à 0 je préfère garder le système actuel.



pour de la synchronisation machine, le mieux, c'est le nouveau système des StepID.
++

ok, je vais regarder ça

hello,
avec la b41, j'ai mis les StepID accessible avec les ProgramChange.
peux-tu tester et me dire si ça fonctionne chez toi?


++
nico

Ok, je vais voir ça aujourd'hui, merci

Pascal

1ere constatation : un prg change 1 étant reçu par dlight comme un prg chg 0 tout est décalé.
Je persiste quand même à penser que l'ID 0 n'existant pas, elle ne devrait pas être utilisée puisqu'elle ne peut pas être transmise. Sinon, le principe de la step ID m'a l'air d'être la bonne solution mais elle comporte une faille dans la mesure où elle est directement accessible par l'utilisateur Je m'explique (aussi clairement que possible : dans un système de base de donnée l'ID est généralement une référence unique et invisible du côté utilisateur qui permet au système de gérer les situations les plus complexes à sa sauce tout en restant transparent d'un point de vue ergonomique. Ayant eu pas mal affaire à des bases de données voilà comment, personnellement, j'approcherai la chose :
1/ je garderai le pas de séquentiel comme seule référence du côté utilisateur
2/ le système assignerai son ID personnelle et unique (à lui de gérer ça au mieux et de les réorganiser si ça l'arrange) à chaque création de pas.
3/ du côté midi, l'utilisateur assignerai le n° de pas qu'il désire à un prg change non spécifié (par défaut le 1er prg change disponible / non utilisé par le canal midi spécifié) qui serait stocké par le système en step ID.
4/ la fenêtre d'assignation midi, quant à elle, se mettrai à jour (en arrière plan) grâce à la correspondance step ID > n° de pas de manière à rester à jour avec le contexte de l'utilisateur.
Exemple (à partir d'une base de donnée vierge soit 1 pas de séquence 0) :
1/ l'utilisateur crée 2 nouveaux pas de séquence et les assigne en LoadStep_X2 (le système choisi par défaut le 1er prg change disponible et peut éventuellement afficher cette valeur à titre indicatif pour paramétrer la source extérieure qui envoie la commande de prg change)
seq => prg change => ID (invisible pour l'utilisateur)
0 => pourquoi ne pas créer un type d'assignation exceptionnelle du prg change 1 au pas 0 (ID 0) pour revenir au début => 0
1 => 1 => 1
2 => 2 => 2
La fenêtre midi affiche :
LoadStep_X2_1 => ProgChge 1
LoadStep_X2_2 => ProgChge 2
2/ l'utilisateur insère un pas entre le pas 1 et 2 :
seq => prg change => ID
0 => 1
1 => 1 => 1
2 => X => 3
3 => 2 => 2
La fenêtre midi affiche maintenant :
LoadStep_X2_1 => ProgChge 1
LoadStep_X2_3 => ProgChge 2
3/ l'utilisateur assigne le pas 2 en LoadStep_X2 (soit automatiquement le prg change 3 = 1er prg change disponible)
seq => prg change => ID
0 => 1
1 => 1 => 1
2 => 3 => 3
3 => 2 => 2
La fenêtre midi affiche :
LoadStep_X2_1 => ProgChge 1
LoadStep_X2_2 => ProgChge 3
LoadStep_X2_3 => ProgChge 2
4/ l'utilisateur efface le pas n°3 :
seq => prg change => ID
0 => 1
1 => 1 => 1
2 => 3 => 3
La fenêtre midi affiche :
LoadStep_X2_1 => ProgChge 1
LoadStep_X2_2 => ProgChge 3
5/ l'utilisateur insère un pas entre 1 et 2, le sytème crée une nouvelle (max) ID
seq => prg change => ID
0 => 1
1 => 1 => 1
2 => X => 4
3 => 3 => 3
La fenêtre midi affiche :
LoadStep_X2_1 => ProgChge 1
LoadStep_X2_3 => ProgChge 3
6/ l'utilisateur assigne le pas 2 en LoadStep_X2 (soit automatiquement le prg change 2 = le premier prg change disponible)
seq => prg change => ID
0 => 1
1 => 1 => 1
2 => 2 => 4
3 => 3 => 3
La fenêtre midi affiche :
LoadStep_X2_1 => ProgChge 1
LoadStep_X2_2 => ProgChge 2
LoadStep_X2_3 => ProgChge 3
7/ cas où l'utilisateur RE-assigne le pas 2 en LoadStep_X2
comme pour le patch, le système demande s'il faut vraiment écraser cette assignation qui existe déjà

On voit finalement qu'on se retrouve avec la même logique que le patch circuits / dimmers. On est par contre limité par le nb de prg change disponibles : 127 x 16 => 2032 pas. Á 1 pas +/- toute les 10 secondes ça fait déjà presque 6 heures de spectacle !!!

6h de spectacle... yeah!!

Sinon, le principe de la step ID m'a l'air d'être la bonne solution mais elle comporte une faille dans la mesure où elle est directement accessible par l'utilisateur

le principe de l'ID réponds surtout à un problème de répétition des cues dans la séquence.
L'ID étant le moyen de définir spécifiquement les pas de séquences contenant la cue répétée pour pouvoir se caler dessus

par extension, c'est effectivement possible d'envisager d'utiliser l'ID comme tu souhaite le faire avec les PrgChange, mais pas comme tu le décris car il faut penser aussi à ceux qui veulent connaitre les ID pour pouvoir se recaler...
et là, il ne faut pas que ce soit obscur.

++

Je comprend effectivement le besoin de l'ID tel que tu le décris. Dans ce cas, rien n'empêche à ce que cet ID ne soit accessible qu'en lecture. Pour moi le soucis est surtout la non concordance entre le n° de prg change envoyé à dlight et ce qu'il reçoit, il arrive qu'on s'y perde.
En tout cas, j'ai passé toutes mes assignations LoadStep_X2 en LoadStepID_X2 et cela semble bien simplifier la tâche pour de futurs inserts ou suppressions.
++

J'ai néanmoins atteint les limites de l'assignation prg change à une step ID quand je suis arrivé à 127

eh ouais....

++