Audiofanzine a 25 ans !
Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
FR
EN
Notifications
  • Refonte graphique octobre 2025
    Refonte graphique octobre 2025
    Une refonte graphique vient d'être mise en ligne. Nous espérons qu'elle vous plaira. Merci de nous signaler tout bug ou perte de fonctionnalité ici →
  • Un cadeau d'UVI pour les 25 ans d'Audiofanzine
    Un cadeau d'UVI pour les 25 ans d'Audiofanzine
    Pour célébrer notre quart de siècle, UVI se joint à nous et vous offre le Digital Synsations Vol.1. Pour en profiter c'est par ici 👉
  • Nouveauté : Bookmark article, news ou tuto
    Nouveauté : Bookmark article, news ou tuto
    Bookmarkez un article, une news ou un tuto et retrouvez-le dans votre section "Mes signets" du menu membre.
  • 6 nouveaux annuaires
    6 nouveaux annuaires
    Luthiers, Réparateurs, Cours de musique, Studios d’enregistrement, de mastering et de répétition... Suggérez l’ajout d’une entreprise, inscrivez la vôtre ou déposez un avis.
  • Alertes disponibilité et baisse de prix
    Alertes disponibilité et baisse de prix
    Ces nouvelles fonctionnalités vous permettent d'être informé·e dès qu'un produit est disponible ou que son prix a baissé.
  • Tentatives d'arnaque dans les petites annonces
    Nous faisons face depuis quelques mois à une recrudescence de tentatives d'arnaques dans les petites annonces. Suivez nos recommandations >
Bidouille & Développement Informatique
News
Articles
Médias
Forums
Tutoriels

Le pub des programmeurs

  • 1 927 réponses
  • 117 participants
  • 131 695 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
551
ZieQ : les FILE* ont une API, et d'après les écrits de Sutter et autres, les fonctions fpon et autres font bien partie de la classe FILE, sans aucun doute.

Gabou, tu es quand même un peu paradoxal, tu parle de refactoring, mais l'héritage, c'est pas trop pour toi alors que c'est l'une des bases du refactoring pour éviter la réécriture du code, donc bon :| Quand on lit les 2 ouvrages de référence à ce sujet, c'est clair.
De plus, les templates, c'est super pratique pour changer une stratégie efficacement, il est vrai que le C++ ne considère pas les classes comme des objets, et le Python fait cela de manière dynamique, et c'est pas plus mal ;)

Enfin, pour les détracteur de Qt, discutez d'abord avec le créateur du C++, s'il l'utilise pour enseigner à ses étudiants, c'est peut-être pas tant batard que ça, vous ne trouvez pas ?

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

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

552
Ah oui, Java, c'est pas trop le top pour moi, je suis à la limite de ce qui est acceptable en consommation mémoire - 2.2G -, donc passer par un langage avec GC, ça me paraît risqué.
Mais je vais tenter un mini projet en Python, ça me permettra de me faire la main et de tester Python, je l'ai promis depuis si longtemps à Gabou :D

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

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

553

Citation :
Gabou, tu es quand même un peu paradoxal, tu parle de refactoring, mais l'héritage, c'est pas trop pour toi alors que c'est l'une des bases du refactoring pour éviter la réécriture du code, donc bon



C'est une base du refactoring en langage a typage statique peut etre, mais dans des langages dynamiques (le contexte dans lequel je me placais), l'heritage est pas tres utile. Par exemple, tu utilise peu l'heritage pour heriter d'une interface en python, ca sert a rien, puisque tu n'utilises jamais le type. Si tu veux changer certaines fonctions membres, les mettre dans une autre classe (lors du prototypage par exemple), c'est extremement lourd en C++.

Je sais pas de quel ouvrage de reference tu parles, mais beaucoup d'ouvrages sont ecrits pour le C++ ou le java, et je trouve que ces langages sont vraiment tres pauvres en expressivite pour comprendre les concepts objet. Un debutant, avec le C++, il va bien se prendre la tete avant de faire des functor, des factory et cie. Quand j'ai commence a utiliser python, j'ai vraiment eu une sorte d'illumination sur tous ces aspects.

