Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Bidouille & Développement Informatique
Agrandir
Bidouille & Développement Informatique
Les Mains dans le Cambouis
Bidouille & Développement Informatique
Actu 1 1
Articles
Médias 33 33
Tutoriels
Forums 326 326

Le pub des programmeurs

  • 1 925 réponses
  • 117 participants
  • 123 188 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
1441
miles, tu as déjà testé les VSTs de Simulanalog?

Ils ont un pack (gratos!) avec une simu de SD1, de tubescreamer, de fender twin, de marshall JCM et de quelques autres pédales, et çà marche très bien!

http://www.simulanalog.org/guitarsuite.htm

Je crois qu'à la base c'est un projet universitaire en traitement du signal, ils ont fait un sacré boulot! J'ai comparé avec les plugins "LePou" que plein de gens considèrent comme les meilleures simulation d'ampli gratos, et ben je préfère largement Simulanalog.

Mais si je comprends bien tu as développé tout un toolkit en Python pour le dev audio?
1442
En fait, c'est basé sur les papiers de simulanalog, mais réécrit depuis 0. Dans leur papier, il n'y a pas qu'une distortion un peu plus simple et pas de discussion sur l'oversampling, même si l'algo d'origine est le même (un Newton Raphson). Je n'ai jamais vu leur code source, donc je ne sais pas quel est l'oversampling qu'ils utilisent. Pour la meilleure qualité, je constate que x32 est ce qu'il y a de meilleur en terme d'alisaing. Il me semble que les LePou utilisent moins, donc sont moins gourmands.

Il faut juste que je finalise mes tests et ma pseudo-skin et ce sera uploadé. Question de jours, j'espère !
Mon toolkit est écrit en C++, mais il y a des wrappers en Python pour mes tests (et pour les graphiques).

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

1443
Citation de miles1981 :
Citation de Zerosquare :
Pour le Fortran, c'est ce que je croyais aussi, mais un pote qui bosse sur des supercalculateurs m'a dit que c'est très utilisé dans le domaine (et pas par "inertie", mais parce qu'apparemment c'est bien adapté aux calculs parallèles).

