4.0.0_b39

mainly bug fixes.
we're getting closer to the 4.0.0 release....

touchOSC layouts are here:
dlight-tools.github.io/dlight-pad/

Device's personality are here:
dlight-tools.github.io/dlight-devices/

enjoy and please report any wrong behavior.
++

Il y a peut-être un petit problème de décrochage de l'interface USB-DMX PRO d'Enttec au bout d'un long temps d'utilisation. Ce n'est pas un problème spécifique à cette version (b39) mais aussi les anciennes betas.
Pour une exposition Dlight recevait des infos OSC de puredata, l'ordinateur restait allumé et continuait son travail quand les gradateurs étaient éteints. Au bout de deux jours les lumières se figeaient. En relançant la connexion de l'interface usb ça repart pour deux-trois jours et ainsi de suite.
Le tout sur mac OSX 10.10.3 Quartz 2.7.7. Toutes mises en veille désactivées....
Je ne sais pas comment faire pour trouver un journal de plantage qui permettrait de savoir pourquoi.
Bonne journée.
Jef

Salut nico !

Pignolage de bas étage :
Dans le Device Listing, j'ai un device de chargé, il apparaît en surbrillance, mais si je fais un clone, il me charge unknow_unknow. Il faut resélectionner le device pour pouvoir le cloner.

Maintenant que cette fenêtre ne gère plus le patch, dans le menu clone, à quoi sert Dimmer Start et Gap ??

le pignolage, c'est important...

Dans le Device Listing, j'ai un device de chargé, il apparaît en surbrillance, mais si je fais un clone, il me charge unknow_unknow. Il faut resélectionner le device pour pouvoir le cloner.

en fait le sytsème d'identification de la sélection est pas bullet proof.
si tu sélectionne un device dans le device listing, que tu changes de fenetre (nouvelle fentre qui fait un grab de sélection), que tu reviens au device listing, il se peut que ton device apparaisse toujours sélectionné mais en fait il ne l'est plus.

ça va etre dur à corriger ça....

Maintenant que cette fenêtre ne gère plus le patch, dans le menu clone, à quoi sert Dimmer Start et Gap ??

à patcher à la volée dans le cas d'un clone...
ça peut-être pratique si tu connais les adresses des machines et qu'elles se suivent et surtout, ça évite d'avoir à se taper tout le boulot dans la fenetre de patch.

++

@Jefff,
l'OS doit délivrer un ordre de mise en veille de la connection USB.
je vois pas pourquoi sinon la connection se couperait...

++

sl1200mk2 écrit: le pignolage, c'est important...

héhé c'est ce qui rend l'appli hyper sympa à utiliser

en fait le sytsème d'identification de la sélection est pas bullet proof.
si tu sélectionne un device dans le device listing, que tu changes de fenetre (nouvelle fentre qui fait un grab de sélection), que tu reviens au device listing, il se peut que ton device apparaisse toujours sélectionné mais en fait il ne l'est plus.

ça va etre dur à corriger ça....

J'imagine. Surtout que avec les différents système ça doit se gérer différement ...

à patcher à la volée dans le cas d'un clone...
ça peut-être pratique si tu connais les adresses des machines et qu'elles se suivent et surtout, ça évite d'avoir à se taper tout le boulot dans la fenetre de patch.

J'avais bien compris cela quand le patch se faisait encore dans la fenêtre de Device oui. Mais là, mon premier essai n'a rien patché du tout, et mon second m'a fait un Segmentation fault
Il faut que je regarde ce soir pour le reproduire et t'en dire un peu plus...

bonne journée.

@antoine,
ah oui, les segmentation fault, je veux bien qu'on les traque...
fait gaffe à un truc c'est de bien valider par enter chaque box. c'est peut-etre ça qui a conduit au segmentation fault, mais auquel cas, il faut le trouver.

++

Hello,

donc voilà, j'ai réussi à reproduire mon segmentation fault. Il est dû à une erreur de compréhension du fonctionnement du clone.
La procédure à suivre :

Nouveau > Device Listing > Charger un device (j'ai pris un device tout bête DIMMER + RVB)
Je l'affecte au Channel 1.
Patch > Channel 1 @ Dimmer 1

Device Listing > Clone :
Number of Device 1
Channel Start 1
Dimmer Start 1
Gap 5

Voilà, je viens de comprendre que le système de clone part à partir du deuxième élément (on ne compte pas celui que l'on clone) et là, ca marche bien ! mais avec ma manip avant que normalement on ne devrait pas faire, Segmentation fault chez moi.

C'est le Channel Start qui fait le segmentation fault. Si je mets le même que celui sur lequel je prend modèle.
Si le dimmer start est le même que celui du modèle, alors il dépatch le modèle et tout se passe bien....

Concerant la validation des box, j'ai fait des essais, c'est la case du dimmer qui demande une validation par entrée. Si je ne le fait pas, alors il ne patche pas les devices, mais il clone bien. Toutes les autres cases se valide juste par la tabulation.

@Antoine,
bien joué, thanx.
ça sera fixed pour la b40

++

Désolé d'en trouver encore....

En voulant comprendre le fonctionnenement du Cue_goto quand on a plusieurs fois la même cue dans la séquence, ( pour le WIKI ), par erreur, en faisant un Cue_goto pendant un transfert ==> Segmentation fault.

@antoine,
t'es sur que c'était pendant un cue_goto? et pas un goto_ID ou quoi?

++

Coucou,


Oui c'était bien sur un cue_goto, mais ce n'est pas systématique, cela arrive quand la step suivante le cue_goto contient un timegroup.
Je te joins la conduite sur laquelle j'ai trouvé ce bug, mais pas compris ce qui pouvait le provoquer. Si tu lances un transfert et que tu fais un Cue_goto sur les CUE 5 / 6 / 12 / 16 , segmentation fault.
Donc, si tu prends cette conduite, tu verras que pour ces 4 CUES, la STEP suivante contient un Timegroup. Et comme un cue_goto continue le transfert sur la cue suivante, je pense que c'est le timegroup qui est la cause.

@antoine,
bien vu!!
fixed pour la prochaine beta

++

b40 is online
@antoine,
merci de tester les corrections des segmentation fault.

++