Template pour changer de strategie, je comprends pas, la, par contre. Par exemple, je trouve pas que la stl tienne ses promesses sur l'independance container/algorithmes: si tu veux tester par exemple du code en utilisant soit des list, soit des vector, il suffit pas de remplacer list<int> par vector<int>. Typiquement, le sort marche pas de la meme maniere, etc... c'est d'une lourdeur, en general, et tres difficile a debugger (t'as plus le code sous les yeux); je garde un tres mauvais souvenir de blitz, par exemple. Certains trucs comme boost::python utilisent a fond les templates, et sont interessants, mais je trouve ca finalement assez anecdotique. Qt utilise assez peu les template, par exemple, et c'est certainement une des raisons pour lesquelles j'apprecie qt.

Perso, je code en C ou pire en C++ vraiment que si j'ai pas le choix, et ca veut dire en general performances. Mais j'evite au maximum, maintenant.
554

Citation :
Ah oui, Java, c'est pas trop le top pour moi, je suis à la limite de ce qui est acceptable en consommation mémoire - 2.2G -, donc passer par un langage avec GC, ça me paraît risqué.



Java consomme plus de memoire, mais je pense pas que ce soit le GC qui soit le probleme, au contraire. Typiquement, ce qui prend vachement de memoire avec une vm evoluee comme celle de java, c'est le JIT compiling. Ce serait interessant de comparer un programme ecrit en java et compile avec gjc, et un programme en C++; j'aurais tendance a penser que le programme compile avec gcj prendrait beaucoup moins d'espace memoire que le meme au dessus d'une vm.

Citation :
Mais je vais tenter un mini projet en Python, ça me permettra de me faire la main et de tester Python, je l'ai promis depuis si longtemps à Gabou :D



Le teste pas pour ton truc a 2 Go, parce que la, c'est clair que c'est pas le top :)
555
Les 2 livres dont je parlent sont :
- Refactoring to Patterns
- Refactoring - Improving the Design of Existing Code

Effectivement plus orienté type statique. Je vois très exactement ce à quoi tu fais référence quand tu parles de l'inutilité du type, c'est en fait de ce manque du C++ que je m'affranchis grâce aux templates, en quelque sorte, sans arriver à al même puissance que Python tout de même.
Par exemple, j'ai défini une classe de sous-matrice qui a la même interface que les matrices usuelles de ma bibliothèque, grâce à quoi tous mes algos fonctionnent rigoureusement de manière identique, sauf que ça me permet de travailler à plusieurs échelles, par exemple - typiquement, une optimisation multi-points où je ne prends successivement qu'une partie des points, alors que par le passé, j'utilisais tous les points -, mais c'est le genre de choses que Python fait naturllement de par sa nature typage dynamique ;)

Pour ce qui est de Qt avec les templates, c'est utilisé, sauf que ce n'est pas possible dans leur hiérarchie QObject à cause de moc, justement, ça entraîne en revanche parfois un peu d'acrobaties dans le cas où on veut utiliser 3 stratégies statiques sans devoir recoder le support de ces stratégies - je me comprend, mais je ne me fais pas comprendre, je crois ;) -

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

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

556

Citation :
Pour ce qui est de Qt avec les templates, c'est utilisé



Oui, bien sur, mais c'est pas base dessus. Ca n'utilise pas les template de maniere intense comme peut le faire gtkmm ou boost.

Apres, l'utilite ou non du typage, j'irais pas non plus jusqu'a dire que c'est inutile. C'est un debat sur lequel bien des personnes plus qualifiees que moi se sont dechire (ML vs LISP, par exemple); python est d'ailleurs fortement type.

La ou je trouve que le typage a la C++ est tres fortement surestime, c'est que ca se place finalement sous le mauvais angle: finalement, ce qui compte plus, c'est le contrat entre classes, et la, on rejoint la philosophie d'eiffel en quelque sort. Il y a discussion en ce moment a propos de python pour rajouter le typage optionnel, et un des points d'achoppement, c'est celui la.

Pour un langage oriente calcul vectoriel, un truc qui a l'air interessant, c'est fortress, je sais pas si t'en as deja entendu parler ?

http://research.sun.com/projects/plrg/

