3.0.8_b1

@Colin
ok i'll try to prepend [CH] according to case we've discuss

@Pipou

à propos de ma remarque sur la flèche qui commande la boite RPN/@mode,

ok, merci d'avoir remarqué ça, je vais le corriger

Autre point, et pas des moindre : le Xfade ne fonctionne que dans un sens! la valeur du x2 n'est pas inversée, du coup les 2 sont à FF et la mémoire ne passe pas.

tu parles de commandes OSC non?
si tel est le cas, il va falloir que t'adaptes tes patchs pour qu'ils correspondent au fonctionnement du xfade normalisé pour la 3.0.8 (et la 3.0.7 aussi il me semble)
essaye d'envoyer les paires suivantes pour trouver la bonne:
X1/255->0, X2/0->255
X1/0->255, X2/255->0
X1/0->255, X2/0->255
*après quelques tests, ce qui fonctionne avec pureData en osc c'est:
X1/0->225, X2/0->255, puis X1/255->0, X2/255->0

Ensuite j'ai tourné et retourné mon patch dans tous les sens, rien à faire, je n'arrive pas à envoyer le go ni le goback. Je pense que c'est du au module vvvv "OSCencoder" qui envoie l'argument 1 dans une forme que dlight ne comprend pas...

il envoie des integer ou des floats? dis moi et j'adapterais DL en conséquence (dans la 3.0.8_b2, DL demande des nombres entiers comme argument)
si t'as un peu de temps, je reposte le patch pd avec les commandes osc, cliques sur connect tout en haut à gauche, et dans cette zone tu trouveras les commandes de go goback, pause

++
nico

hola!

