Se connecter
Se connecter

ou
Créer un compte

ou
Agrandir
Les Mains dans le Cambouis
Bidouille & Développement Informatique

Le pub des programmeurs

  • 1 925 réponses
  • 117 participants
  • 123 184 vues
  • 130 followers
Sujet de la discussion Le pub des programmeurs
Salut :coucou: y a des programeurs sur AF si oui vous bossez sous quoi ?
Afficher le sujet de la discussion
1451
@ Hohman : jolis tes skins, félicitations !


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.
1452
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...
1453
@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).

[ Dernière édition du message le 12/06/2014 à 10:52:22 ]

1454
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ù.
1455
miles1981 > Ok, on étudiera en détail tes besoins au moment venu. ;)
1456
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.

[ Dernière édition du message le 12/06/2014 à 11:37:57 ]

1457
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 ;)
1458
1459
Merci pour toutes ces infos et articles ! Cela me donne vraiment envie de m'y remettre !
1460
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 ;)