Sujet Commentaires sur la news : Overloud présente Fluid Convolution
- 9 réponses
- 6 participants
- 711 vues
- 5 followers
Neo Alchemist
7297
Administrateur·trice du site
Membre depuis 3 ans
Lire la news
Ce thread a été créé automatiquement suite à la publication d'une news pour ce produit. N'hésitez pas à poster vos commentaires ici !
berboucha5
52
Posteur·euse AFfranchi·e
Membre depuis 17 ans
Mais c’est une bonne bonne nouvelle 
Wolfen
13834
Rédacteur·trice
Membre depuis 22 ans
Je viens de mettre a jour un de mes algos de convolution (j’ai remplacé un + par un - et j’ai finalement remis le +), je vais de ce pas déposer a l’INPI le terme viscous convolution, parce que ca « colle » plus à la réalité, et je mettrai les mots clés last generation et game changing dans la description
Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape
[ Dernière édition du message le 07/02/2021 à 10:00:23 ]
Anonyme
Workinghour
254
Posteur·euse AFfamé·e
Membre depuis 21 ans
Anonyme
Wolfen
13834
Rédacteur·trice
Membre depuis 22 ans
Je lis la news en anglais :
Même avec les termes techniques, y a toujours du bullshit là
Bon déjà, l'oversampling n'est la plupart du temps pas utilisé sur la totalité du traitement des simulateurs d'amplis, notamment parce que la partie cab est souvent faite avec juste de la convolution (donc linéaire donc ne génère pas d'aliasing, donc pas besoin d'oversampling), donc y a pas besoin de resampler les IRs dans ce cas précis. Quand bien même, le resampling des IRs (par exemple si elle est stockée en 96 kHz et que le traitement audio est en 44.1 kHz, ou l'inverse) ne se fait jamais pendant le traitement, il se fait une seule fois au chargement de l'IR et après le surcoût lié au resampling n'existe pas.
Et histoire d'aller plus vite, qu'est-ce qu'on fait dans ce cas après chargement ? On stocke le résultat dans le domaine fréquentiel pour économiser des FFTs et autres pendant le traitement. Et si le logiciel utilise sa propre libraire de simulations d'enceintes (donc ne dépend pas des IRs au format wav qu'on voit aussi), il paraît évident que c'est plus sympa de stocker les résultats de tous ces calculs directement dans la librairie pour ne jamais avoir à les faire à l'utilisation. Tout le monde fait déjà plus ou moins ça à priori vu que c'est parfaitement logique. Donc je ne comprends pas trop pourquoi ils présentent ça comme une innovation (la première fois que j'ai fait ça personnellement en tant que débutant en DSP c'était en 2006).
De plus ça règle pas non plus le souci du resampling. Si tu as une IR stockée dans le domaine fréquentiel en 44.1 kHz, l'opération qui permet d'arriver au même résultat sans perte de qualité en 96 kHz n'est pas triviale, et pas plus ou moins rapide ou précise que faire la même chose avant la conversion en fréquentiel. Après là on peut imaginer qu'ils ont codé un algorithme qui le fait et dont ils sont contents, ok mais faut bien faire la conversion une fois au chargement aussi, et donc là aussi je vois pas ce qu'il y a de si intéressant à en parler comme ça
Enfin ils parlent des transitions au changement d'IR. Là aussi, les développeurs de plug-ins de réverb à convolution les ont pas attendus. Un problème récurrent avec les moteurs de convolution c'est de décider quoi faire au changement d'IR. Le plus simple c'est d'avoir un deuxième moteur dont on se sert uniquement pendant les transitions, et on fait un fade out sur le premier et un fade-in sur le second au changement. Ça marche plutôt bien dans le sens où on peut avoir facilement un rendu sans artefacts quand c'est bien fait. Mais cette approche a deux soucis : pendant la transition le CPU double (uniquement pendant les fades), et c'est recommandé seulement sur des IRs courtes, pour que le premier problème ne dure pas longtemps, ce qui a pour effet de supprimer la queue de réverb de la première IR. C'est donc une approche non recommandée sur les réverbs et les IRs de une seconde et plus par exemple. C'est pour ça que depuis les années 2000, il existe des articles qui montrent comment on peut intégrer la seconde IR directement dans les pré-calculs effectués du moteur numéro 1, ce qui permet de ne pas avoir à faire de fade, et de garder la queue de réverb de l'IR précédente jusqu'au dernier moment où on en a besoin. Je peux vous trouver plusieurs discussions qui parlent de ça sur les forums ou des articles datés d'avant 2010
Autant c'est bien que tous ces éléments ultra connus soient intégrés dans leur techno à Overloud (qui d'habitude me semble-t-il ne fait pas ce genre de bullshit marketing), autant je trouve ça complètement naze d'en parler de cette manière, en inventant un terme technique pour des procédés que tout le monde utilisait déjà avant eux (par exemple Altiverb depuis ses débuts)
Citation :
Convolution is the mathematical process used to apply an IR to an audio stream.
Fluid Convolution allows us to remove the digital artifacts of conventional IR processing, seamlessly switch between different IRs, and also do this with a lower CPU impact.
When the recorded audio sample rate differs from the IR sample rate, conventional convolution requires resampling of the audio in order to match the two sample rates. This is particularly true when oversampling is used, like in many guitar processors. This leads to an increased CPU load and some audio degradation due to the resampling process.
With the Fluid Convolution we store the IRs in the complex frequency domain, so no resample is needed. The results are a more natural feel and a lower CPU impact.
The transition between IRs also happens seamlessly: when changing IRs or tweaking cabinet parameters, traditional audio engines typically jump between different impulses according to the new settings. With Fluid Convolution, everything will happen smoothly, with no gaps or artifacts, and with a new level of realism.
Même avec les termes techniques, y a toujours du bullshit là
Bon déjà, l'oversampling n'est la plupart du temps pas utilisé sur la totalité du traitement des simulateurs d'amplis, notamment parce que la partie cab est souvent faite avec juste de la convolution (donc linéaire donc ne génère pas d'aliasing, donc pas besoin d'oversampling), donc y a pas besoin de resampler les IRs dans ce cas précis. Quand bien même, le resampling des IRs (par exemple si elle est stockée en 96 kHz et que le traitement audio est en 44.1 kHz, ou l'inverse) ne se fait jamais pendant le traitement, il se fait une seule fois au chargement de l'IR et après le surcoût lié au resampling n'existe pas.
Et histoire d'aller plus vite, qu'est-ce qu'on fait dans ce cas après chargement ? On stocke le résultat dans le domaine fréquentiel pour économiser des FFTs et autres pendant le traitement. Et si le logiciel utilise sa propre libraire de simulations d'enceintes (donc ne dépend pas des IRs au format wav qu'on voit aussi), il paraît évident que c'est plus sympa de stocker les résultats de tous ces calculs directement dans la librairie pour ne jamais avoir à les faire à l'utilisation. Tout le monde fait déjà plus ou moins ça à priori vu que c'est parfaitement logique. Donc je ne comprends pas trop pourquoi ils présentent ça comme une innovation (la première fois que j'ai fait ça personnellement en tant que débutant en DSP c'était en 2006).
De plus ça règle pas non plus le souci du resampling. Si tu as une IR stockée dans le domaine fréquentiel en 44.1 kHz, l'opération qui permet d'arriver au même résultat sans perte de qualité en 96 kHz n'est pas triviale, et pas plus ou moins rapide ou précise que faire la même chose avant la conversion en fréquentiel. Après là on peut imaginer qu'ils ont codé un algorithme qui le fait et dont ils sont contents, ok mais faut bien faire la conversion une fois au chargement aussi, et donc là aussi je vois pas ce qu'il y a de si intéressant à en parler comme ça
Enfin ils parlent des transitions au changement d'IR. Là aussi, les développeurs de plug-ins de réverb à convolution les ont pas attendus. Un problème récurrent avec les moteurs de convolution c'est de décider quoi faire au changement d'IR. Le plus simple c'est d'avoir un deuxième moteur dont on se sert uniquement pendant les transitions, et on fait un fade out sur le premier et un fade-in sur le second au changement. Ça marche plutôt bien dans le sens où on peut avoir facilement un rendu sans artefacts quand c'est bien fait. Mais cette approche a deux soucis : pendant la transition le CPU double (uniquement pendant les fades), et c'est recommandé seulement sur des IRs courtes, pour que le premier problème ne dure pas longtemps, ce qui a pour effet de supprimer la queue de réverb de la première IR. C'est donc une approche non recommandée sur les réverbs et les IRs de une seconde et plus par exemple. C'est pour ça que depuis les années 2000, il existe des articles qui montrent comment on peut intégrer la seconde IR directement dans les pré-calculs effectués du moteur numéro 1, ce qui permet de ne pas avoir à faire de fade, et de garder la queue de réverb de l'IR précédente jusqu'au dernier moment où on en a besoin. Je peux vous trouver plusieurs discussions qui parlent de ça sur les forums ou des articles datés d'avant 2010
Autant c'est bien que tous ces éléments ultra connus soient intégrés dans leur techno à Overloud (qui d'habitude me semble-t-il ne fait pas ce genre de bullshit marketing), autant je trouve ça complètement naze d'en parler de cette manière, en inventant un terme technique pour des procédés que tout le monde utilisait déjà avant eux (par exemple Altiverb depuis ses débuts)
Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape
[ Dernière édition du message le 08/02/2021 à 10:36:40 ]
Anonyme
Anonyme
Wolfen
13834
Rédacteur·trice
Membre depuis 22 ans
- < Liste des sujets
- Charte