Je pense vraiment que tout ce qui est vm va se developper beaucoup. Ca consomme plus de memoire pour etre performant, mais une fois que le 64 bits va devenir courant, ce sera plus trop un probleme je pense.
557
Non, je ne connais pas cette bête ;)
Le truc, c'est comme on a une plateforme commune entre tous les membres du labo, la politique est C/C++, point final :|
En revanche, c'est certain qu'on ne tournera jamais avec un langage à VM qui bouffe un tant soi peu de mémoire, déjà comme ça on doit faire gaffe - j'ai dû modifier mes algos pour supprimer méchemment à la hache des temporaires parce que je dépassais la mémoire autorisée - et que le swap, c'est pas une option :|

Tout ça pour rerererereredire qu'à chaque application, son langage :)

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

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

558
C'est clair qu'il y a des trucs qui demandent pas mal d'optimisation, et que tu vas pas utiliser un langage sur vm pour certains trucs. Mais en utilisant le C/C++, tu fais deja un compromis. Les fonctions ont un cout en C ou pire eventuellement, en C++; l'objet a un cout meme en C++: la vtable prend de la place. C'est le plus souvent negligeable, mais si tu as des millions d'objets, ca l'est plus forcement, etc...

C'est la que j'etais pas d'accord finalement avec les autres participants de la discussion precedemment. Non pas sur le fait qu'evidemment, il y a des projets ou le C/C++ est clairement adapte; mais plus sur les cas ou c'est reellement adapte.

Le GC a un cout, mais c'est vrai aussi pour malloc (typiquement, le coup ou le gars critiquait mac os x qui etait 40 % plus lent que linux sur le meme code C sur la meme machine pour du code de calcul statistique... ben en fait, c'etait a cause des optimisations differentes de malloc entre les deux OS; le malloc de linux par defaut etant quand meme tres bon en general); etc... Dire que le C est la solution pour la recherche d'optimisations pures, c'est oublier qu'il y a 30 ans, un appel de fonction prenait beaucoup de temps sur un ordinateur. D. Cutler, un des chefs du projet NT au depart chez MS, decrit bien le probleme des developpeurs qui codaient tout en assembleur a l'epoque, et des problemes de mentalite.

En codant en C, on fait deja beaucoup de compromis, un peu plus mais pas beaucoup en C++ (sauf dans certains cas ou ca peut faire mal). ET les compilos ont vachement progresse, rendant l'assembleur le plus souvent inutile par rapport au C... au prix deja de l'occupation memoire; linux, code en C, t'auras pas une interface graphique avec 4 Mo de ram (je crois que linux de base seul, maintenant, en 2.6, refuse de booter avec seulement 4 Mo de Ram). Pourtant, windows 95 tournait sous 4-8 Mo de ram (peniblement).

Quand tu fais du pseudo temps reel pour un plug audio par exemple, tu dis au revoir a tout appel systeme, donc entre autre au syteme de memoire fourni par l'OS, faut le faire a la main de nouveau, etc..

Je pense que les vm, ce sera comme aujourd'hui le C/C++. Necesssaire, indispensable dans certains cas particuliers, mais le reste se fera avec GC ou autre systeme de gestion automatique de memoire, et avec vm. Les gros projets a millions de lignes en C ou en C++, c'est pas l'avenir de l'informatique, je pense.
559
Je profite de ce regroupement d'expert en audio et info pour poser une petite question.

La nouvelle version de windows, nommée Vista, intégre une nouvelle sorte de moteur audio et video. Les données sont notamment traitée avec une plus haute priorité, à un plus haut niveau hiérarchique (?). Est ce que vous pensez que cela va amener des avantage au niveau du traitement audio professionnel (autre que lire un mp3 ou regarder un dvd) ou pas ?



Source : http://www.clubic.com/article-66145-10-microsoft-windows-vista-rtm-dossier.html
560
A la place d'utiliser des drviers ASIO, on utilisera peut-être plus ces drivers là s'ils ont une bonne interface, sinon ça sera comme les WDM, certains logiciels les supporteront, d'autres non, et l'ASIO restera.

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

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

561
Mais le fait que les signaux audios seront traités à un plus au niveau, c'est une bonne chose ou pas ? Est ce qu'on va perdre en vitesse de traitement et gagner en stabilité (comme uns sorte de machine virtuelle ?) ?

