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):

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

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!

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

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.

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

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

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.

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?

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

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

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

Avec tunnel.py? [1]

[1] http://www.eecis.udel.edu/~manicka/Rese … is_PPT.pdf

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...).

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.

tu as regardé ça :
http://www.nabble.com/GNURadio-compile- … ian-Lenny-(Testing)-td19235169.html
j'ai l'impression qu'il y est fait le tour de la question de l'installation sur lenny et aussi ubuntu...

Oui en fait c'etait plus simple de l'installer sur Ubuntu (Hardy sur X31) directement depuis les paquets en rajoutant des sources depuis le site de gnuradio [1].
Etch et Lenny ne permettent pas encore d'acceder a la derniere version de GnuRadio.
En tout cas ca tourne sur Ubuntu.
Un test en compilation sur GentooPPC est en cours.

Maintenant il faut voir comment lancer des scripts python depuis puredata.
Et si ca marche adapter une interface gnuradio<>python<>puredata.
N'y a t-il pas moyen d'ecrire directement sur le terminal depuis pd?

[1] http://www.gnuradio.org/trac/wiki/UbuntuInstall

cosmin a écrit:

N'y a t-il pas moyen d'ecrire directement sur le terminal depuis pd?

l'objet [shell] fait ça

PS : si quelqu'un à une piste bien balisée pour installer pyext je suis preneur...

Ici http://codelab.fr/939#p4595 un tuto sommaire pour installer flext sur Osx.
Je vais aussi tenter d'installer flext sur une gentoo ppc et Ubuntu Hardy X86.
Et j'edite le parcours.

As tu essaye le binaire py/pyext depuis http://grrrr.org/ext/beta ?

Installation de py/pyext

En attendant des sources plus optimisees, telecharger les binaires a cette page:
http://grrrr.org/ext/beta/pd/

Sur Osx:

Definitivement le py.pd_darwin format zip ( py.pd_darwin-osx.4-py2.5.zip 07-Mar-2008 00:47  215K ) de la page http://grrrr.org/ext/beta/pd/osx/ fonctionne sur Osx Tiger. Il faut prealablement intstaller Python 2.5 ( via Macports par example ) et copier le framework du pthon version 25 dans le chemin du framework natif d'osx (/System/Lybrary... d'osx ).

Apparament le ficier py.pd_darwin du 05-Jan-2008 23:36  521K ne fonctionne pas sur ma plateforme osx.


Sur Linux:

A la page http://grrrr.org/ext/beta/pd/linux/, le py.pd_linux du 20-Jan-2009 14:09  287K s'installe bien, du moins sur une Ubuntu Hardy Heron.

Dans les deux cas, placer py/scripts dans /externs (copier le dossier py/scripts depuis examples ou depuis les dernieres sources de py/pyext) pointer un raccourci sur le directoire py/scripts pour charger les libreries.
Appeler egalement "py" au startup de pd.

ok merci cosmin je vais regarder tout ça...
j'ai pas eu de net pendant 1 semaine à cause de la tempête qui s'est déchainée chez nous... et maintenant quand on regarde les arbres, on a l'impression d'avoir la tête penchée :/ bizarre...
sinon, tu as avancé sur les problèmes de communication avec ton interface ?

Salut rep,
On a vu la catastrophe en images a la TV.
Je me demande ce qui est pire: revenir momentannement a l'age de pierre, ou assister au spectacle d'une nature ravagee?
On realise encore une fois combien on est vulnerable face aux elements dechaines de la Nature, et combien dependants de l'infrastructure technologique et energetique dans notre societe cybernetique.
Comment communiquiez-vous sur de longues distances?
Il vaut mieux avoir un bon vieux radio-amateur et une  bicyclette pas trop rouillee dans le coin!

Pour moi le projet USRP<>puredata avance mais j'ai l'impression a retrograde.
Pas evident de faire communiquer [pyext] et des modules python parfois charges par dossiers entiers (...from gnuradio import gr...etc..).

Apparament l'aide sur [pyext] que l'on trouve sur le net est relativement inexistante hormi les examples natifs de pd-extended, et malgre les aimables directives de Thomas a ce sujet, il ne m'est pas evident de faire correctement communiquer [pyext] et gnuradio.

Pour moi ce qui est surtout hermetique c'est le Python.
J'ai ecume quelques cannaux IRC et mailing lists, mais pour l'intant je n'ai trouve aucune aide qui convient a mon probleme.

Cosmin

J'ai sous-estime les degats causes par Klaus...
J'aimerai bien savaoir si la gestion de la catastrophe est bien geree par le gouvernement, ou si ce n'est encore qu'une propagande mediatique. En tout cas ca fait plaisir de voir rejaillir la solidatite Cathare.



Concernant [pyext]:
Je bute encore sur la connextion pyext <> gnuradio.
Je dois surement passer a cote d'erreurs simples dues a mes lacunes en language python.
Alors je teste et m'accroche encore.

Pour revenir à Zombie...

J'ai installé :
- wxpython 2.8 via les dépôts officiels
- simpleOSC d'ixi et pyOSC

J'ai récupéré zombie 0.1...

Mais je me suis retrouvé avec un :

ImportError: No module named osc

J'ai changé la ligne en

import OSC as osc

Mais je récupère un :

File "zombie.py", line 202, in __init__
    osc.init()
AttributeError: 'module' object has no attribute 'init'

Je me dis donc qu'OSC n'est pas osc... et que j'ai merdouillé quelque part... :P
Du coup, Rep, aurais-tu utilisé zombie récemment... sur une Ubuntu 10.04, par exemple ?

Merci...