Je confirme. Enfin presque. Ce n'est pas plus adapte au calcul parallele que les autres langages, c'est juste plus adapte au calcul en general. Fortran est prevu pour faire des calcul sur des tableaux multidimensionnels, il a un avantage sur la gestion des pointeurs par rapport au reste des langages (aliasing interdit) donc potentiellement plus performant. Et comme tous les vieux utilisent Fortran 77, tous les jeunes doivent s'y mettre, sauf qu'eux decident de prendre Fortran 2003 (il existe un 2008, mais aucun compilateur n'existe pour le moment) et ca va etre la grosse merde par la suite.
Aussi, les gars qui font du Fortran sont des mathematiciens formes a Matlab. Ils ne comprennent rien a l'informatique, donc ils prennent avec joie le truc pourri qui date des annees 70 et qui n'est pas trop loin de leur zone de confort.
Le cocktail ideal...


Oui, je suis aigri :p

À ma connaissance ce n'est pas uniquement ça (je connais des gens qui font des calculs de mécanique des fluides sur ordi, et sur différents supercalculateurs). Par exemple sur le supercalculateur Fujitsu de Météo-France, le compilateur livré avec, est optimisé pour utiliser au mieux l'architecture matérielle des CPUs, de l'allocation de la RAM, des bus entre unités de calculs etc... Certains microprocesseurs peuvent faire une multiplication de 2 matrices de nombres réels en 1 cycle, autrement dit : des centaines de multiplications et additions. Mais pour ça il faut :
- que le compilateur soit spécialement conçu pour ce hardware
- qu'il sache identifier des "formes de bloc de programme" qui peuvent s'optimiser à mort
- que le programmeur sache utiliser ces formes, plutôt que d'autres qui semblent équivalentes mais qui sont en réalité infiniment moins efficaces. (je dis peut-être n'importe quoi, mais en exemple pour fixer les idées, si à un moment on utilise un tableau à double entrée T(i,j), il faut d'abord faire la boucle sur i, puis j, sinon même si le résultat du calcul est le même, sa durée explose).

Sur ce supercalculateur et au moment où on en parlait (il y a 10 ans ?), seul le compilateur fortran utilisait à fond la puissance du hardware, le compilateur C l'exploitait à peine, et servait surtout pour "dépanner" et compiler des outils qui ne sont pas très consommateurs en CPU.

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

1444
Effectivement, les compilateurs Fortran ont un avantage, leur âge combiné avec l'absence d'aliasing qui fait que le code intermédiaire est mieux décrit et potentiellement mieux compilé.
En revanche, que ce soit Fortran, C ou C++, le back-end est maintenant commun, donc les routines d'optimisation sont indépendantes. Il faut juste que le compilateur C ou C++ sache annoter correctement, ce qu'il sait faire de mieux en mieux.
+1 sur le fait que le programmeur sache dans quel sens faire ses boucles. Mais c'est pire que cela, il y a pas mal de choses à faire soi-même maintenant, comme le cache blocking... Il y a des bibliothèques C++ qui sont capables de faire ça de manière transparente pour l'utilisateur, donc avantage au langage moderne.
Ensuite, ça marche bien pour les algos qui font des appels à la mémoire de manière contigüe. Quand on passe aux accès aléatoires (plus ou moins tous les algos modernes), cette différence disparaît.

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

1445
Citation de miles1981 :
En revanche, que ce soit Fortran, C ou C++, le back-end est maintenant commun, donc les routines d'optimisation sont indépendantes.

De ce que j'avais compris et sur le Fujitsu en question (ou sur des SGI), le back-end n'était pas commun. Seul le back-end spécifiquement développé par Fujitsu pour cette machine (et uniquement en Fortran) permettait de l'exploiter à fond. Fujitsu aurait pu faire de même pour le C, mais il y avait manifestement tellement peu de clients à faire du calcul scientifique autrement qu'en Fortran, que ça ne valait pas le coup.

Je me souviens aussi de tests à la sortie de processeurs intel, où gcc malgré toutes ses qualités, ne pouvait pas donner d'aussi bonnes performances que le compilateur C intel, et qu'il a fallu pas mal de temps (entre 6 mois et un an), pour rattraper ça.

Donc j'imagine que ce que tu veux dire c'est que les back-end sont les mêmes pour les compilos gnu (et peut-être d'autres aussi), mais de ce que j'ai retenu, il y a d'autres cas, et parfois pour exploiter au maximum un hardware ces compilos ou back-ends ne sont pas égaux.


Par ailleurs, chez Météo-France comme dans beaucoup d'autres sociétés de calcul scientifique (mécanique des fluides...), quand un logiciel est énorme (disons 100 hommes x an) et fait l'essentiel de ce dont on a besoin, ben on continue à développer dans le même langage les petits ajouts de l'année... C'est la life !
(et c'est probablement pareil dans plein d'autres sociétés et pays, sinon Fujitsu aurait aussi développé la version C).

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

[ Dernière édition du message le 12/06/2014 à 00:23:59 ]

1446
Citation de miles1981 :
Il faut juste que je finalise mes tests et ma pseudo-skin et ce sera uploadé. Question de jours, j'espère !


Si t'as besoin d'un coup de main pour ça, c'est peut être possible que je fasse un peu de coloriage:

https://www.gearslutz.com/board/music-computers/733123-sknote-presets-skins.html

http://www.mediafactory.org.au/natalie-herbstreit/files/2014/10/the-end-2gt1jas.jpg

1447
Quelques uns que j'ai fait que je trouve sympa :

329897d1360342694-sknote-presets-skins-funny-test.jpg


313995d1350524238-sknote-presets-skins-captrndcountry.jpg

http://www.mediafactory.org.au/natalie-herbstreit/files/2014/10/the-end-2gt1jas.jpg

[ Dernière édition du message le 12/06/2014 à 00:34:59 ]

1448
Citation de Dr :
De ce que j'avais compris et sur le Fujitsu en question (ou sur des SGI), le back-end n'était pas commun. Seul le back-end spécifiquement développé par Fujitsu pour cette machine (et uniquement en Fortran) permettait de l'exploiter à fond. Fujitsu aurait pu faire de même pour le C, mais il y avait manifestement tellement peu de clients à faire du calcul scientifique autrement qu'en Fortran, que ça ne valait pas le coup.

Je me souviens aussi de tests à la sortie de processeurs intel, où gcc malgré toutes ses qualités, ne pouvait pas donner d'aussi bonnes performances que le compilateur C intel, et qu'il a fallu pas mal de temps (entre 6 mois et un an), pour rattraper ça.

Donc j'imagine que ce que tu veux dire c'est que les back-end sont les mêmes pour les compilos gnu (et peut-être d'autres aussi), mais de ce que j'ai retenu, il y a d'autres cas, et parfois pour exploiter au maximum un hardware ces compilos ou back-ends ne sont pas égaux.


Par ailleurs, chez Météo-France comme dans beaucoup d'autres sociétés de calcul scientifique (mécanique des fluides...), quand un logiciel est énorme (disons 100 hommes x an) et fait l'essentiel de ce dont on a besoin, ben on continue à développer dans le même langage les petits ajouts de l'année... C'est la life !
(et c'est probablement pareil dans plein d'autres sociétés et pays, sinon Fujitsu aurait aussi développé la version C).

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++ ;)

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

1449
Citation de Hohman :
Si t'as besoin d'un coup de main pour ça, c'est peut être possible que je fasse un peu de coloriage:

https://www.gearslutz.com/board/music-computers/733123-sknote-presets-skins.html

Joli, je prends note et je veux bien, oui ! Pour l'instant la branche est juste sur mon Mac, le temps de savoir pourquoi le plugin semble fonctionner avec auval mais pas avec AULab !

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

1450
Par contre il faut que tu saches que je ne connais presque rien en programmation. Je peux juste fournir l'image de fond, les potentiomètres, typo, lumière et ombrage en pseudo 3D pour chaque position d'images et au format/dimensions voulu. Pour le reste je nage, j'ai quelques petites notions 3DS mais c'est beaucoup trop de boulot, c'est cher et je ne sais pas tout faire seul (essentiellement au niveau du code, et je n'ai pas envie de tuer quelqu'un :mdr:...)...
Les images que tu as pu voir représentes environ une demi journée de loisir en remplaçant des images existantes, dans ce cas aucun problème et on peut facilement faire mieux... Si/quand tu penses que c'est bon pour toi, aucun problème pour revenir vers moi.

http://www.mediafactory.org.au/natalie-herbstreit/files/2014/10/the-end-2gt1jas.jpg

[ Dernière édition du message le 12/06/2014 à 01:16:05 ]