Contrôle des submasters via OSC

@Olivier,
j'ai pas trop le temps de te répondre en détail, mais merci pour tes suggestions qui me paraissent cohérente également.
j'essaye d'intégrer ça pour la 3.0.3, mais il parait de plus en plus évident que l'OSC doit faire bonne figure dans DL

@Renaud,
le wiki est exactement là pour ça, si vous pouvez écrire une section qui reprendrait ton tableau, i guess ça serait perfect

++

voyez vous un inconvénient à ce que la commande /pad/freeze devienne monostable?
si le freeze est actif, la commande le désactive et inversement; plus de niveau associé à la commande.
c'est pour assurer une compatibilité avec une nouvelle commande Midi (associé à une Note) qui ne gère pas les niveaux.

++
nico

sl1200mk2 écrit: voyez vous un inconvénient à ce que la commande /pad/freeze devienne monostable?

Au niveau commande, il n'y a me semble-t-il, pas d'inconvénient. Au contraire, ça simplifie l'écriture.
Par contre, au niveau retour d'info, il est important de pouvoir connaître l'état (0-1).
Or, pour l'heure, il n'y a aucun retour pour les commandes /pad/...
Il en faudrait au moins pour freeze, blackout, scene, prepa, X1, X2.

A+
Olivier

sl1200mk2 écrit: le wiki est exactement là pour ça, si vous pouvez écrire une section qui reprendrait ton tableau, i guess ça serait perfect

Oui qui...? Pour ma part, je suis prêt à y contribuer...

Olivier

j'ai commencer à faire le Wiki tu peut le completter ou si tu as du temps écrire une section ?

@pierremine
J'ai vu la page OSC que tu as mise dans le wiki. Super initiative !
Je pense cependant qu'il faudrait supprimer les commentaires. C'est bien qu'ils restent dans le google.doc créé par Renaud, ça permet de faire avancer la réflexion. Mais dans le wiki, il me semble qu'il faut un outil plus pratique, avec une lecture claire, simple, efficace, sous forme de tableau.
Qu'en penses-tu ?

Olivier

C'est moi qui ai repris le tableau google sur le wiki. Le plus efficace serait effectivement de synthétiser les différentes adresses.
L'espace est un wiki, chacun peux donc le modifier. Olivier, n'hésites pas à faire de la mise en forme, celle-ci sera la bienvenue.

Merci pour le Wiki

Nico,
J'ai rédigé une page OSC pour le wiki que je vais encore compléter.
En revérifiant les commandes, je me suis rendu compte que la 3.0.2 ne reçoit plus le message /circ/#
J'avais déjà mentionné le cas des subs qui ne reviennent plus par /sub/#
En fait, :Light renvoie ceci:
/circ/5 255 (par exemple)
et pour les subs:
/4 255
Mais les seuls messages qui permettent de router les données sont:
/circ qui donne /5 255 (dans mon exemple)
et /sub qui donne /4 255
De fait, c'est un peu compliqué car il faut séparer les données du paquet et utiliser un séparateur pour virer le / (on y arrive mais c'est une écriture un peu lourde). Surtout: dans le cas d'envoi simultanés, une seule donnée est récupérable, la dernière de la chaîne.
Si tu pouvait réintégrer l'ancienne syntaxe, ce serait super.

A+

Olivier

pour la 3.0.3, j'ai essayé de faire un bundle (vers le milieu de la page).
comme ça je n'envoie qu'un paquet qui devrait être de la forme /circ/x FF /circ/y FF....
mais tu me diras ce qu'il en est, je vais publier une beta avant la release de la 3.0.3

et c'est quoi pour toi l'ancienne syntaxe?

++

/circ/1 etc.
/sub/1 etc.
Je regarderai ton lien opensoundcontrol.org et je te dirai.

O.

Oui, effectivement le bundle me paraît plutôt bien pour éviter un routage avec de longues énumérations...

O.

@Olivier,
j'ai pas pu répondre à tes demandes pour cette version, mais ce n'est que partie remise.


Cela étant, ya eu pas mal de nouvelles dans l'osc concernant les messages émis/reçus de séquence, les niveaux de sub/circuits émis

merci de tester tout ça,
++

merci de mettre à jours le wiki si il y as lieux....

@ Nico

J'ai testé et ça me paraît pas mal.
Au fond, malgré ce que j'ai pu dire précédemment, le fait d'avoir une syntaxe retour unique /seq avec différentes infos qui lui sont liées (commande, pas, etc.) me plaît bien, même si ça ne va pas dans le sens de ce que souhaitait Renaud à savoir l'identité des messages envoi et retour. Il suffit ensuite de dispacher les différentes infos.
Le point fort, selon moi, c'est le suivi des pas de séquence, ça c'est très bien.

Les deux points faibles, si je peux me permettre, se situent au niveau des circuits et des subs:
1) le fait que les numéros de circuits ou de subs soient sous forme de symboles (/# et /#/level) et non pas de nombres: les retours pourraient être tout simplement des listes de nombres (1 255).
2) la syntaxe des subs est toujours la même quel que soit le mode flash, time ou level et les valeurs ne correspondent pas forcément à ce qui est envoyé (ex: en mode time, tu envoies /sub/1/flash 1 et tu reçois /1/level 255 si ton target est à full, c'est un peu tordu).
Bon, à suivre...

J'ai fait les adaptations du wiki. Dis-moi s'il y a d'autres modifications qui m'ont échappé (j'avoue que je n'ai pas tout vérifié). J'y mettrai un peu plus tard les adaptations nécessaires des patches Pd avec un dispatch pour la récupérations des différentes infos (ça devient nécessaire).

Allez, comme on dit à New Orleans, "estamos en contacto".

A+

Olivier