Alors c'est vrai que j'ai pas été clair, j'ai écrit un peu vite :
pour le xfade, c'est en midi que le problème existe, en OSC effectivement j'ai fait comme tu dis.
Quand à mes patch, je n'avais pas précisé non plus, c'est VVVV que j'utilise, je n'ai pas pure data (et je n'y comprend pas grand chose...) Je ne maîtrise pas vraiment ce soft, mais il me semble que la "node" OSCconverter envoie des nombres flottants. Je n'ai jamais changé le type de données envoyées... il ne me semble pas, à moins que ce soit à cause de la version de vvvv que j'utilise (un beta plus récente), mais les nodes sont les mêmes...et certaines fonctions fonctionnent parfaitement. A l'inverse, j'arrive très bien à récupérer les messages osc de dlight. Il est vrai que je n'ai jamais essayé de récupérer le go, je vais regarder de mon côté , mais je doute pouvoir aller bien plus loin, mes connaissances sont très limitées sur ce soft, et j'ai déjà retourné la question dans tous les sens, je ne peux pas influer sur la forme finale du message délivré par la node osc.
En espérant que ces précision t'ont aidé..
A+
pipou

@pipou,
je vais autoriser les floats pour les messages /seq/go, goback et pause
pour le midi, c'est du controle hardware ou software que tu fais? si c'est du soft, c'est pareil, il faut adapter tes patchs

@Colin
prepending [CH] for the case we've defined works great!
i've added this functions in case post-command is [+] or [-] or [THRU] or [@] or [@ FF] ( the last one is reached with double-clic on @).
do you see other scenario where it should happen?

++
Nico

Salut Nico,

Effectivement, je pense que c'est ce qu'il faut, je n'envoie que des valeurs allant de 0 à 1. J'ai hâte de retrouver l'accès au go par OSC, j'ai plein d'idées en ce moment...

Pour ce qui est du midi, c'était effectivement en software, j'ai testé cet aprèm' avec mon nanokontrol, pas de problème, le xfade est dans le bon sens.
Je remonte un truc aussi, je sais qu'à l'époque tu ne savais pas comment faire, ça a peut-être évolué : le moyen d'associer les fichiers .sho à Dlight sous windows pour que le show s'ouvre en double-cliquant dessus...
Sinon jusqu'à présent, version très stable, aucun bug repéré.
A+
pipou

@pipou
et bien t'as plus qu'à modifier tes patchs...
je suis désolé d'avoir niqué ton boulot, mais je pense que c'était nécessaire de clarifier le xfade... sinon on se le serait trainé pendant longtemps et au bout du compte, ça nous aurait fait chier.

Je remonte un truc aussi, je sais qu'à l'époque tu ne savais pas comment faire, ça a peut-être évolué : le moyen d'associer les fichiers .sho à Dlight sous windows pour que le show s'ouvre en double-cliquant dessus...
Sinon jusqu'à présent, version très stable, aucun bug repéré.

Nan, toujours pas. J'ai lu que ça avait avoir avec les Windows Registry, mais je ne sais pas comment y accéder.
et je suis d'accord avec toi, ça serait super!!!

petites question subsidiaire:
ci-joint un sho, peux-tu l'ouvrir, faire un saveAs et me dire combien de temps DL mets pour sauvegarder le nouveau sho

++

Ya pas de soucis pour mes patchs, c'est vraiment simple à faire avec vvvv...
Sinon pour ta conduite, j'ai eu le temps de compter jusqu'à 4 pour qu'elle s'ouvre, et idem pour le saveas.
a+
pipou

@pipou

Sinon pour ta conduite, j'ai eu le temps de compter jusqu'à 4 pour qu'elle s'ouvre, et idem pour le saveas.

j'ai un pote qui compte 4 minutes chrono en main pour le saveAs...
du coup c'est son ordi qui doit bien foirer...

thanx

@Nico et pipou !
Je suis depuis quelque temps l'évolution de la bêta 3.08.1 sans trop participer car je suis trop habituer au langage rpn, donc le @mode ...!
Je me suis permis d' essayer d' ouvrir le fichier .sho et effectivement, il s' est ouvert rapidement par ontre au moment de " save as " petit instant de 'dl ne répond pas ' puis confirmation d' enregistrement...
Avez vous un conseil pour utiliser autre logiciel que pure data, ainsi que Seqcon qui ne fonctionne guère sur mon ordi. ? Merci d' avance !
Thierry

Windows Vista, H.Pr., ...

@pieri,
l'@Mode, ça va déchirer!!

Je me suis permis d' essayer d' ouvrir le fichier .sho et effectivement, il s' est ouvert rapidement par ontre au moment de " save as " petit instant de 'dl ne répond pas ' puis confirmation d' enregistrement...

une estimation de temps pour le saveAs?

++

J'ai jamais réussi à faire tourner seqcon... c con oui oui bon ça c'est fait...
pour ce qui est des soft à part pure data, perso j'utilise vvvv, il y a max aussi (mais qui est payant il me semble...).
Pour lancer du son, ableton live va très bien...mais il est payant et très cher. Quoique tu peux avoir une version lite si tu achètes un nanokontrol par exemple... qui lui ne coute que 50€ max

Amis du soir bonsoir!
Aujourd'hui, j'avais du temps et mes deux ordis à dispo, et surtout très envie de mettre au point un système me permettant de contrôler 2 dlight synchronisés, pour avoir toujours sous la main un ordi de secours prêt à brancher. Je suis l'heureux propriétaire depuis peu d'une 2eme ENTTEC PRO, ce qui me permettra de réagir en cas de panne (on est jamais à l'abri!)
A la base mon idée était de commander les deux conduites en même temps via un contrôleur midi software (vvvv) en passant par l'OSC de Dlight.
Puis le temps a passé et sur cette beta je n'arrive plus à accéder au go via OSC, je me suis dit : le soft qui est le plus adéquat pour contrôler dlight... c'est dlight! Du coup, aussitôt dit, aussitôt fait, rien de plus simple : transférer les messages OSC de Dlight"1" tel quel via vvvv sur mon réseau, et laisser l'OSC reader en marche sur le dlight"2".
A première vue, ça marche du tonnerre, et quelle a été ma joie pendant la générale d'entendre les tops sons se déclencher de concert sur les 2 ordis! (j'utilise aussi dlight pour contrôler Ableton live)...
Puis les bugs ont montré le bout de leur nez : sauts, doublement de mémoires, séquence incohérente (retour à la mémoire 0?) sur le dlight2 (le dlight1 n'a eu absolument aucun problème, il ne faisait qu'émettre)
J'ai cru avoir identifié et réglé le problème : dlight1 traduit en OSC toutes les opérations qu'il execute, et dlight2 les execute suivant l'OSC, mais aussi execute sa propre conduite (à savoir que j'avais chagré exactement la même conduite dans les 2 dlights), donc doublait certaines commandes. J'ai donc coché le "inhib Mlink " et "inhib wait" dans le setup de dlight2. Nette amélioration, mais dlight2 saute encore parfois des mémoires, d'autant plus lorsqu'on enchaine des mémoires avant que la précédente ne soit terminée.
Je ne suis pas allé plus loin dans mes recherches pour l'instant, mais je pense qu'on tient là la meilleure façon de tester la cohérence des informations envoyées par dlight, et sa façon de les interprêter. Peut-être un moyen "d'épurer" les messages...
En attendant, je pense filtrer uniquement les go osc et les renvoyer en midi, évitant ainsi les conflits...à tester.

