Hello...

Que te dit la commande htop sur la charge CPU de ta Pi ?

Bon, je viens de faire d'autres tests :

D'abord avec le même patch en réduisant la polyphonie à 8 voies seulement: ça n'a quasiment rien changé (2% de CPU en moins seulement). C'est normal car le problème commence avant même de jouer une note, donc sans solliciter de polyphonie.

Ensuite, avec ce même patch mais sans abstractions (j'ai tout mis dans le patch principal) et en remplaçant l'objet [tabread4~] par l'objet [tabread~] (qui ajoute un vilain aliasing mais bon) : ça n'a pas changé non plus, le patch saccade à tout va.

Puis finalement, avec un simple patch qui fait tourner une sorte de boite rythme dynamique sur 3 samples (kick, Snare, Hihat, avec l'objet [readsf~]) et là, ça passe, sans problème même car le CPU ne dépasse par les 20%.

Donc, j'ai tendance à penser que soit les limites du Rpi sont très vite atteintes en matière de lecture (de samples) et j'imagine que l'écriture (enregistrement audio) doit subir le même sort, soit je fais une erreur quelque part mais je ne vois pas bien où chercher !

Bref, personne ne s'est heurté à ce problème jusqu'ici ?

Dernière modification par boscovic (2014-11-11 15:21:52)

citation :

J'avoue n'avoir encore jamais fait de projet sonore Puredata/RaspberryPi... Donc, ce n'est pas mon expérience qui va t'aider...

... mais c'est tes idées et je te remercie de les partager autour de ma requête.

Tu as raison, je crois qu'il faut contourner l'option tableau pour tout ce qui est audio, le CPU du Rpi en mourrait !
Du coup, je vais me renseigner sur l'objet [sfread2~] et peut-être aussi sur d'autres librairies externes qui pourraient avoir des objets intéressants dans mon cas pour enregistrer et lire dans cette contrainte.

Je n'ai pas encore de projet arrêté mais j'aurai vraiment besoin de manipuler des "loopers" dans le sens général du terme (enregistrement audio puis manipulation autour de la lecture) et aussi des "samples" (pour développer des claviers, boites à rythmes ou des modules plus singuliers comme des slicers ou du granulaire par exemple).

Au niveau de la polyphonie, je ne peux contourner l'affaire "manuellement" car il me faudrait 1 wav accordé pour chaque note du clavier et encore, ça couperait le son du .wav à chaque rappel. L'intérêt de la polyphonie étant de charger un seul sample, de l'accorder "dynamiquement" sur chaque touche mais surtout de pouvoir appuyer plusieurs fois (jusqu'à 16 ici) sur la même touche sans couper pour autant la tenue du son en cours...

citation :

mais il faut la compiler. Je l'ai pour ma Ubuntu 32bit... mais pas pour ARM... désolé...

Ah, j'ai toujours bossé sur Mac uniquement avec Pd Extended et je n'ai quasiment aucune connaissance en Linux : certains objets externes ne sont pas compatibles entres les différents OS ? (il faut qu'ils soient compatibles Raspbian ?)

citation :

u peux très bien imaginer une abstraction pour chaque "touche" contenant X fois une autre abstraction/ [readsf~] qui permettrait d'appuyer X fois successivement sur la même "touche" sans que le son en cours soit coupé...

Oui, c'est vrai qu'une abstraction du genre ferait tout à fait l'affaire, un peu long à préparer mais c'est une solution.
Merci pour la piste [samplebox~ ], je vais prendre le temps de regarder si ça passe, de tester tout ça.
Ok pour les objets compilés, merci pour l'info.