Salut !
Je suis en train d'essayer de bidouiller un patch qui aurait pour effet de mélanger un flux webcam avec une analyse audio à base de [pix_sig2pix~], mais je comprends pas.
Déjà, j'ai du mal à piger l'histoire de [block~]. Quand je ne m'en sers pas, l'image générée par l'analyse d'un signal entrant ne prends pas tout l'espace demandé, à savoir un con de [square 4]
D'autre part, lorsque je m'en sers de façon à ce que tout l'espace soit rempli, ce n'est pas aux même dimensions que les images de la webcam, à savoir 640x480, la dimension du [pix_sig2pix~] est de 640x4.
En plus j'ai un "adc~: bad vector size" qui a un rapport direct avec le [block~]
Ah oui, et aussi un "GEM: Someone sent a bogus pointer to copy2Image" mais que je sais pas trop d'où il viens.
Bref, mes questions :
- Pourrait-on m'expliquer ce qu'est ce [block~] ? J'ai un peu du mal à piger sur les forums anglais
- Comment pourrais-je faire pour que les 2 images (webcams et analyse audio) soient de la même dimension (pour ensuite les mélanger avec [pix_diff] par exemple) ?
Ci-joint mon patch tel qu'il est actuellement
Merci !
Dernière modification par RoKN (2013-05-20 12:53:37)
Hors ligne
J'aurais du mal à t'expliquer convenablement [block~ ] mais, pour info...
4096 = 64 x 64
d'où la taille du [block~ 4096 ] pour un [pix_sig2pix~ 64 64]
Bon courage...
Hors ligne
Et donc si je veux faire en sorte que ce soit de la même taille que la vidéo, il faut donc que je fasse 640 x 480, ce qui fait... 307200 !
Déjà qu'à 16384 ça commence à "ramer" un peu... non, c'est forcément autre chose
Peut-être que la taille du [sig2pix~] dois obligatoirement être carrée, donc par exemple [sig2pix~ 384 384], donc un [block~ 147486] ?!
... non ya surement un autre moyen...
Dernière modification par RoKN (2013-05-20 18:48:32)
Hors ligne
pour le adc~ encapsule dans un subpatche, ou bienencapsule ton sig2pix~, et voilà ils ne vont plus se parasiter.
Hors ligne
pour faire simple, [block~] est la taille de la fenêtre dans le signal audio qui sera utilisée pour le traitement et l'analyse dans le patch dans lequel il apparait. la quantité de donnée prise à chaque opération.
c'est expliqué un peu plus en détail ici en fin de chapitre :
http://fr.flossmanuals.net/puredata/ch0 … io-dans-pd
l'objet sig2pix~ transpose 1 pixel = 1 sample ... donc oui pour remplir une image 640x480 il faut... du temps...
c'est pas pour rien que la video prends plus de bande passante que le son : il y a plus de donnée sur un même espace de temps. Donc inversément.
une solution ici serait de prendre une petite fenêtre comme 64x64 avec un [block~ 4096] pour garder un framerate correct pour la synesthésie
et de mettre un
|
| [dimen 640 480<
|/
[resize]
|
après le [sig2pix~] pour le mélanger ensuite avec la webcam
Dernière modification par Olm-e (2013-05-22 01:36:37)
Hors ligne
Bon, ton patch est parfait.
Seulement, j'ai vraiment du mal à piger et ça me frustre.
Mais, et qu'en est-il de la lecture de fichiers audio ?
La j'essaye de lire un .wav encodé à 48000Hz, j'ai aussi essayé en 44100Hz, et ça me fait des grésillements, ce qui doit être normal... mais je ne pige pas pourquoi
EDIT :
En fait, en baissant le [block~] à 64, ça lis plus ou moins le morceau, peu en très saccadé.
Je n'arrive pas à faire en sorte que :
1) la lecture se fasse "normalement",
2) les effets de [pix_sig2pix~] soient plus fluides.
Ci-joint le patch modifié
Dernière modification par RoKN (2013-06-05 11:47:05)
Hors ligne