ou sharemem

J'essaie de piger la chose
à priori
pd~ ouvre un nouveau patch ( déclaré par son nom ? ) dans une nouvelle instance et dépendant du premier.
cela permet d'utiliser les différents core de la machine ( un par instance ? )
est-ce qu'on se limite à deux instances, une interface, l'autre audio ? où bien est-il aussi judicieux de séparer certaines parties de l'audio ( traitement et sampleurs par exemple ) ?
Comment faire fonctionner les send receive d'une instance à l'autre ?
Dans ma situation à moi, je n'ai pas une surcharge notable des processeurs, c'est vraiment dans la partie synthèse que ça se situe.
J'accusais les [counter] parce que jusque là, je n'utilisais pas cet objet, je les faisais moi même, et je n'avais pas ce problème, les patchs étaient sûrement moins chargés aussi.
Merci de vos lumières.

citation :

je me permets de relancer, je n'arrive pas à bien comprendre les principes qui organisent la division d'un patch en plusieurs parties.
Jusque là je n'en avais pas besoin, mais je viens de rajouter un bout de patch de plus et ça devient le bordel.
Faut-il éviter les Gop même dans des sous-patchs ?

il faut surtout eviter les objets graphiques tout court en général, qui font ralentir le système (bien que la dernière version de pd-extended améliore pas mal la chose... )

citation :

Entre deux instances,  communication en OSC obligatoire ?

si elle ne sont pas liées par un [pd~] c'est le mieux oui.

citation :

Est-ce que ça vaut le coup de séparer en trois ou quatre un patch chargé ?

si l'ordi est multicoeur et que les processus sont lourds, oui, ça distribue le calcul .

citation :

Et puis, je n'arrive pas à ouvrir un patch avec pd~, l'aide est pour le moins succinte, où trouver un peu de doc sur ce genre de sujet ( d'ailleurs, comment on peut nommer ce genre de sujet ? ) ?
Navré d'insister, mais je suis en galère.
Bien à vous et merci d'avance.

albdet

pour bien faire, il faut une application "maitre" et des patchs appellés par les

[pd~ start monpatch.pd (
|
[pd~]

on met le patch maitre dans le même dossier que les patchs esclaves, et voilà...
on communique entre eux grâce aux inlet/outlets de [pd~]

pour envoyer au patch esclave :

dans patch maitre : 

[send monpatchreceive blahblah (
|
[pd~]

dans monpatch.pd :

[r monpatchreceive]
|
[print]
   
pour recevoir dans le patch maitre depuis monpatch.pd

dans patch maitre

[pd~ start monpatch.pd (
|
[pd~]
|
[route monpatchsend1 monpatchsend2]
|                               |
[0]                           [0]

dans patch monpatch.pd

[monpatchsend1 1 (
|
|  [monpatchsend2 1 (
| /
|/
[stdout]

citation :

Notamment une question qui se pose, on ne peut utiliser qu'un receive par port ? c'est un peu génant pour moi.

Oui, un seul [udpreceive] par port et par machine !

citation :

Sinon, on renvoie ensuite avec les [send][receive] de pd ?

Exact. Ou alors tu renvoies sur un autre port, mais bon...

L'avantage d'OSC c'est de disposer d'un système hiérarchique : si tu dois contrôler une abstraction qui a 4 paramètres, tu peux contrôler le premier en envoyant [/monabstraction/parametre1 mavaleur<.

Ensuite
[udpreceive monport]
|
[unpackOSC]
|
[routeOSC /monabstraction /rienavoir]

et après tu peux router tes 4 paramètres avec
[routeOSC /parametre1 /parametre2 /parametre3 /parametre4]

je te joins un exemple. Perso j'utilise la bibliothèque mrpeach, je crois qu'oscx se fait un peu vieille...

Dernière modification par dwan (2013-04-20 21:05:02)