[Pdmtl] Analyse audio en C?

[Mathieu Bouchard]

On Wed, 20 May 2009, Alexandre Quessy wrote:

> Qu'est-ce qu'il y a de si terrible à vouloir changer de solution
> technologique

Ce n'est pas un problème. D'après moi, le problème est de mal s'expliquer, 
c'est tout. J'essaie de découvrir tes vraies raisons, puisque tu as cru 
bon d'en parler et que ton opinion a de la valeur ici (et pas dans le sens 
de «c'est ben d'valeur»!!!).

> pour créer des logiciels "stand-alone" qui ne soient pas dépendants d'un 
> autre logiciel,

Si tu veux faire un logiciel standalone, tu n'as qu'à prendre un ensemble 
de logiciels et l'appeler: 1 logiciel. Il n'y a aucune ligne de 
démarcation claire permettant de dire que l'on a entre nos mains un 
logiciel, deux logiciels, 42 logiciels, etc.; on pourrait 
vraisemblablement dire que chaque externe de Pd est un logiciel, tout 
comme chaque combinaison de patches, d'externes et de Pd donne 1 logiciel. 
Peut-être devrait-on alors dire que l'on a "du" logiciel, comme on a de 
l'eau et du temps.

D'ailleurs, c'est typique des programmeurs C/C++ de s'imaginer qu'ils ont 
des applications «standalone» même s'ils se lient dynamiquement avec 
libc.so, libasound.so, libjpeg.so, etc.

Et si je comprends bien, le noyau du système d'opération ne compte pas 
comme étant un logiciel?

Je n'essaie pas de faire des jeux de mots là...

> qui lui est un logiciel de programmation graphique pour le son ? Pure 
> Data et Max/MSP m'ont aidé à apprendre les bases du son, de l'image et 
> de l'électronique... mais dois-je me limiter à ces outils pour tous les 
> projets que je ferai pour les X années à venir ? Je ne crois pas.

Ben étant donné que Pd offre tant de possibilités de changer de langage 
pour écrire des plugins, je ne vois pas en quoi Pd serait tellement une 
limite plutôt qu'un point d'appui.

> Il peut être intéressant, pour des raisons de performance, de 
> portabilité, de simplicité, ou juste pour l'intérêt d'apprendre de 
> nouveaux outils, de choisir un langage texte plutôt que graphique.

Ouais, mais je pense pas que la limite se situe entre le texte et le 
graphique. D'ailleurs c'est une limite tellement vague que je crois qu'il 
est inutile d'en parler. C'est plus utile de parler de flot de données vs 
les autres possibilités d'expression, ou de diagrammes de flot de données 
vs les autres possibilités d'expression, mais il y a assez de manières de 
faire spécifiques à Pd/Max pour que ça vaille la peine de parler de Pd/Max 
vs le reste de l'univers.

> Je trouve qu'il est plus facile d'exprimer ma pensée (un algorithme) de 
> manière juste avec du texte.

C'est pas le fait que ça soit du texte en soi, qui rend les choses plus 
faciles. Sinon tu pourrais écrire des patches .pd dans TextEdit et ça 
serait facile.

Je pense que l'on a pas encore exploré toutes les possibilités de Pd au 
niveau des structures de base de la programmation, et de la résolution de 
problèmes. Je suspecte qu'il y a beaucoup de manières dont on pourrait 
s'exprimer dans Pd et c'est juste parce qu'on n'y a pas été habitué pcq 
personne l'a été, alors que lorsqu'on apprend un autre langage de prog, on 
apprend plus à exprimer n'importe quoi qu'on veut exprimer. Une des 
raisons pour lesquelles je voulais que les gens considèrent Pd comme un 
langage de prog, c'étaient pour qu'ils le comparent à un langage de prog, 
pour que ça donne des idées sur comment combler les lacunes de Pd que les 
autres langages de prog n'ont pas.

> J'aime beaucoup Python ces temps-ci,

C'est pourquoi j'ai mentionné Python quand tu as parlé des callbacks, mais 
franchement, ça s'applique à plein d'autres langages/inteprètes 
similaires.

> mais, à ma connaissance, seul le C ou le C++ offre des performances 
> vraiment optimales pour ce qui touche au son.

Si les règles du jeu sont définies par les programmeurs C/C++, oui. Mais 
si on écarte la portabilité vers autre chose que x86, alors tu peux 
toujours programmer en assembleur et ainsi battre ce que GCC peut 
produire. C'est aussi très possible d'écrire du code C/C++ qui est moins 
performant que ce que tu as déjà dans d'autres langages, pour la simple 
raison qu'il y a des bibliothèques écrites en C/C++ qui ne sont 
disponibles qu'à travers des API d'autres langages et pour lesquelles les 
auteurs ont mis ben du temps à l'optimiser, alors que tu ne mettrais pas 
nécessairement ce temps-là dedans.

Ce qui est souvent plus important que d'optimiser pour le temps CPU, c'est 
d'optimiser pour le temps de programmation. Ça se fait entre autres en 
augmentant les dépendances dans la mesure où les dépendances choisies 
sauvent du temps.

En plus de ça, si tu optimises en fonction de projets réels plutôt que 
d'avoir juste le plus de calcul possible sur un CPU, peut-être qu'alors tu 
vas voir que tu peux couper sur le nombre de canaux, sur la fréquence 
d'échantillonnage, etc. et qu'alors là, tant que le projet rentre dans 
l'ordi (en tant que % d'utilisation de CPU), t'es correct, peu importe 
comment inefficace ton application est.

Mais si tu veux vraiment bourrer un ordi contemporain à pleine capacité de 
calcul, ce n'est pas le C/C++/assembleur qu'il faut utiliser, c'est le 
GLSL.

> Peut-être que d'ici peu on aura une librarie Python pour STK et aubio. 
> D'ici là, je risque de faire mes prototypes avec Pure Data, comme je le 
> fais déjà, et quelques essais en C.

tu as déjà fait des externes Pd DSP ? avec dsp_add, t_signal et tout le 
tralala...

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec