Bonjour
pourquoi
[5(
|
[until]
|
[random]
donne bien 5 résultats différents
alors que
[5(
|
[until] [noise~]
\ ∕
[snapshot~]
donne 5 résultats identiques
ça va trop vite? que faudrait-il faire?
Dernière modification par Jean-Christophe Sekinger (2014-06-15 13:48:05)
Hors ligne
Il est tout à fait possible que la boite [until] crache ses bangs significativement beaucoup plus rapidement que ne le fait [noise~]. En fait, je crois savoir que Pd fait travailler [until] aussi vite que possible, en un seul tick logique. Or, en un tick donné, il ne peut pas arriver plusieurs valeurs audio différentes, donc [snapshot~] ne sort qu'une seule valeur. Il me semble d'ailleurs qu'il existe une version alternative de [until] qui permet d'éviter de bloquer le processus quand on lui demande d'effectuer une tâche particulièrement longue beaucoup de fois.
Je viens d'essayer une solution à base de [metro 2], ça marche. [metro 1], c'est trop rapide
Hors ligne
Le noise en question étant échantillonné à une fréquence donné, il est nécessaire d'introduire un délai au moins égal au temps qui sépare chaque échantillon si tu veux récupérer des valeurs successives.
Mais, dans la pratique, si tu fais un essai avec un [metro 1] tu verras que tu peux tout de même encore choper deux valeurs identiques successives une fois sur deux alors qu'avec du 1/44100 ce ne devrait pas être le cas.
Ne sachant pas exactement ce que tu souhaites faire, je ne peux pas t'aider plus dans le contournement de ce pb...
Hors ligne
Merci!
http://ailleurslatete.free.fr/?Utilisat … terrupteur
j'aurais pu le faire avec random mais quand j'ai un truc en tête, la solitude fait que je doive aller au bout
C'est simplet mes patchs, je ne sais que le minimum. Mais ça me rend heureux
Dernière modification par Jean-Christophe Sekinger (2014-06-15 21:30:40)
Hors ligne
Je crois que les évènements "contrôle" s'intercalent entre, non pas les échantillons de "signal", mais les buffers d'échantillons, qui sont de 64 samples par défaut (réglable avec [block~]).
Du coup des évènements de contrôle espacés de moins que 64 / 44100 = 1,45 ms se produiront en fait "en même temps", dans l'espace du signal.
Hors ligne
Oui je comprends. Il faudrait un [block~ 1] alors?
__
ah non j'ai encore des trucs à apprendre
Dernière modification par Jean-Christophe Sekinger (2014-06-16 09:05:49)
Hors ligne
Ben non c'est vrai que le [block~ 1] ne suffit pas :
Si tu veux vraiment échantillonner le [noise~] (mais franchement le [random] c'est fait pour ça...), tu pourrais choper le 2e, le 3e,(...) sample du buffer à l'aide de [z~ 1], [z~ 2],(...).
Hors ligne
Merci pour l'exemple! Et aussi pour le «mais franchement le [random] c'est fait pour ça...» :-D en y réfléchissant, je me dis que l'utilisation de [noise~] au lieu de [random] avait au moins trois raisons:
1. quand j'utilisais windows et reason, je m'étais servi de bruit pour générer du «hasard» (reason n'était vraiment pas fait pour ça, mais j'avais découvert un truc là qui m'a amené à pure data. Je me suis dit aussi qu'utiliser du bruit blanc était plus à ma portée dans la mesure où j'ai une image mentale d'un bruit blanc alors que de l'algorithme de [random], non. Et même, échantillonner un bruit revient à la sculpture en taille directe ([random] fait un peu tombola à côté non?)
2. buter contre un problème amène à réfléchir (un peu flou pour moi mais passionnant) et à aller vers les autres.
3. la persévération et la persévérance.
Hors ligne
Pour infos, random et noise utilisent exactement le même algo pour générer un nombre pseudo-aléatoire.
Hors ligne
Pierre Guillot a écrit:
Pour infos, random et noise utilisent exactement le même algo pour générer un nombre pseudo-aléatoire.
ouééé! Merci pour la réponse!
Hors ligne
Pages: 1