Le pub des programmeurs
- 1 925 réponses
- 117 participants
- 123 184 vues
- 130 followers
Anonyme
521410
Sujet de la discussion Posté le 25/08/2005 à 17:21:03Le pub des programmeurs
Salut y a des programeurs sur AF si oui vous bossez sous quoi ?
Dr Pouet
52037
Membre d’honneur
Membre depuis 20 ans
1451 Posté le 12/06/2014 à 01:19:22
@ Hohman : jolis tes skins, félicitations !
En mécanique des fluides, ils ont l'air d'être loin d'en prendre le chemin. Ils utilisent des technos plus récentes (C++, java, openGL...) pour la modélisation du problème, ou pour l'analyse et la représentation des résultats, mais le calcul reste imperturbablement en Fortran.
Moi je bosse sur des gros logiciels opérationnels qui tournent à H24 (contrôle aérien) et effectivement comme tu dis tous les 20/30 ans on change tout. Mais c'est pas tellement un problème de langage, un peu plus un problème de librairies/cots... mais surtout un problème de conception initiale qui a fait son temps, voire qu'on a poussée dans ses toutes dernières extrémités et qui a donné tout ce qu'elle pouvait.
Citation :
Tout à fait. Jusqu'au jour où on se dit que le legacy code, c'est bien mais c'est limite en terme de maintenance et on recommence de 0 en C++
En mécanique des fluides, ils ont l'air d'être loin d'en prendre le chemin. Ils utilisent des technos plus récentes (C++, java, openGL...) pour la modélisation du problème, ou pour l'analyse et la représentation des résultats, mais le calcul reste imperturbablement en Fortran.
Moi je bosse sur des gros logiciels opérationnels qui tournent à H24 (contrôle aérien) et effectivement comme tu dis tous les 20/30 ans on change tout. Mais c'est pas tellement un problème de langage, un peu plus un problème de librairies/cots... mais surtout un problème de conception initiale qui a fait son temps, voire qu'on a poussée dans ses toutes dernières extrémités et qui a donné tout ce qu'elle pouvait.
miles1981
8352
Je poste, donc je suis
Membre depuis 20 ans
1452 Posté le 12/06/2014 à 10:15:29
Hohman > Merci ! C'est très facile à changer (j'utilise la bibliothèque WDL-OL qui vient de Cockos), juste les images là où elles sont + la position des boutons et c'est bon. Je te tiens au jus.
Dr Pouet > T'inquiètes, je travaille actuellement sur l'un des plus gros simulateurs d'écoulement de fluides commercial dans le domaine pétrolier, remplaçant l'ancien simulateur écrit en Fortran (peu souple, c'est en fait 2 simulateurs en 1), 30 personnes environ, et tout est en C++.
+1 sur ton dernier paragraphe, c'est exactement la raison qui a fait que la boîte a lancé ce projet : l'ancien simulateur ne scalait pas. Bon, le souci, c'est que c'est tellement un standard du marché que personne n'a vraiment envie de passer au nouveau, même s'il est bien plus rapide...
Dr Pouet > T'inquiètes, je travaille actuellement sur l'un des plus gros simulateurs d'écoulement de fluides commercial dans le domaine pétrolier, remplaçant l'ancien simulateur écrit en Fortran (peu souple, c'est en fait 2 simulateurs en 1), 30 personnes environ, et tout est en C++.
+1 sur ton dernier paragraphe, c'est exactement la raison qui a fait que la boîte a lancé ce projet : l'ancien simulateur ne scalait pas. Bon, le souci, c'est que c'est tellement un standard du marché que personne n'a vraiment envie de passer au nouveau, même s'il est bien plus rapide...
Audio Toolkit: http://www.audio-tk.com/
obe
408
Posteur·euse AFfamé·e
Membre depuis 20 ans
1453 Posté le 12/06/2014 à 10:51:41
@miles : Tu utilises quoi pour l'anti-aliasing ?
De l'interpolation linéaire ou cubique plus un filtre IIR (pour minimiser la latence mais avec un résultat pas mathematiquement parfait), ou tu remplis avec des zeros puis FIR passe bas ?
J'avais testé les deux en prototypant avec Jesusonic (Reaper-Cockos). A l'oreille il n'y avait pas grande différence par contre sur les graphes la différence était flagrante.
Je trouve ton projet très intéressant. Par contre, je n'arrive pas vraiment à voir comment interagissent wdl-ol, python et QT au sein de ton audio-toolkit (je n'ai pas encore regardé le code).
De l'interpolation linéaire ou cubique plus un filtre IIR (pour minimiser la latence mais avec un résultat pas mathematiquement parfait), ou tu remplis avec des zeros puis FIR passe bas ?
J'avais testé les deux en prototypant avec Jesusonic (Reaper-Cockos). A l'oreille il n'y avait pas grande différence par contre sur les graphes la différence était flagrante.
Je trouve ton projet très intéressant. Par contre, je n'arrive pas vraiment à voir comment interagissent wdl-ol, python et QT au sein de ton audio-toolkit (je n'ai pas encore regardé le code).
[ Dernière édition du message le 12/06/2014 à 10:52:22 ]
miles1981
8352
Je poste, donc je suis
Membre depuis 20 ans
1454 Posté le 12/06/2014 à 11:03:31
J'utilise un filtre IIR pour créer l'interpolation. Je ne me souviens plus sur le coup de l'adresse du papier d'où j'ai récupéré la science, mais grosso modo, c'est un filtre d'ordre 6 (centré, donc il engendre une latence de 3 échantillons ramené à la fréquence d'origine) avec des coefficients bien choisis selon l'oversampling demandé. Après, je passe mon filtre non linéaire, je filtre avec un passe bas classique puis je décime.
Donc il me semble que c'est ni l'un ni l'autre
Qt, j'ai arrêté, trop compliqué à mettre en place, à maintenir... donc je n'utilise plus que WDL-OL pour générer les UI. Et j'ai le support VST3, AU, AAX gratuitement!Dans le coeur du plugin, j'attaque directement la couche C++ de mon toolkit, donc pas de Python. Ce n'est utilisé que pour designer, comparer... C'est ce que j'avais aussi fait pour mon premier plugin d'overdrive (celui-ci utilisant Qt) : http://matt.eifelle.com/2011/05/10/qtvst-how-qtsimpleoverdrive-is-implemented/ Je dois avoir les scripts sur le repository de QtVST sur github au cas où.
Donc il me semble que c'est ni l'un ni l'autre
Qt, j'ai arrêté, trop compliqué à mettre en place, à maintenir... donc je n'utilise plus que WDL-OL pour générer les UI. Et j'ai le support VST3, AU, AAX gratuitement!Dans le coeur du plugin, j'attaque directement la couche C++ de mon toolkit, donc pas de Python. Ce n'est utilisé que pour designer, comparer... C'est ce que j'avais aussi fait pour mon premier plugin d'overdrive (celui-ci utilisant Qt) : http://matt.eifelle.com/2011/05/10/qtvst-how-qtsimpleoverdrive-is-implemented/ Je dois avoir les scripts sur le repository de QtVST sur github au cas où.
Audio Toolkit: http://www.audio-tk.com/
Hohman
4086
Squatteur·euse d’AF
Membre depuis 12 ans
1455 Posté le 12/06/2014 à 11:23:07
miles1981 > Ok, on étudiera en détail tes besoins au moment venu.
obe
408
Posteur·euse AFfamé·e
Membre depuis 20 ans
1456 Posté le 12/06/2014 à 11:24:05
Ok je vois, tu remplaces le FIR passe-bas par un IIR passe-bas d'ordre 6 (!). Je veux bien l'article où sont données les formules pour calculer les coeffs d'un tel filtre.
Du coup, tu n'as pas de problèmes de stabilité avec un filtre d'ordre 6 (parfois on préfère utiliser 3 filtres d'ordre 2) ? De plus la réponse en phase doit être assez bizarre, mais tant que cela ne s'entend pas cela ne pose pas de problème.
Néanmoins, cela me semble une bonne solution pour minimiser les artefacts liés à l'oversampling tout en conservant une latence decente.
OK pour WDL-Ol c'est celui que j'utilise aussi même si je n'ai terminé aucun de mes projets pour l'instant... Juice semble pas mal et surtout plus documenté mais je reste sur WDL-OL car j'aime bien l'état d'esprit des gars de chez Cockos.
J'utilise aussi Python et scipy pour essayer de compendre le DSP avant de coder, puis je passe par une phase de prototypage en JesuSonic , puis ensuite WDL-OL.
A ce propos, je te conseille JesuSonic pour faire rapidement des tests en audio temps-reel. Cela permet de mettre un peu les maths de coté pour se concentrer sur l'audio avant de se lancer dans un code plus structuré dans WDL-OL.
Pour la distortion, j'ai codé en Jesusonic ce qui exposé dans l'article de D. Yeh. Ce n'est pas 100% fini, mais cela doit correspondre en version assez simplifiée à ce que tu implémentes avec la SD1 (équation non linéaire due aux diodes, résolution de l'ODE par la méthode de Newton, gestion basique de l'oversampling).
Ton code va surement pouvoir m'aider à terminer et à ameliorer ce projet.
Du coup, tu n'as pas de problèmes de stabilité avec un filtre d'ordre 6 (parfois on préfère utiliser 3 filtres d'ordre 2) ? De plus la réponse en phase doit être assez bizarre, mais tant que cela ne s'entend pas cela ne pose pas de problème.
Néanmoins, cela me semble une bonne solution pour minimiser les artefacts liés à l'oversampling tout en conservant une latence decente.
OK pour WDL-Ol c'est celui que j'utilise aussi même si je n'ai terminé aucun de mes projets pour l'instant... Juice semble pas mal et surtout plus documenté mais je reste sur WDL-OL car j'aime bien l'état d'esprit des gars de chez Cockos.
J'utilise aussi Python et scipy pour essayer de compendre le DSP avant de coder, puis je passe par une phase de prototypage en JesuSonic , puis ensuite WDL-OL.
A ce propos, je te conseille JesuSonic pour faire rapidement des tests en audio temps-reel. Cela permet de mettre un peu les maths de coté pour se concentrer sur l'audio avant de se lancer dans un code plus structuré dans WDL-OL.
Pour la distortion, j'ai codé en Jesusonic ce qui exposé dans l'article de D. Yeh. Ce n'est pas 100% fini, mais cela doit correspondre en version assez simplifiée à ce que tu implémentes avec la SD1 (équation non linéaire due aux diodes, résolution de l'ODE par la méthode de Newton, gestion basique de l'oversampling).
Ton code va surement pouvoir m'aider à terminer et à ameliorer ce projet.
[ Dernière édition du message le 12/06/2014 à 11:37:57 ]
miles1981
8352
Je poste, donc je suis
Membre depuis 20 ans
1457 Posté le 12/06/2014 à 11:56:00
Hohman > Merci !
obe > En fait, le filtre passe-bas est un Butterworth, en général d'ordre assez élevé, au cas ou le gars a une fréquence d'échantillonnage de 44.1kHz, et que la zone de transition est très faible. Pas de souci de stabilité pour un tel filtre. La phase aussi est très bien pour ces filtres ultra-classiques.
Pour l'implémentation du filtre oversampling -> https://github.com/mbrucher/AudioTK/blob/master/ATK/Tools/OversamplingFilter.cpp
J'ai trop l'habitude de tout coder en C++ ou en Python pour faire autre chose :p Et en plus maintenant que j'ai un pipeline, il me suffit de coder la partie manquante (bon, j'ai un truc de base qui me manque, la gestion de la latence dans le pipeline, ça sera là pour la 1.0.0, mais pas encore maintenant). Pour les filtres IIR ou FIR, il me suffit de coder la génération des coeffs, pour un algo d'optimisation, il suffit de mettre la fonction de coût... Bref, c'est très facile de changer un bloc par un autre. Par ex le module SD1 a commencé par la partie overdrive, petite modification de l'équation, puis les coeffs de l'EQ (un peu plus compliqué puisqu'il ne faut pas se planter sur les signes, simplifier les équations dès que possible...). C'est finalement très incrémental
Ton premier article ressemble effectivement à celui de simulanalog, mais il donne le nombre d'itérations de Newton nécessaires, et ça c'est pas mal. Parce que j'en utilise 3 à 4 fois plus ! Donc j'imagine itérer à une plus grande précision qu'eux. Et sachant que certains transitoires dans la SD1 sont tellement abruptes avec une sinusoïde à 1kHz que l'algo ne converge pas après 10 itérations, je suis interrogatif sur ces valeurs assez faibles...
N'hésite pas à regarder le code, à donner ton avis et à critiquer, il est sous licence BSD précisément pour cette raison
obe > En fait, le filtre passe-bas est un Butterworth, en général d'ordre assez élevé, au cas ou le gars a une fréquence d'échantillonnage de 44.1kHz, et que la zone de transition est très faible. Pas de souci de stabilité pour un tel filtre. La phase aussi est très bien pour ces filtres ultra-classiques.
Pour l'implémentation du filtre oversampling -> https://github.com/mbrucher/AudioTK/blob/master/ATK/Tools/OversamplingFilter.cpp
J'ai trop l'habitude de tout coder en C++ ou en Python pour faire autre chose :p Et en plus maintenant que j'ai un pipeline, il me suffit de coder la partie manquante (bon, j'ai un truc de base qui me manque, la gestion de la latence dans le pipeline, ça sera là pour la 1.0.0, mais pas encore maintenant). Pour les filtres IIR ou FIR, il me suffit de coder la génération des coeffs, pour un algo d'optimisation, il suffit de mettre la fonction de coût... Bref, c'est très facile de changer un bloc par un autre. Par ex le module SD1 a commencé par la partie overdrive, petite modification de l'équation, puis les coeffs de l'EQ (un peu plus compliqué puisqu'il ne faut pas se planter sur les signes, simplifier les équations dès que possible...). C'est finalement très incrémental
Ton premier article ressemble effectivement à celui de simulanalog, mais il donne le nombre d'itérations de Newton nécessaires, et ça c'est pas mal. Parce que j'en utilise 3 à 4 fois plus ! Donc j'imagine itérer à une plus grande précision qu'eux. Et sachant que certains transitoires dans la SD1 sont tellement abruptes avec une sinusoïde à 1kHz que l'algo ne converge pas après 10 itérations, je suis interrogatif sur ces valeurs assez faibles...
N'hésite pas à regarder le code, à donner ton avis et à critiquer, il est sous licence BSD précisément pour cette raison
Audio Toolkit: http://www.audio-tk.com/
miles1981
8352
Je poste, donc je suis
Membre depuis 20 ans
1458 Posté le 12/06/2014 à 12:05:24
L'article pour l'oversampling : http://yehar.com/blog/wp-content/uploads/2009/08/deip.pdf
Audio Toolkit: http://www.audio-tk.com/
obe
408
Posteur·euse AFfamé·e
Membre depuis 20 ans
1459 Posté le 12/06/2014 à 12:17:53
Merci pour toutes ces infos et articles ! Cela me donne vraiment envie de m'y remettre !
miles1981
8352
Je poste, donc je suis
Membre depuis 20 ans
1460 Posté le 12/06/2014 à 12:29:22
Citation de obe :
Merci pour toutes ces infos et articles ! Cela me donne vraiment envie de m'y remettre !
Ca donne envie de s'y mettre quand on est plusieurs passionnes
Audio Toolkit: http://www.audio-tk.com/
- < Liste des sujets
- Charte