on parlait récemment de la jonction que l'on pouvait établir entre processing et puredata par l'intermédiaire d'OSC (cf : l'émulation de la TR909 de chez Roland [1]), aujourd'hui je vous fait part d'un petit screenshot ou il est question de cette fameuse jonction osc mais ce coup ci entre un script python, qui dispose d'une interface graphique et qui communique avec un patch puredata, le tout à travers d'une petite bibliothèque, simpleOSC [2] développé par ixisoftware.
Comme vous le voyez il y a ici (de haut en bas et de gauche à droite) :
- une console dans laquelle est lancé le script python python_example.py
- le code source intégral de ce script python (simplissime!)
- python test 1 qui est ce fameux script une fois lancé
- un petit patch qui montre que les données du script python sont bien reçues dans puredata
c'est de cette façon qu'a été réalisé par exemple DelVJ [3], logiciel développé par DelCorp
[1] : http://codelab.fr/154
[2] : http://www.ixi-software.net/content/dow … c0.2.5.zip
[3] : http://www.delcorp.org/delvj/index.php/Portada
l'image (qui est trop grande pour être affichée correctement... désolé... pour la voir dans sa 'vraie' largeur cliquer-droit dessus: afficher l'image):
Hors ligne
Salut,
Pourquoi ne pas utiliser directement netsend et netreceive pour communiquer avec Python.
Je ne connais pas Python pour affirmer mais ça permet de ne pas charger de librairie externe dans Pure Data et de garder le Pure Data Vanilla.
Est ce que c'est réalisable?
Thomas
Hors ligne
Salut rep
je me suis mis à utiliser SimpleOSC également depuis vision'r pour communiquer depuis puredata vers un serveur Web en OSC mais je n'avais pas regardé du côté du Zombie qui a l'air plus avancé !
merci pour l'info rep!
Hors ligne
Bon c'est mon point de vue,
je préfère de loin ne pas utiliser des librairies externe sous Pure data surtout si le patch est amené à être utilisé sur plusieurs machines et plusieurs Systèmes d'exploitation différents.
Je ne suis pas fan de la compilation et configuration en tout genre.
Thomas
Hors ligne
Salut l'indien,
netsend/netreceive reste propre à Pd et Max/MSP ce qui fait un auditoire singulièrement réduit. Evidemement, tu auras toujours la possibilité de coder un bout de python pour te grefffer dessus. Personnellement, je milite pour qu'OSC fasse son chemin dans Pd-Vanilla: cela ouvre la porte à tellement d'autres programmes et hardwares (Gephex, Processing, SuperCollider, Chuck, Reactivision, Lemur , tout programme écrit en Python...) et c'est d'une plus grande souplesse d'usage.
D'ailleurs, il vaut mieux utiliser mrPeach plutot qu'OSCx comme bibliothèque , qui existe déjà compilée pour les 3 plate formes de Pd. De plus, amha, le problème vient de la gestion hyper bancale du chargement des bibliothèques et de la gestion des chemins par Pd plutôt que des bibliothèques elles-même.
On paye beaucoup pour ça le modèle de dévelopement très atomisé de Pd.
++
O.
Hors ligne
oli44 a écrit:
D'ailleurs, il vaut mieux utiliser mrPeach plutot qu'OSCx comme bibliothèque , qui existe déjà compilée pour les 3 plate formes de Pd.
ha oui tiens je connaissais pas mrpeach, j'ai vu passer ce même avis ce matin sur la liste pdmtl et j'avais pas compris tout à fait la raison pour laquelle l'emploi de mrpeach était préférable... merci pour cette précision
Hors ligne
Oui tu as raison mais en principe l'OSC est juste une couche supplémentaire à l'UDP qu'utilise Pure Data et Max/MSP.
Pourquoi les logiciels adoptent plutôt l'OSC que l'UDP tout simplement.
Est il plus pratique à l'utilisation, aporte t'il vraiment de nouvelles fonctionnalités
Thomas
Hors ligne
l'UDP est de plus bas niveau, c'est plus facile pour les pauvres humains d'avoir un système arborescent tel que l'OSC et c'est bien d'avoir une sorte de norme (même si il est souhaitable qu'elle évolue)
Si l'OSC s'est répandu autant, c'est parce qu'il a d'emblée su répondre largement aux besoins. netsend/receive est plus une solution adoptée dans son coin par Miller Puckette , je crois. ça serait intéressant de lui demander son avis là-dessus. P-e que OSC n'existait pas encore à l'époque.
Hors ligne
rep a écrit:
oli44 a écrit:
D'ailleurs, il vaut mieux utiliser mrPeach plutot qu'OSCx comme bibliothèque , qui existe déjà compilée pour les 3 plate formes de Pd.
ha oui tiens je connaissais pas mrpeach, j'ai vu passer ce même avis ce matin sur la liste pdmtl et j'avais pas compris tout à fait la raison pour laquelle l'emploi de mrpeach était préférable... merci pour cette précision
dixit IOhannes Zmoelnig: OSCx a bcp plus de bugs! C'est une bonne raison, non?
Hors ligne
bonnes raison d'utiliser l'OSC quand on travaille sur plusieurs logiciels différents, en revanche si l'on reste sur Pure Data autant utiliser le bon vieux netsend/netreceive
Merci pour ses informations sur l'OSC, ça éclaire un eu les choses
Hors ligne
Pour compléter sur l'intérêt de mrpeach par rapport à OSCx:
-le developpement d'OSCx est stoppé alors MArtin Peach est toujours actif
-mrpeach permet de faire tout ce que fait OSCx ,plus
* le typage des messages forcé ou automatique
* l'ajout de timestamp dans les bundles
cheers
Hors ligne
Salut,
Je cherche a faire communiquer puredata et l'USRP via Gnu Radio et python [1].
Comment realiser un pont de communication entre puredata et l'USRP?
Les objets netsend et netreceive devraient donc suffire si j'ai bien compris?
[1] http://www.gnu.org/software/gnuradio/do … radio.html
Dernière modification par cosmin (2009-01-09 14:16:42)
Hors ligne
Avec tunnel.py? [1]
[1] http://www.eecis.udel.edu/~manicka/Rese … is_PPT.pdf
Dernière modification par cosmin (2009-01-09 14:44:01)
Hors ligne
hééé salut Cosmin, bienvenue !
bien content de te voir par ici !
ça à pas l'air simple ton histoire... N'y aurait'il pas de bonnes ressources en français sur USRP histoire que je capte rapidement quelque chose à ce programme (parce que la... cette doc en anglais... j'ai pas le courage...).
Hors ligne
salut rep
C'est bien de se retrouver.
Le manuel GnuRadio/USRP est essentielement en anglais.
Apparament les modules de communication avec l'USRP sont en python avec ou sans GUI.
Pas facile de trouver une bonne doc en francais.
Je vais retanter l'install de Gnuradio depuis les dernieres sources sur OSX avec Macports (pas simple, probleme de compilation,ect...) et sur une install Ubuntu Gutsy pc (probleme de dependances et de version GnuRadio sur Debian Etch et Lenny).
Le plus simple serait d'essaier sur une Gentoo (apparament les dependances seraient resolues), mais la apres 8 essais infructueux d'installation sur ppc, je commence a perdre la tete.
Apres, si netsend et net receive ne peuvent pas piloter l'USRP depuis puredata, le plan B serait d'essayer avec pd-flext/pd-py.
Mais la c'est encore une autre histoire.
Hors ligne