La page wikipedia est pas mal (la petite animation) :

http://fr.wikipedia.org/wiki/Produit_de_convolution

Ce que tu veux faire c'est une convolution discrète.

Sinon pour implémenter une convolution y'a deux approches, le domaine temporel où tu bosse avec le son "normal" et le domaine fréquentiel ou tu fais des transformées de Fourier.

Ce qu'il faut savoir c'est que si t'as deux sons f et g, la transoformée de Fourier des deux sons convolué : F{ f * g } est égal à la multiplication des transformées de Fourier des deux sons F{ f * g } = F{ f } F{ g }. Ensuite faut faire une transformée inverse sur le résultat pour obtenir le son convolué.

Si tu regarde la définition de la convolution t'as une somme de moins l'infini à plus l'infini. Pas commode. Alors que pour la transformée de Fourier t'as un algorythme très efficace (FFT). Cela dit c'est pas très clair qu'elle méthode est la meilleure. Dans pure data y'a des fft, pour le domaine temporelle je crois pas que ce soit possible de le faire (faut avoir accès chaque échantillon).

Je sais pas quel est ton niveau là dessus, hésite pas si jamais...

Dernière modification par Staross (2008-06-25 22:18:15)

Salut,

J'espère que cette discussion intéressera encore du monde, mais les réverbs à convolution c'est tellement cool ...
J'ai récemment essayé de m'y coller, et là je suis en train de me perdre dans la lecture de diverses pages wikipedia sur les filtres numériques et les mathématiques complexes, sujets que je suis loin de maîtriser.

Quelqu'un a récemment posté ce patch de simple convolution de deux signaux temps-réel sur pdpatchrepo :
http://forum.pdpatchrepo.info/topic/907 … volution/2
Ça marche impeccable, mais ça n'est pas adapté pour faire une réverb à convolution qui combinerait un signal temps-réel avec un fichier impulse response stocké dans une table (ça semble plus compliqué que ça).

Je suis par ailleurs en train d'étudier ce vieux papier de Bill Gardner du MIT Media Lab :
http://alumni.media.mit.edu/~adamb/docs … nPaper.pdf
Bien qu'il date d'une ère antédiluvienne, il semble toujours être une bonne base à partir de laquelle plusieurs personnes sont arrivées à des résultats concrets, et décrit la technique encore utilisée à notre époque.

Je me demande si ce principe pourrait être reproduit avec un patch pure data et des objets natifs, ou s'il faudrait écrire un external comme il en existe dans la librairie HISS Tools pour Max/MSP : http://thehiss.org/
Dans un cas comme dans l'autre, si certains d'entre vous sont intéressés, on peut essayer d'y travailler ensemble.
Je n'ai jamais programmé d'objets pure data utilisant fftw, mais je pense que c'est jouable, par exemple en allant piocher dans les sources de la vanilla.

Sinon les sources des HISS Tools sont dispo sur github : https://github.com/HISSTools/HISSTools_ … se_Toolbox
Je pense qu'il y a largement moyen de s'en inspirer. D'ailleurs je pense que c'est la prochaine piste que je vais suivre, en espérant qu'elle mène quelque part (je n'avais pas vu que les sources étaient disponibles )

Idéalement j'aimerais comprendre ce que je fais donc si vous avez des explications, sur le fonctionnement d'une convolution dans le domaine temporel par exemple, ça m'intéresse beaucoup.

A vous lire,
Joseph

Salut Rep !

D'après le peu que j'ai compris pour l'instant, la difficulté vient de la taille conséquente du fichier d'impulse response qui caractérise un espace acoustique réverbéré (le coup de pistolet ou impulsion de dirac enregistré dans une église par exemple).

Vu que les fft se font sur des petits paquets de signal si on veut garder une latence acceptable pour le temps-réel, il faut découper l'impulse response (simple fichier wav en fait) en petits paquets, et faire une sorte d'application en "cascade" de la convolution des spectres de ces paquets successifs sur le même paquet de signal entrant (avec des délais donc), en parallèle avec les nouveaux paquets de signal entrant qui doivent subir le même traitement au fur et à mesure.
Désolé j'essaie d'être aussi clair que ça l'est pour mes pauvres neurones ...

L'article que je cite dans mon précédent post décrit assez bien le principe : ça consiste à découper le fichier d'impulse en paquets de tailles croissantes (puisque plus on est tard dans la queue de reverb, plus on peut se permettre de calculer le résultat avec de la latence, et en plus ça permet aussi de réduire la charge processeur totale). Le truc est de calculer la convolution du premier paquet d'impulse dans le domaine temporel, avec un "direct form filter" (dixit l'article) pour garder une très faible latence, et les suivantes avec fftw.
Après il y a aussi des astuces de scheduling des calculs de convolution pour optimiser la demande processeur et avoir quelque chose de constant plutôt que des pics de demandes de ressources.
Bref, un beau bouzin tout ça

Comme je disais, je pense zieuter du côté des sources des HISS Tools pour commencer, parce qu'ils contiennent notamment un objet dont je ne me rappelle plus le nom mais qui fait ça à la perfection (en tout cas le résultat sonore est parfait).
Je vous tiendrai au courant des avancées, mais je serais aussi ravi de continuer cette discussion ici jusqu'à ce que le principe soit mieux explicité pour tout le monde.

++
Joseph
--
http://www.josephlarralde.fr

citation :

Depuis j'imagine que des routines de modélisation physiques ont dues être incluses dans les DSP non ?

C'est bien possible
Là j'essayais de comprendre le principe depuis la base ... ça c'est mon grand défaut d'essayer de réinventer la roue avant d'avoir bien cherché la librairie qui le fait déjà.
Sinon l'article est certes vieux, mais des gars qui font des trucs qui marchent (genre ça : https://www.youtube.com/watch?v=0Ebnue1a4vc) continuent à le citer comme référence.
Peut-être que je ne cherche pas au bon endroit ceci dit, m'en vais continuer à fouiller du côté de la modélisation physique. En plus si c'est procédural c'est plus flexible (donc mieux, plus de paramètres avec lesquels jouer en live)
En tout cas c'est sûr que ça existe mais de là à ce que ça soit open-source ...
Si quelqu'un connaît une bonne librairie je suis tout ouïe !

Yop,

perso j'utilise un external de convolution partitionnée pour ce genre d'application, plus précisément [bsaylor/partconv~] de Ben Saylor : http://puredata.info/search?Creator=ben … er=reverse .

Nau

et aussi le travail de Pierre Guillot
https://github.com/CICM/CreamLibrary/tr … er/Caramel