Sélectionnez votre langue

Résolution de problème : merci de consulter la FAQ et le Wiki

Aidez-nous à améliorer le contenu du Wiki et de la FAQ en les consultant. Le Wiki est mis à jour régulièrement et la FAQ permet une résolution rapide des principales embûches rencontrées. N'hésitez pas à nous faire parvenir vos suggestions d'amélioration sur le forum ou à éditer directement le Wiki ou la FAQ .

Urgence Avignon : Gros Problème OSC entre Qlab et Dlight

Plus d'informations
il y a 10 mois 4 jours #28774 par El Gringo
Bonjour à tous,

Je rencontre une énorme tuile sur la prépa d’un de mes shows sur le festival d’Avignon. Je bosse comme pas mal d’entre-nous avec Qlab en master et Dlight en slave. Mes envois lumières passent donc par des cues Network sur Qlab (ex : /seq/X2LoadAndFireID f 51) pour que Dlight envoi la ID correspondante. Ça fonctionne, Dlight va bien sur la bonne ID, mais le cue associée est méconnaissable (je peux me retrouver carrément dans le noir)
Si je retourne sur Dlight, que je recule et renvoie le GO, aucun problème, je récupère le bon cue.
HELP !!! 
si quelqu’un sait ce qu’il se passe et connaît une solution à mon problème, il faut que je résolve ça avant le 3 juillet (date du 1er filage en condition). 
pour info, je suis en Qlab 5.4.10 et Dlight 4.5.21.4

merci d’avance 🙏🏻

Connexion pour participer à la conversation.

Plus d'informations
il y a 10 mois 4 jours #28775 par aroom
hey

c'est pas juste une histoire de tracking de device ?

si tu envois une ID sans avoir chargé le step où t'as chargé tes D-Link, tu peux avoir des surprises


sinon sur QLab (et dans DL aussi maintenant) t'as pas besoin de mettre le f dans le message OSC

Connexion pour participer à la conversation.

Plus d'informations
il y a 10 mois 4 jours #28776 par El Gringo
Je ne comprends pas ce que tu entends par charger un step avant d’envoyer la demande d’ID.
Il semble que ça soit effectivement plus un problème avec les devices plutôt qu’avec le trad (mais sans certitude).
J’arrive sur les bonnes ID mais les devices des cues associées perdent parfois toutes les couleurs ou leur dimmer tombe à zéro. Je retourne sur Dlight, recule puis avance et je récupère mon cue.
Merci pour l’histoire du F, les copains autour venait de me dire qu’il n’a plus d’utilité, en effet.

Connexion pour participer à la conversation.

Plus d'informations
il y a 10 mois 4 jours #28777 par sl1200mk2
Hello,
là je suis en tournée mais je pourrais regarder d’ici Lundi…
pendant ce temps, est ce que le pb arrive sur tous les devices ou seulement ceux qui n’ont pas d’offset d’intensité dans leur perso? 
le cas échéant as-tu bien coché le virtualDimmer4Colour dans le deviceListing?

++

nicolas

Connexion pour participer à la conversation.

Plus d'informations
il y a 10 mois 4 jours #28778 par El Gringo
Si on parle bien de ce qui s’appelle désormais « intensity controller virtualization », alors ce n’est pas ça.
Je me suis fais avoir il y a longtemps par cette histoire de ces précieux dimmer virtuels (cachés à droite) pour palier aux manques de dimmer de certaines bécanes, mais ce n’est pas le cas ici. Elles ont toutes un dimmer.
Sinon je ne sais pas ce qu’est le « virtualDimmer4Colour »
Merci pour ta réactivité 🙏🏻

Connexion pour participer à la conversation.

Plus d'informations
il y a 10 mois 4 jours #28779 par sl1200mk2
C’est bien de ça dont je parlais… mais à priori c’est pas ton pb…
peux-tu poster ton sho et dire quel step/ID regarder

++

nicolas

Connexion pour participer à la conversation.

Plus d'informations
il y a 10 mois 4 jours - il y a 10 mois 4 jours #28780 par aroom
DL calcule et charge en X1 les paramètres de devices linkés en X2. pas à vue bien entendu. c'est le MIB, ou movement in black


si t'as :

step1 chan5 pas de D-Link
step2 chan5 D-Link en rose
step3 chan 5 pas de D-Link

quand tu fait des GO ou des flèches haut bas dans DL tu as au plateau :

step1 chan5 pas de couleur
step2 chan5 en rose
step3 chan5 en rose

car c'est du tracking. la valeur du step2 est gardée en step3

si tu pilotes DL via QLab et que tu charges avec loadandfireX2 le step1, et ensuite le step3 dans passer par le step2, ton chan5 ne sera pas en rose, car tu n'as pas chargé le step avec le D-Link correspondant à la couleur du chan5

donc à toi de voir si dans la conduite QLab, tu loadandfire tes ID à la suite, ou si tu sautes de step en step, en ne passant pas par le step qui a le D-Link qui t'intéresses.
Dernière édition: il y a 10 mois 4 jours par aroom.

Connexion pour participer à la conversation.

Plus d'informations
il y a 10 mois 4 jours #28781 par El Gringo
Je supprimé tous les F de mes Lignes de codes Network, et j’ai comme l’impression que c’était ça qui fouttait se m****.
Je ne veux pas crier victoire trop vite car je bosse à l’aveugle à cette heure, mais je n’ai plus l’impression que mes cues se chargent de façon anarchique. Je teste ça samedi en réel

Connexion pour participer à la conversation.

Plus d'informations
il y a 10 mois 4 jours #28782 par aroom
tu peux utiliser Protokol en art-net pour vérifier hexler.net/protokol

Connexion pour participer à la conversation.

Plus d'informations
il y a 10 mois 4 jours #28783 par sl1200mk2
Les F n’ont jamais été utiles dans le sens Qlab DL, ils servaient juste dans le sens DL Qlab pour dire que à DL quel type d’argument envoyer (soit des nombres entiers @i, soit des nombres à virgule @f, soit des phrases @s)
mais je me suis rendu compte que personne ne comprenait le sens du @… donc j’ai bossé pour les virer.

nicolas

Connexion pour participer à la conversation.

Plus d'informations
il y a 10 mois 1 jour #28791 par El Gringo
Un grand merci à tous pour le coup de main hyper rapide. Confirmation : c’était bien le F dans la ligne de code qui foutait sa m****. J’ai testé ce matin après les avoir tous enlevé au préalable, et plus un bug. 
merci 🙏🏻 

Connexion pour participer à la conversation.

Temps de génération de la page : 0.358 secondes
Propulsé par Kunena