Contrôle des submasters via OSC

Salut Nico,

me voila de retour pour un peu d'OSC (encore!), évidemment une demande

Je ne crois pas qu'il y ait de commande osc pour contrôler les modes des subs, que ce soit ^pour le mode flash/solo ou pour le mode flash/time
Je propose les 3 adresses suivantes :

Pour le sub n°1 :

/sub/1/flash/mode normal/solo = flash normal ou flash solo
/sub/1/mode flash/time = choisir le mode flash ou le mode time pour le sub
/sub/1 flash pourra déclencher le flash ou le time suivant le mode choisi = appui sur le bouton flash

Dis-moi ce que tu en penses.

renaud

il me semble qu'il existe déjà une méthode OSC pour ce qui est de la commande des subs
/sub/flash [x]
avec [x] comme numéro de sub. à vérifier....

on peut tout à fait rajouter des commandes de manipulation de type pour les subs, à savoir:
/sub/mode/solo [x] avec [x] comme numéro de sub //passe le sub en solo
/sub/mode/normal [x] avec [x] comme numéro de sub //passe le sub en mode pas solo

/sub/mode/flash [x] avec [x] comme numéro de sub //passe le sub en mode flash
/sub/mode/time [x] avec [x] comme numéro de sub //passe le sub en mode timé

a-ton-avis ?
++

Je viens d'essayer et effectivement l'adresse dont tu parles existe (/sub/flash [x]).
En mode flash, cela fonctionne bien, mais en revanche en mode time, le premier message fait monter le sub dans le temps voulu, mais il faut que je renvoie deux fois le message pour que le sub redescende.

D'une manière plus générale, les namespace OSC sont construits avec des noeuds et des feuilles, et en général on va regrouper les messages possibles de manière hierarchique au fur et à mesure des noeuds. Cela permet alors une découverte et un parsing via les slashs.

Du coup, je préfererais

