Salut,

Oui, tu peux le faire, après la question est un peu vague. Il te faudrait décrire le lien entre repérage des trains et le placement des enceintes. Là on pourra t'aider davantage.

Bonsoir à tous et merci pour votre accueil!

La maquette occupe une pièce de 5mX4.50m  avec un HP aux 4 coins,  +1 au centre sur un des cotés et un sub.
Le logiciel de pilotage envoie sur le serveur IP  le nom du train et ses coordonnées XY en centimètres avec comme valeurs de X 0 à 500 et Y 0 à 450   
ces données sont actualisées 50 fois par sec .   
Dans ce référentiel les coordonnées des 4HP d'angles seraient  (0  0) (0 450) (500 0) (500 450)
       

J'ai copié un premier patch avec un lecteur son utilisant les tableaux et ca marche !
j'ai hate de découvrir la suite   

A bientot
Eric M

Utilise [netreceive] à la place de [tcpclient]
Pour voir la tête des données tu peux utiliser [print] pour afficher dans la console les messages reçus.

Euh non.. netsend et netreceive, ça sert à communiquer à l'aide du protocole FUDI (des messages en texte qui se terminent avec un caractère "point virgule", transportés au choix dans du TCP ou de l'UDP : http://en.wikipedia.org/wiki/FUDI )... à moins que tu ne puisses faire "parler" ton serveur en FUDI ?

Intégrés à Pd-extended, les "externals" réseau des librairies net ou mrpeach n'ont rien d'obscur : ils sont bien documentés mais (parfois) complexes à mettre en oeuvre. En effet, ils émettent et reçoivent les données binaires "brutes", sous forme de liste d'octets qu'il faudra donc "coder" ou "décoder" sous la forme souhaitée. Cela ne facilite pas leur usage, mais en contrepartie, ce sont des objets merveilleusement génériques (hihi) qui ont l'immense avantage de permettre l'implémentation de n'importe quel protocole ! (on peut tout faire, j'ai même envoyé un MMS avec... )

Martin Peach, un des principaux développeur des ces objets réseaux, a fourni un "décodeur" du protocole OSC sous la forme de l'external [unpackOSC], ce qui est bien pratique... quand on utilise ce protocole.
A moins d'en programmer un, il n'existe pas encore d'external "décodeur" pour d'autres protocoles (d'ailleurs ça participe probablement à la popularité d'OSC comme protocole réseau de prédilection pour Pd).
Mais il reste POSSIBLE de faire le nécessaire "à la main" dans un patch.

Le plus simple, c'est quand le protocole est très simple Par exemple, des messages textes (donc sous forme d'octets en ASCII) pourront être aisément transformés en messages Pd grâce à [tof/from_ascii_code] (et inversement [tof/to_ascii_code] pour la transmission).

Tu peux commencer par utiliser [mrpeach/tcpclient] (TOUT est expliqué dans l'aide de l'objet) comme tu as fait et, effectivement, brancher en sortie un [tof/from_ascii_code 13] suivi d'un [print] pour déjà voir ce que tu reçois.
Ensuite toute la difficulté, c'est de trier les données reçues, ça nécessitera évidemment un bonne maîtrise des objets [list] et plus généralement de la "logique" des messages dans Pure Data.

Dernière modification par Nicolas Lhommet (2014-12-11 19:52:27)

Bonsoir,
merci de vos réponses,  dans le patch que j'ai récupéré avec "TCPCLIENT" j'ai une print et je vois effectivement  des chaines de nombres dans la console, 
je joins une vue du client IP pour visualiser ce que cela devrait donner quand j'airai compris comment le reformater car je n'arrive pas à créer  [tof/from_ascii_code] peut etre une bibiothèque à ajouter?

Bonsoir à tous,
après avoir décodé avec [tof/from_ascii_code 59] et pas [tof/from_ascii_code 13] parce que les messages du serveur sont séparés par des ;;;;;
cela commence à ressembler à quelque chose....il ne reste plus qu'a trier tout ca ...

Merci Nicolas pour tes conseils et ta grande patience

EMA883 a écrit:

Bonsoir à tous,
après avoir décodé avec [tof/from_ascii_code 59] et pas [tof/from_ascii_code 13] parce que les messages du serveur sont séparés par des ;;;;;

ah bah je vois que tu as enfin lu (et surtout compris!) l'aide de l'objet... c'est pas trop tôt ! mais tant mieux, parce que ça peut encore te servir.
En effet, cet objet attend soit un "bang", soit d'atteindre le code ascii donné comme argument à sa création, pour enfin renvoyer le message décodé.
L'aide présente un usage classique, avec le code ascii 13 ("retour chariot") qui indique généralement une nouvelle ligne (pour les néophytes, je signale que c'est le cas dans tous les textes numériques : traitement de texte, mails, messages sur le forum, etc...). Donc c'est pratique pour séparer les messages de texte par lignes.

Pour ton serveur, plutôt qu'un simple caractère de terminaison, c'est une sorte d'"en-tête" de taille fixe, présent au début de chaque message, qui va permettre d'en déduire la longueur et donc la fin (comme détaillé page 6 de la documentation du protocole; pour ceux que ça intéresse, on peut la trouver en bas de la rubrique Téléchargement sur le site du logiciel de contrôle "ferroviaire" CDM-Rail qu'utilise EMA883 : http://cdmrail.free.fr). Exemple de message décodé :

S-R-01-0001-CDMGEN-__ERR|039|03|ERR=200;SEV=2;MSG=Layout_Not_Loaded;

- S-R-01-0001-CDMGEN-__ERR : commande (de longueur fixe, 24 caractères)
- 039 : toujours composé de 3 chiffres, nombre de caractères pour la suite (en commençant juste après le "|" - qui suit, et jusqu'à la fin du message)
- 03 : nombre de paramètres
- ERR=200;SEV=2;MSG=Layout_Not_Loaded; : les 3 paramètres annoncés, chacuns suivis d'un ";"

";" est un caractère de terminaison qui t'as servi à isoler tes paramètres, mais on voit qu'il te reste encore 3 caractères de séparation, et donc tu pourrais aussi les utiliser pour décomposer (et délimiter) tes messages avec d'autres [tof/from_ascii_code]
Par simple curiosité, comment t'y es tu pris finalement, pour te "débarrasser" du début du message et n'obtenir que tes paramètres dans la console ?

Dernière modification par Nicolas Lhommet (2015-01-17 01:19:08)