Bonjour. J'ai testé ton patch (où le problème est exposé de manière parfaitement claire, merci ) : tu "joues" simultanément 5 échantillons identiques, et déclenchés par l’intermédiaire de tes messages OSC transmis via les objets UDP, et, en effet, ça "sonne" parfois typiquement comme un problème de phase (légèrement décalées, elle s'opposent pour certaines fréquences, d'où l'effet de filtre perçu). Et qui dit "déphasage" dit "décalage dans le temps"...

On peut mesurer les durées entre deux bang (ou nombre, ou liste) reçus grâce à l'objet "vanilla" [timer] qu'il suffit de mettre en sortie de ce qu'on veut mesurer comme ceci (ce qui affichera le nombre de millisecondes dans la console) :

[t b b]
|     |
[timer]
|
[print]

"Branché" ainsi simultanément aux [bang( qui précède chaque "samplers", ou bien en sortie de ta commande initiale d'envoi de messages OSC (le message [send ...( en haut), je ne mesure aucun décalage, l'objet [timer] me renvoie toujours 0ms (on a juste l'intensité de l'échantillon multipliée par 5, ce qui est normal).

Par contre en sortie de [udpreceive] j'obtiens parfois (avec mon Pd-extended 0.43.4 sur Win7) un (étrange) écart de 1,45125ms entre chaque "message" reçu, et par conséquence le même délai entre chaque 'déclenchement' d'échantillon, qui est la cause de ces problèmes de phase.

Donc ça doit venir d'une "particularité" du fonctionnement interne soit de [udpsend] ou de [udpreceive]. Mais en remplaçant ce dernier (qui est celui de la librairie mrpeach) par la version [iemnet/udpreceive], je n'ai plus ces décalages (reste à voir ce que ça donnerait sur les autres OS...)

Dernière modification par Nicolas Lhommet (2015-02-07 18:45:58)

Merci à tous les deux pour ces réponses.

Pour Berenger : non, chez moi, il y a le même problème quelque soit l'ordre des messages. C'est vraiment étrange qu'il y ait un fonctionnement différent chez toi, si tu es sur Mac. Sur PC, cela m'étonnerait moins car le fonctionnement sur PC n'est pas régulier…

Pour Nicolas : ta solution fonctionne chez moi. Super ! Effectivement, le récepteur [udpreceive] venant de la bibliothèque iemnet corrige le problème. Il s'agit donc bien d'un bug du module [udpreceive] de la bibliothèque mrpeach.

Pertuit a écrit:

Sur PC, cela m'étonnerait moins car le fonctionnement sur PC n'est pas régulier…
...
il y a un troisième module [udpreceive] dans la bibliothèque net. Mais, comme pour la bibliothèque mrpeach, il ne fonctionne pas correctement.
Une uniformisation de ce module dans les bibliothèques serait peut-être bienvenue...

...et vivement tout le monde sur Windows ! ça éviterait ces fonctionnement irréguliers d'OS secondaires Plus sérieusement, pour les "modules" dont tu parles : c'est normal, ils sont identiques, voilà comment on peut s'en assurer sur Mac:

citation :

ta solution fonctionne chez moi.
...
Il s'agit donc bien d'un bug du module [udpreceive] de la bibliothèque mrpeach

Disons que c'est un external pas spécialement optimisé, et d'ailleurs les versions "iem" de IOhannes m zmölnig sont des "fork" des objets réseaux de Martin Peach ("mrpeach") qui se veulent plus fiables (voir toutes les explications dans Navigateur d'Aide -> iemnet -> README.txt).
Même si ça apporte un semblant de solution (avec [iemnet/udpreceive], je n'ai plus les délais sur Windows et Mac OS, mais ils demeurent sur Ubuntu...) l'erreur, c'est plutôt de présumer que des messages envoyés sur le réseau au même moment  arriveront à destination obligatoirement en même temps. C'est généralement le cas sur la même machine (via l'interface virtuelle 127.0.0.1) mais il n'y a aucune garantie que ça le soit dans une transmission réseau normale (et encore moins quand elle est "sans-fil"...).

Via le "réseau", si tu veux déclencher des événements le plus simultanément possible (dans ce cas, pour éviter des déphasages de tes échantillon), le mieux n'est pas d'envoyer des "ordres de déclenchement" les uns après les autres et  le plus vite possible (comme tes 5 messages "send /trigger X" séparés par des virgules), mais d'envoyer un seul message les contenant tous.

Personnellement, je n'utilise pas (et connais mal) le protocole OSC (dont il est malheureusement fait une promotion systématique et réductrice, dès lors qu'il s'agit de réseau dans Pure Data...) mais je me suis dit qu'une manière de grouper les messages avait forcément été prévue...
Une recherche sur Google avec les mots "pd osc" (pas évident à deviner... ) m'a donnée comme 1er résultat la page du "FLOSS Manual" de Pure Data consacrée à OSC, dans laquelle est présentée le mécanisme de "Bundle" qui sert justement à ça. Et en groupant tes messages dans un "bundle OSC", comme ceci (juste en ajoutant les "messages crochets" au début et à la fin) :

... ça fonctionne très bien sur tous les OS et avec tous les objets UDP, y compris ceux de la librairie "mrpeach".

J'ai également mis en pièce jointe le même patch, modifié pour reproduire ce système de "groupe de messages" en utilisant uniquement des objets "vanilla" (donc qui peut aussi marcher avec Pd "pas extended"), à base de netsend/netreceive, et sans OSC (comme la boucherie )

Berenger a écrit:

...[oscparse] / [oscformat] existent (un exemple en pj)

ah, bah voilà, qu'est-ce que je disais... encore du OSC (on le met à la porte, il revient par la fenêtre) et des messages envoyés séparément, donc c'est reparti pour les problèmes de phase, retour à la case départ........ c'est de la provoc' ??

Pertuit a écrit:

Je ne connaissais pas la solution du "bundle" et cela fonctionne très bien. En l'occurrence, je ne pourrai pas l'utiliser car, dans mon programme, les messages ne sont pas envoyés par Pd, mais par IanniX et les envois en format OSC sont nécessairement disjoints...

...étonnant, pour un programme spécialisé dans la gestion des événements dans le temps !
Du coup, j'ai regardé un peu Iannix, il y a bien un réglage (que tu as certainement essayé) dans Inspector->Config->Network : "MAKE OSC BUNDLE ON" pour lequel on peut spécifier une adresse IP et un port. Logiquement, ça doit être prévu pour envoyer des bundles OSC, non?? Seulement, rien n'est envoyé sur le port spécifié... on reçoit uniquement les messages normaux (disjoints) sur le port de sortie OSC principal (qui est indiqué juste au dessus dans "DEFAULT_IP"). Bizarre, bizarre.....

Du coup j'ai regardé le code de Iannix (merci l'open source !) et dans la fonction d'envoi des messages OSC, j'ai trouvé ceci :

if((message.getPort() == bundlePort) && (message.getHost() == QHostAddress(bundleHost))) {
  //Add message to bundle
  bundleMessages.append(message);
}

(source : https://github.com/iannix/IanniX/blob/m … c.cpp#L411 )
Ce petit test peut se traduire ainsi : "si le port utilisé (pour l'envoi d'un message OSC) est égal à celui spécifié pour les bundle OSC  (ainsi que l'adresse IP), alors ajoute le message dans un bundle". Et c'est bien ça !! :
Si on spécifie le MÊME PORT et la même adresse IP pour les deux réglages de sortie OSC dans l'interface de Iannix ("default" et "bundle") alors TOUS les messages sont envoyés dans des bundle OSC, avec les événements simultanés correctement regroupés dedans...
Donc si tu configures OSC dans la rubrique Network de Iannix comme ceci (avec le port 57120 pour les deux réglages) :

... le patch que tu as posté, utilisé tel quel sans modification, ne devrait plus avoir de problème de phases

A noter que, à l'instar de l'objet [unpackOSC] de Pd-extended, le (très récent) objet [oscparse] de Pd "vanilla", signalé par Berenger, sait également "disjoindre" des bundle OSC. En revanche, contrairement à [packOSC], [oscformat] ne permet pas (encore) d'en créer... mais il y a moyen de fabriquer ses propres bundles OSC, comme j'ai fait dans cette nouvelle variation "vanilla" de ton patch, en pièce jointe (cette fois-ci uniquement pour Pd 0.46-1 et supérieur).

Dernière modification par Nicolas Lhommet (2015-02-09 13:55:50)