Salut Kro,

Pour l'OSC avec gephex, je ne saurais pas, mais sur OSC en général, voila quelques liens :

Un diaporama (au format .mov) qui aborde à la fois OSC du point de vue de l'utilisateur, mais aussi du point de vue interne,
Everything you ever wanted to know about OSC :  http://opensoundcontrol.org/files/Every … ut-OSC.mov

Une description du protocole TUIO (pour tables réactives, etc, TUIO est bati sur OSC et utilise la même syntaxe) C'est intéressant car il y a des exemples de messages, et ça montre comment structurer un ensemble de messages pour adapter OSC à un "instrument" particulier.
http://modin.yuri.at/publications/tuio_gw2005.pdf

Une comparaison avec MIDI dans ce pdf : http://opensoundcontrol.org/files/OSC-Demo.pdf

Ca correspond à ce que tu cherches ?

ouioui je connais tres bien tout ce qui est réseau
moins ce qui est osc

merci pour le diaporama emoc

tout me semble bon je comprends juste pas pourquoi il ne se passe rien, je peux pas trop débugger dans gephex, p-e quil ne prend pas tous les types de variable

mais en fait je me demande si je suis pas tombé sur un bug, parfois il se passe quelque chose :
la valeur que je modifie dans gephex oscille entre 0 et 1 au hasard (il me semble) quand je change la valeur dans pure data

que j'envoie un float ou un int ne change rien
et si je type cette valeur [/gephex i $1] il ne se passe plus rien

bonsoir à tous . Je reprends ce fil car je pense avoir trouvé ce qui cloche :
au vu des sources C++ des modules numosc et oscnum il semble qu'une opération mathématique soit effectuéee sur la valeur numérique envoyée (essentiellement les fonctions annotées //push value et //get value) qui est de type "float" . En ce qui concerne l'adresse c'est bon . Un truc du genre /gephex/control1/ est parfaitement interprété par un un soft tel que puredata (ai aussi vérifié avec les outils de la  bibliothèque OSC (liblo) ) .
Donc suite à la manipulation de la valeur (à l'envoi) seul gephex  va savoir la décoder vu que l'opération inverse est réalisée . D'une instance de gephex vers une autre çà fonctionne donc très bien .
Je ne connais rien à C++ ni à C d'ailleurs mais au vu de l'analyse des paquets UDP je pense qu'il s'agit d'une manipulation décimal vers binaire (genre puissances de 2) répartie en 3 paquets de 256 plus 1 de 128 où une
multiplication de la valeur par 4 vaut un increment de 1(256)
En connaissant la formule appliquée il doit être facile de la retranscrire dans puredata et ce dans les 2 sens .
ci-dessous ce qui me semble en cause    pour num -> osc (send)
// push float value
  float value = static_cast<float>(inst->in_value->number);
  std::copy(reinterpret_cast<char*>(&value),
        reinterpret_cast<char*>(&value) + 4,
        inst->out_r->data + size_len + address_len + pad_len + 4 );

                                                          pour osc -> num (recieve)
// get float value
        std::copy(p_pos, p_pos+4, reinterpret_cast<char*>(&inst->my->value));

dans les sources de gephex 0.4.4  /modules/src/numoscmodule et oscnummodule .
si l'un de nous est un as de la prog . bienvenue .
à part çà content que le paquet gephex de "tangostudio" fonctionne chez vous (comme chez moi) .
on a pas mal bossé pour le compatibiliser avec le v4l2 des nouveaux kernel et gcc 4.4
cordialement  sakramh

Bonjour,
depuis puredata tout est ok . Un message du type /gephex/control1 $1  est parfaitement interprèté par oscdump de liblo .
Cette page est uptodate sur le sujet : http://en.flossmanuals.net/PureData/OSC
C'est gephex qui comprends pas . Déjà il n'admet que les "float" et c'est lui-même qui met le tag "f" . Gephex envoie la partie adresse ( /trucmuche/voix1 )  corectement et rajoute de lui-même et d'office le type float ( f ) , ce qu'on voit bien dans les sources des modules .
Là où il complique c'est dans l'envoi de la valeur qui est "reinterpreted" dans quelquechose comme la base 4 . Ou dans un algo genre valeur*4=increment de 256 , valeur*2=128 etc ... cela apparait très bien en dépackant les messages UDP  . Mais étant une bille en programation je suis pas capable de dire qu'elle est l'opération exacte effectuée dans gephex sur les nombres avant envoi ou après reception . Une fois celle ci decodée il suffirait dans purdata d'appliquer l'opérateur inverse (ou de modifier les sources de gephex vu qu'il semble que ce soit le seul soft soft à utiliser cet algo)
                                                            cordialement,    sakramh

Dernière modification par sakramh (2010-11-11 14:07:11)