/sub/1 0-255 (valeur de 0 à 255 du sub //commande déjà existante)
/sub/1/mode 0/1 ou flash/time (place le sub en mode flash ou time)
/sub/1/flash 0/1 (équivaut à appuyer sur le bouton flash ou le relacher)
/sub/1/flash/mode 0/1 ou normal/solo (place le sub en mode flash ou solo)

Je serais plus partant pour des adresses de ce type, mais peux-être cela complique-t-il la programmation pour toi?

Je peux te donner une petite appli OSC pour tester si besoin, dis-moi.

/sub/1 0-255 (valeur de 0 à 255 du sub //commande déjà existante)
/sub/1/mode 0/1 ou flash/time (place le sub en mode flash ou time)
/sub/1/flash 0/1 (équivaut à appuyer sur le bouton flash ou le relacher)
/sub/1/flash/mode 0/1 ou normal/solo (place le sub en mode flash ou solo)

ok, je préfère parser des chiffres que des string donc 0/1 pour les switch

Je peux te donner une petite appli OSC pour tester si besoin, dis-moi.

yep, je veux bien

++

Voila l'appli.


J'ai mis des boutons textes, mais c'est bien des 0/1 qu'ils envoient. J'ai mis ca en localhost, j'imagine que c'est comme ca que tu testes?

Je viens de m'apercevoir que les circuits ne fonctionne plus avec la version 3, alors que cela fonctionnait avec la 2.5.1 Peux-être est-ce du aux univers DMX? J'ai mis la fonction circuit en test aussi dans le patch

voili !!

La pièce jointe semble ne pas passer, alors voila le lien pour télécharger l'appli

didascalie.net/video/Dlight/tools/dlight-sub-osc.app.zip

alors, pour la prochaine version j'ai rajouté le contrôle des subs par OSC,
les messages sont les suivants:
/sub/[x]/level 0-255 //affecte le niveau du sub [x] à la valeur envoyée
/sub/[x]/flash 0-255 //flashe le niveau du sub [x] à la valeur envoyée - dans le cas d'un sub timed, la valeur n'est pas prise en compte
/sub/[x]/type 0-255 //modifie le type du sub [x], 0==normal, default==solo
/sub/[x]/mode 0-255 //modifie le mode du sub [x], 0==flash, default==timed

j'ai essayé avec PD, ça fonctionne bien, Renaud, l'appli renvoie ce message:
jcom.loader: unable to load object bundle executable

dis moi si ça fonctionne pour toi quand l'update de DL sera publique.
++
nico

Ok, j'étais offline un petit moment… Je viens de tester et ……………c'est parfait!!!

merci encore Nico.

à bientôt,

Ah… en fait il y a un petit problème

Tu as changé l'adresse de contrôle de l'intensité des submasters qui était
/sub/1 0-255
pour
/sub/1/level 0-255

Cette modification fait sens car l'adresse est plus claire, en revanche le renvoi d'info est toujours /sub/1

Pourrais-tu changer l'adresse dans le renvoi d'info de dlight sur le réseau?

tx

Bonjour Nico & Renaud,

Je me permets de me glisser dans vos échanges sur l'OSC.
Je me suis aussi permis d'écrire dans le très utile tableau OSC google.doc établi par Renaud pour l'actualiser, le compléter, effectuer quelques corrections et ajouter des précisions notamment concernant les retours d'infos.
Je travaille sur Pure data et je prépare un tableau de commande qui permettra de piloter entièrement DLight depuis Pd, permettant des synchros lumière-son-capteurs et autres. C'est déjà en partie opérationnel mais il manque encore certaines commandes. Dès qu'il sera prêt,je pourrai le mettre à disposition...
La synchro fonctionne déjà bien pour une conduite "traditionnelle" et permet de reprendre la main sur DLight quand on veut (les infos circulent dans les deux sens) ou de switcher de DL à Pd.

Sans vouloir passer pour celui qui demande plus (je trouve que le boulot de Nico est vraiment super), j'aimerais suggérer qq points:
- commande et retour d'info du crossfader (voir mon commentaire dans le tableau);
- simplification de l'écriture des adresses /sub (c'est important lorsqu'on veut déclencher via OSC de nombreuses micro-séquences simultanées construites sur master);
- plus quelques décalages dans les retours d'infos concernant les pas (voir également ds le tableau).

Après, si tu le souhaites, Nico, j'aurais quelques suggestions complémentaires à faire, pour sophistiquer, mais on pourra en reparler.

En tous cas, encore bravo.

Olivier

c'est marrant que tu parles de ça car je sors d'une installation à Londres (à la Pilar Corrias gallery) où j'ai fait exactement ce que tu décris, PD qui gère les signaux de capteurs en MIDI et talk to DL en OSC.
c'était assez compliqué, mais ça fonctionne bien

- commande et retour d'info du crossfader (voir mon commentaire dans le tableau);

ok, je regarde ça

- simplification de l'écriture des adresses /sub (c'est important lorsqu'on veut déclencher via OSC de nombreuses micro-séquences simultanées construites sur master);

tu peux déjà ressayer avec la 3.0.2 qui intègre les nouveaux messages de sub:
/sub/[x]/level ou flash ou mode ou je sais plus, regarde les posts avec Renaud.

- plus quelques décalages dans les retours d'infos concernant les pas (voir également ds le tableau).

Je pense effectivement que les messages du séquentiel sont à améliorer (j'ai d'ailleurs du trafiquer un peu tout ça pour l'install) avec notamment des messages du type
/seq/stepmoins /seq/stepplus pour rester dans la logique du controle de la séquence (un seul message après le /seq)

Après, si tu le souhaites, Nico, j'aurais quelques suggestions complémentaires à faire, pour sophistiquer, mais on pourra en reparler.

as you wish

++

Oui, je trouve aussi que le dialogue DL/Pd en OSC fonctionne très bien et l'ensemble est très stable. Surtout, via l'OSC on peut, sans aucune plantade, faire faire à DL des choses que son interface seule ne permet pas de faire (les ressorts cachés de DL!) et surtout qu'un avab ne supporte pas sans bug instantané.

Concernant les masters, j'ai bien testé la 3.0.2 et la nouvelle syntaxe.
Regarde, à ce propos, mes commentaires ajoutés au google.doc de Renaud:
spreadsheets.google.com/ccc?key=0AhgzuAN...Th0MzVmeTB4ZXc&hl=fr
Je suggère notamment une simplification des adresses que je trouve un peu compliquées. Tu me diras ce que tu en penses...
Ce que je trouve compliqué, c'est par exemple de devoir écrire /sub/#/flash tout en s'assurant du mode TIME pour avoir du timed. L'idée serait de réduire le nombre d'adresses et surtout de les rendre plus transparentes pour éviter de se planter lorsqu'on développe un programme dont l'architecture est complexe. Genre : pour avoir du TIME tu écris /time et pour avoir du FLASH tu écris /flash. Genre aussi : devoir rentrer une valeur 0-255 (en TIME) qui n'a aucun effet puisqu'il suffit qu'elle soit supérieure à 0 (ce qui revient alors à écrire 0 ou 1)...
Je me pose aussi une question concernant le nécessaire double envoi d'info.
En mode TIME, je trouve ça bien (ça simplifie l'écriture puisque un seul et même message suffit pour produire du ON/OFF). En mode FLASH, ça peut aller aussi lorsque tu veux faire durer ton effet quelques secondes (au lieu de faire appuyer/relâcher comme sur l'interface DL ou un jeu d'orgue classique, tu fais appuyer/appuyer. Par contre, lorsque tu veux un effet flash vraiment instantané, le double-clic est alors trop long, pas assez réactif. Mais je ne sais pas comment contourner cette difficulté.

Par ailleurs:
- l'adresse /sub/kill ne fonctionne pas (Renaud l'avait déjà signalé, je crois);
- le retour d'info /sub/1 /sub/2 etc. ne donne rien: je ne reçois l'info retour qu'en écrivant /sub avec une double info: n° de sub et level: par ex. /1 255. C'est un super avantage car, lorsque tu utilises 60 masters, ça t'évite d'écrire un routeOSC laborieux. Mais l'inconvénient c'est que lorsque tu envoies plusieurs masters en synchro, tu ne reçois qu'une seule double info (le dernier dans la chaîne de tes connexions). L'idéal serait donc d'avoir le choix, selon tes nécessités, entre deux syntaxes, voire même de pouvoir noter les deux si besoin: par ex.: /sub /sub/7 /sub/12 /sub/28, le premier permettant de suivre les déclenchements de masters non simultanés et les autres d'avoir une vue sur des synchros précises qd c'est nécessaire...
A moins de pouvoir avec /sub obtenir une liste en retour d'info, du genre: /4 255 /9 220 14/ 127... Mais je ne sais pas si c'est possible.

Voilà mes quelques réflexions sur l'écriture des masters.

Un autre problème à te signaler, dont j'ignore l'origine mais qui apparaît avec la nouvelle syntaxe des /sub dans la 3.0.2: pour tester j'ai écrit plusieurs messages Pd différents et, lorsque j'envoie un message [send /sub/1/level $1] en utilisant alternativement pour $1 des messages à valeurs fixes et un slider, j'ai par moments des temps de latence durant lesquels il n'y a plus de réaction du master. Ce qui me paraît bizarre... Le même type de messages avec /circ par exemple ne crée aucune absence de réactivité. Et surtout, le même patch adapté pour ta version DL 2.1 [send /sub/1 $1] ne pose aucun problème: la réactivité est sans faille. As-tu une idée là-dessus ?

Bon, courage !

A+

Olivier

Après ce long commentaire, j'essaye de synthétiser une proposition concrète pour les masters. Tu diras ce que tu en penses.

4 adresses:
/sub/#/time
/sub/#/flash
/sub/#/mode
/sub/#/solo

/sub/#/time
Valeur: 0-255
La valeur du level doit être prise en compte. Si le TARGET est à 127 et que la valeur demandée est aussi à 127 le master montera à 25%.

/sub/#/flash
Valeur: 0-255
La valeur du level doit être prise en compte (elle l'est déjà). Donc idem: si le TARGET est à 127 et que la valeur demandée est aussi à 127 le master montera à 25%.
De plus: même si le master est programmé en mode TIME, cette syntaxe devrait l'obliger à fonctionner en mode FLASH sans déprogrammer le mode TIME. Ce qui permettrait une utilisation ponctuelle en mode FLASH d'un master programmé en TIME sans devoir passer par /sub/#/mode avant et après son utilisation flash.

/sub/#/mode
Valeur: 0-1
Il faut maintenir cette adresse car elle peut être utile. Si par exemple j'ai besoin temporairement d'utiliser tous les masters en mode FLASH, je peux programmer un changement automatique de mode. Ce qui permet de reprendre la main directement ds DL et d'avoir tous mes masters prêts à flasher, puis de rétablir aussitôt leur programmation initiale. Depuis DL, il est trop compliqué de faire ça. Ce serait donc un avantage.

/sub/#/solo
Valeur: 0-1
Cette adresse remplacerait /sub/#/type. C'est la même chose mais en plus transparent : si /solo==0 t'es pas en solo, si /solo==1 t'es en solo. Comme ça c'est clair.

Petite subtilité supplémentaire:
- pouvoir, si besoin, remplacer # par all, ce qui peut être très utile:
/sub/all/time ou /sub/all/flash ou /sub/all/mode ou /sub/all/solo.
Si c'est plus simple à programmer, on peut utiliser le 0 au lieu de all.
Ex: /sub/0/mode 0 == tous les subs en mode flash.

Sur ces bases:
- l'adresse /sub/#/level n'a plus de raison d'être puisque /time et /flash reçoivent obligatoirement la valeur du level.
- l'adresse /sub/kill devient également inutile: il suffit d'écrire
/sub/0/flash 0 pour tuer tout le monde.

Côté retour d'info, je te propose ceci:
/sub [version avec liste comme évoqué dans le post précédent]. Ce qui donnerait:
/1 255 /6 127 17/255 etc.

Sinon, 2 syntaxes conjointes:
/sub
et
/sub/#

Plus ceci:
/sub/mode (avec en retour: /# 0 ou /# 1)
/sub/solo (avec en retour: /# 0 ou /# 1)
Mais, là aussi, une version liste serait bienvenue.

Et là, ce serait le top. :silly:
Est-ce que ça te paraît jouable ?

A+

Olivier

En ce qui concerne les retours d'information, il me parait important d'avoir un message qui soit le même qu'à l'envoi. Ainsi, on a une update des interfaces graphiques sans avoir à parser une liste (ex : slider sur pure data, touchOSC ou lemur)

pour le reste cela me parait cohérent…

Pour ce qui est du tableau des adresses OSC, je viens de voir qu'il y a une section wiki sur le site, est-ce que cela aurait du sens de créer une section OSC dans le wiki de Dlight?