Désolé pour ces questions de noobs :oops:
562
Je ne suis pas sûr de comprendre ta question molecule.

Mais plus la prise en charge est bas niveau, mieux c'est à mon avis. :noidea:

Sinon, après avoir lu l'article, hormis la prise en charge native du 32 bits flottants, je ne vois pas en quoi le reste va impacter nos applis MAO...

Affiliation : Dirigeant Fondateur d'Orosys - Two notes Audio Engineering

563

Citation : Mais plus la prise en charge est bas niveau, mieux c'est à mon avis



Reflexion typique du gars qui programme pas et qui laisse cette tache ingrate a ses stagiaires :ptdr:

Site personnel: https://www.enib.fr/~choqueuse/

564
Bah entre s'amuser avec les priorités sous linux ou gérer ça en dur sur DSP, je choisis le DSP. Enfin en tout cas je l'impose à mes stagiaires. :diable:

Affiliation : Dirigeant Fondateur d'Orosys - Two notes Audio Engineering

565
Oui Oui Oui, je te comprend nonconf.. :mrg:

Site personnel: https://www.enib.fr/~choqueuse/

566

Citation : Mais le fait que les signaux audios seront traités à un plus au niveau, c'est une bonne chose ou pas ? Est ce qu'on va perdre en vitesse de traitement et gagner en stabilité (comme uns sorte de machine virtuelle ?) ?


Si c'est comme pour Mac OS X, à savoir que le scheduler de l'OS devient capable de gérer des priorités temps-réel, alors oui c'est un gain important pour l'utilisateur.

Le système est alors capable de donner régulièrement la main à ces applis temps-réel. Il faut éviter d'en avoir plusieurs de lancées en même temps, mais sinon ça rend le séquenceur beaucoup moins sensible aux autres applications tournant en même temps sur la machine.