Bonne expérience en tout cas, j'ai hâte de voir comment tout ça va évoluer... vivement la prochaine beta!!
A+
pipou

@pipou
c'est malin ça, j'avais jamais essayé de brancher 2 DL ensemble relié par l'OSC...

Du coup, aussitôt dit, aussitôt fait, rien de plus simple : transférer les messages OSC de Dlight"1" tel quel via vvvv sur mon réseau, et laisser l'OSC reader en marche sur le dlight"2".

pourrais-tu refaire l'essai sans passer par VVVV?

Puis les bugs ont montré le bout de leur nez : sauts, doublement de mémoires, séquence incohérente (retour à la mémoire 0?) sur le dlight2 (le dlight1 n'a eu absolument aucun problème, il ne faisait qu'émettre)

il existe un soft qui s'appelle osculator qui te permet de faire du monitoring de messages OSC.
comme ça tu pourras voir pourquoi le DL2 à des bugs - est-ce en fonction des messages émis...?

J'ai cru avoir identifié et réglé le problème : dlight1 traduit en OSC toutes les opérations qu'il execute, et dlight2 les execute suivant l'OSC, mais aussi execute sa propre conduite (à savoir que j'avais chagré exactement la même conduite dans les 2 dlights), donc doublait certaines commandes. J'ai donc coché le "inhib Mlink " et "inhib wait" dans le setup de dlight2.

pourrais tu clarifier un peu pourquoi les MLInks et les Wait émis sur le réseau pouvait foutre la zone?

Nette amélioration, mais dlight2 saute encore parfois des mémoires, d'autant plus lorsqu'on enchaine des mémoires avant que la précédente ne soit terminée.

ces sautes de mémoire, elle sont logiques ou pas?

Je ne suis pas allé plus loin dans mes recherches pour l'instant, mais je pense qu'on tient là la meilleure façon de tester la cohérence des informations envoyées par dlight, et sa façon de les interprêter.

I think you're right!!!

merci pour tes tests,
++

Hello!

Essai ce matin sans passer par vvvv, en règlant Dlight1 pour que le writer OSC écrive directement sur le réseau.
Mêmes résultats, la connexion est instantanée mais dlight2 passe des mémoires non désirées, voire retourne carrément en 0 (le x2 continuant cependant d'afficher la bonne méméoire). Cela arrive souvent lorsque la tempo de la mémoire en question est de 0, ou que la suivante a un wait de 0.1. L'affichage sur dl2 est étrange : le x2 (preset) s'affiche toujours correctement, en fonction de ce qu'envoie dl1. Par contre l'affichage du x1 (scene) ne semble correspondre qu'à ce que fait dl2, et n'est pas toujours le même que dl1 (je parle de l'affichage de la séquence).
C'est assez compliqué à expliquer, mais par exemple, on peut voir affiché dans dl2 le même n° de step en scène et preset.
Si par exemple dl2 ne charge pas la bonne mémoire, les valeurs des circuits affichés vont se réctifier pour s'aligner avec dl1 via la commande osc liée aux channels, pas à la séquence.
En gros : je pense que le problème vient bien de la façon dont dlight envoie ses informations sur la séquence : x1, x2, go, step+/-...
Le problème est systematique quand on "double" un go, c'est à dire quand on enchaine une mémoire avant que la précédente ne soit terminée : dl2 se décale complétement(dumoins sur l'affichage des séquences et des tempos).Encore une fois, c'est vraiment compliqué de décrire ce qui se passe, je te suggère de faire l'essai, tu comprendras vite.
Mais les sauts de mémoires semblent très logiques et liés aux infos que génère dl1 en OSC et celles que génère dl2 en interne, qui se "superposent".
Pas d'accès à osculator, dispo sur mac only pour lez moment.
A+ et bonne journée!
Pipou

etoui, t'as raison!!!
DL1 non content d'envoyer ses infos de séquences, envoi aussi tous les niveaux de circuits en permanence.
et là, c'est le drame!!!

ce que je vais essayer de faire, c'est un OSCManager où tu pourrais choisir quelles infos sont émises par le Writer.

bref, c'est pas pour de suite que DL1 va pouvoir piloter DL2... mais ça devrait le faire
++

@Colin
while working on @Mode for editors, i'm wondering if existing syntax are good?
for example, does [CUE] XX [LOAD] shouldn't be [LOAD] [CUE] x.xx ?
another example:
does [GROUP] XX [REC] shouldn't be [REC] [GROUP] x.xx
or [STEP] XX [INSERT] -> [INSERT] [STEP] XX

any thoughts?
++
nico