Contrôle des submasters via OSC

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