Par exemple, même si tu as un anti-virus (et même plein d'autres logiciels) qui tourne en tâche de fond, le séquenceur ne sera pas perturbé.

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

567
Le coup de l'anti virus, je pense que c'est quasiment ingerable, car justement ca se fout a un tres bas niveau, en interceptant surement des system calls et cie. Donc t'as un systeme noyau modifie, donc ingerable. C'est comme un mauvais driver: tu peux rien y faire, a part ne pas l'utiliser...

Vista a en effet un bien meilleur systeme audio, au moins en theorie, que les precedentes versions de windows. Du coup, il rattrape les 5 ans de retard sur linux et mac os X a ce niveau la. Le coup du bas niveau plus efficace est pas forcement vrai pour l'audio.

Le premier gros avantage, si le protocole est pas mauvais, c'est qu'il y aura plus le bordel asio et cie sous windows. Comme sous mac os x (core audio) et linux (alsa), il y aura un seul truc sous windows. Toutes les cartes audio auront ce protocole, et ca fera un soucis de moins.

Citation :
ais le fait que les signaux audios seront traités à un plus au niveau, c'est une bonne chose ou pas ? Est ce qu'on va perdre en vitesse de traitement et gagner en stabilité (comme uns sorte de machine virtuelle ?) ?



Deja, bas niveau, haut niveau, c'est pas forcement tres clair. Ce qui se passe avec vista, c'est qu'une grosse partie audio qui etait dans le kernel NT est maintenant mis dans le user space, ce qui rend le truc plus stable, et pas forcement plus lent si c'est bien fait (au contraire).

Apres, la partie non audio de vista: le scheduler de windows est historiquement assez mauvais, et windows est base sur des processus lourds, contrairement aux unix, ce qui fait que la programmation par IPC est assez lourde et peu efficace sous windows. Donc la com interprocessus est peu utilisee (y a rewire qui utilise ca), et seul le multi thread est utilisable sous windows. Et la, le scheduler pour les (kernel) thread est tres tres mauvais, avec une latence moyenne de plusieurs ms, et au pire de 16 ms.

Il y a peu de chances que ca change fondamentalement sous VISTA, le coup des processus. Par contre, le scheduler, ca peut s'ameliorer en effet. Il y a aussi les capacites a avoir un kernel a faible latence, je sais pas ce qu'il en est de windows a ce niveau la.

Un papier pas trop mal qui montre un peu les problemes rencontres sous linux pour en faire un bon OS pour l'audio au niveau latence:

http://lac.zkm.de/2006/papers/lac2006_lee_revell.pdf

Je pense que le meme types de problemes se rencontrent sous windows et mac os X, et donc que ca s'applique assez largement.
568
Sympa le lien Gabou :clin:

De ce que j'ai pu voir de part mon expérience, les temps de développement sur windows avec le format VST+ASIO et sur linux en ALSA sont quasiment identiques, pour des performances tout à fait similaires. :noidea:

Affiliation : Dirigeant Fondateur d'Orosys - Two notes Audio Engineering

569
Tout ce qui est probleme de latence est quand meme nettement mieux gere je trouve. Les developpeurs ont des problemes avec windows vis a vis du scheduling par exemple, ce sont des problemes qui reviennent assez regulierement. C'est quasiment impossible de locker de la memoire en ram, aussi.

Pas mal de problemes de cartes sons, IRQ et cie, certains problemes sont propres a windows, quand meme.

Apres, asio et alsa, pour ce que j'en ai fait, c'est assez kif kif. ALSA est pas fantastique non plus au niveau de l'API (les docs sont horribles; cela dit, j'avais fait un peu d'alsa il y a quelques annees maintenant pour interfacer matlab et ma carte son). VST, le pb numero 1, c'est la sous specification, mais je crois que la, t'es au courant des problemes de VST et des differents hotes qui implementent differement le protocole :)
570
Petite question. J'ai un programme Windows qui utilise pour tout une librairie qui fonctionne sur Windows/Mac/Linux en ayant presque pas à changer le code d'un OS à l'autre. J'aimerais savoir si il existe un moyen de compiler et de tester pour la plateforme Mac sur mon PC Windows :noidea:

Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape | Soundcloud

571
Ca paraît pas gagné mon Wolfinou, à moins d'installer une version hackée d'OSX sur ton portable, avec pas mal de chances de n'avoir qu'une partie de ton matériel reconnue et de gros soucis en perspective... :|

Affiliation : Dirigeant Fondateur d'Orosys - Two notes Audio Engineering

572
Peut-être GNUstep. C'est un environnement de développement compatible Openstep (l'ancêtre de MacOS X). Il permet de développer des applis compatible UNIX/MacOS/Win32. Sous UNIX, c'est assez mature, par contre le portage sous Win32 est encore jeune et nécessite MinGW (un evironnement UNIX pour Windows pour faire très simple :) ).

Coté langage, c'est de Objective-C: si tu connais le C et ou Java, tu devrais t'y retrouver facilement. Plus d'infos ici
573
Bon j'ai compris, je vais installer un environnement C++ sur un Mac et je vais devoir compiler la librairie JUCE dessus, faire quelques tests... Mais bon comme je disais, normalement je ne devrai avoir à faire que des retouches mineures sur le code, vu que 95% des fonctions sont génériques :mrg:

Merci quand même :clin:

Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape | Soundcloud

574

Citation : Bon j'ai compris, je vais installer un environnement C++ sur un Mac


Ca ça ne doit pas être nécessaire.

Sur mon vieux Powerbook G4 :

Citation : 

$ gcc --version

gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1495)

Copyright (C) 2002 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.





$ make --version

GNU Make version 3.79, by Richard Stallman and Roland McGrath.

Built for powerpc-apple-darwin7.0

Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99

        Free Software Foundation, Inc.

This is free software; see the source for copying conditions.

There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A

PARTICULAR PURPOSE.



Report bugs to <bug-make@gnu.org>.



Je me suis jamais trop penché sur la question, mais je crois qu'un environnement Gnu assez classique est systématiquement livré avec OS X (faut juste peut-être installer les outils de développements quand on installe l'OS).

Tu dois facilement en apprendre plus sur le site d'Apple, et sur leurs forums pour développeurs. Sinon avec Google, les infos doivent être facile à trouver.

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

575
OK merci :clin:

Question subsidiaire sinon... A priori, si j'ai pas envie de tester mon programme sur Mac, est-ce que je pourrais quand même le compiler sur une plateforme Windows en dmg ? A priori ça doit être faisable avec un gcc ?

Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape | Soundcloud