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 675 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
1626
Citation de Patrick :
Teum > ha dans ce cas tu as besoin de code d'interruption. Comme leur nom l'indique ce sont des petites portions de codes qui se déclenches à la venue d'un événement (elles ne sont pas dans le programme principal et interrompent ce dernier à la venue de l'événement) je sais pas comment c'est géré en Arduino mais ça se fait sans aucun doute ;)


Je n'ai jamais mis en oeuvre (sinon sur Amiga il y a trèèèèès longtemps), mais c'est abordé dans la seconde partie des liens donnés par Jimbass :
https://learn.adafruit.com/multi-tasking-the-arduino-part-2/interrupt-etiquette?view=all
On trouve pas mal de code Arduino utilisant ce principe, pour du MIDI notamment.
https://cs.gmu.edu/~sean/projects/gizmo/

« What is full of redundancy or formula is predictably boring. What is free of all structure or discipline is randomly boring. In between lies art. » (Wendy Carlos)

1627
Par contre la programmation multitâche est super casse-gueule. Énormément de développeurs ne s'en rendent pas compte, se lancent la fleur au fusil dans un truc délicat, et à la fin on a un plat de spaghettis indémerdable et bon pour la poubelle.

Le plus gros problème est le "race condition", mais dans un gros logiciel le "dead lock" n'est pas mal non plus. Et plein d'autres possibilités de naufrage aussi.

Voir déjà :
https://en.wikipedia.org/wiki/Race_condition#Example

Et en l'occurrence, les interruptions sont une deuxième tâche déclenchée n'importe où au milieu de la tâche courante.

Take care, comme on dit ! :-D

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

[ Dernière édition du message le 07/03/2017 à 12:44:36 ]

1628
La notion d'I/O et d'asynchronisme sont venues avec les langages au niveaux qui font des requêtes de temps d'exécution inconnu (et souvent lent) avec, par exemple, les mots clefs async et await du C#...
... Et effectivement ça devient un gros plat de spaghetti parce les mécanismes sous-jacents sont mal connus de certains softeux. (mais c'est quand même génial : Plus besoin de gérer explicitement la sauvegarde de contexte, de table d'exception, etc.).

Je ne connais pas Arduino mais vu le concept hardware du bidule je serais très surpris qu'il n'y ait pas des lib déjà toute prêtes et bien documentée pour gérer les interruptions et les prioriser.

[ Dernière édition du message le 07/03/2017 à 14:34:02 ]

1629
pourquoi passer par arduino et pas par le processeur directement ? ca reste an proc. 8bit de chez Atmel. Pour la comprenette c'est mieux car ensuite le fonctionement est quasi-similaire sur les autres proc et il y aura moins de difficultés a migrer vers autre chose. (après reste le cout de chez fichu programmeur).

rumorofsmoke.github.io/

[ Dernière édition du message le 07/03/2017 à 21:54:38 ]

1630
man 2 select
1631
:-D

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

1632
Sinon, la bible :

4158Y9604PL.jpg

"Le" Stevens.
On le voit même dans Wayne's World 2, c'est dire.

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

1633
Citation de EraTom :
les langages au niveaux

Sous-entendrais-tu que ceux qui sont proches du hardware n'ont pas le niveau ? :oops2:

Citation de redpill :
pourquoi passer par arduino et pas par le processeur directement ?

Tu parles de la carte ou de l'environnement de programmation ?
- Pour la carte, c'est sans doute pour une question d'IO. Sur un PC moderne, point de port série ou de port parallèle avec lequel on peut bidouiller. Avec un microcontrôleur, tu fais tes routines d'interruption en fonction de ce que tu branches sur les IO sans devoir passer des couches et des couches de logiciel système.
- Pour l'environnement, bah c'est surtout le bootloader qui est pratique, le reste c'est du C avec une chaîne de cross-compil GNU et quelques librairies qui facilitent les IO. Rien n'impose de se limiter à ca.

Citation de tropdeg' :
man 2 select

Oui, quand on a un OS Posix. C'est rarement le cas sur un microcontrôleur.

Musikmesser 2013 - Bullshit Gourous - Tocxic Instruments - festivals Foud'Rock, Metal Sphère et la Tour met les Watts

1634
x
Hors sujet :
Ah oui, elle n'est pas mal celle-là...
1635
Tiens je me posais une question il n'y a pas longtemps avec un pote : Qu'est ce qui serait le plus performant entre un FPGA et un GPU ? (en prenant un truc qui soit facilement adaptable sur les deux types d'architectures comme des FFT par exemple) sur des critères genre la rapidité par opération par exemple (je ne sais pas si c'est très clair dit comme ça) il y a des gens qui ont une idée ?
1636
Le GPU sera plus rapide, l'avantage du FPGA, c'est le fait qu'il peut être reconfiguré pour un algorithme particulier. Mais en fin de compte, on utilise des FPGA pour concevoir les GPUs "lents", les débugger avant d'en faire des ASIC. Donc pour qqch qui est déployable sur les 2 plateformes, le GPU aura en général l'avantage.
Maintenant, pour des algos qui ne sont pas parallèles, le FPGA aura un avantage car on peut designer directement par exemple un Newton Raphson et non pas l'émuler comme sur un GPU.

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

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

1637
Je suppose que ça dépend d'une part des puces comparées, et d'autre part du programme qu'on fait tourner dessus.

Au taf des collègues bossent pas mal avec des GPUs : le gros avantage c'est la parallélisation (1 GPU = des centaines, voir des milliers de petits coeurs tournant en parallèle), le gros inconvénient c'est que c'est assez compliqué à programmer et à optimiser du coup : découpage des algos en petites tâches, gestion du parallélisme (synchro, priorités ...) et gestion des transferts de données entre les mémoires respectives du CPU et des GPUs ...

Donc en gros un GPU va permettre des gains de perfs uniquement si le programme se prête à cette approche particulière.

Je ne connais pas les FPGA (au delà du principe dans les grandes lignes) mais je suppose qu'on pourrait probablement en dire autant (?)

Donc à partir de là, les comparaisons générales de perfs entre des matos aussi différents n'ont pas beaucoup de sens car ça dépend de ce qu'on fait tourner dessus.

Comme je dis toujours : en informatique, tout dépend du contexte, il n'y a pas de bonnes ou de mauvaises solutions dans l'absolu, seulement des solutions plus ou moins adaptées à un problème donné.

DubSide

[ Dernière édition du message le 18/03/2017 à 13:55:17 ]

1638
Citation :
Donc à partir de là, les comparaisons générales de perfs entre des matos aussi différents n'ont pas beaucoup de sens car ça dépend de ce qu'on fait tourner dessus.

Complètement. Et d'ailleurs j'aurais plutôt dit que sur des opérations simples on ira plus vite avec un FPGA, cf les test AF de l'interface Antelope Audio.

Dans le cas d'un FPGA on va "dessiner" (désormais par blocs) un circuit, tandis qu'avec un GPU on écrit du code, ce qui sera plus laborieux pour des opérations simples (et évidemment beaucoup plus "faisable" pour des opérations complexes).

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

1639
Ca dépend énormément des algorithmes qu'on fait avec, et les critères de choix sont complexes : type de parallélisation, localité de chaque traitement (nombre d'IO ou d'accès mémoire par calcul), dépendances de données, calculs en virgule fixe ou flottante, contraintes de consommation ... franchement on ne peut pas dire que l'un est meilleur que l'autre en général.

Un FPGA aura comme avantages le fait de concevoir un circuit réellement optimisé pour le traitement à réaliser, des IO très rapides directement sur la puce (pas besoin de faire des aller-retours sur le PCIe, d'ailleurs il n'y a pas besoin de PC à côté), beaucoup de ressources câblées (Blocs DSP, mémoires, interfaces, et même processeurs) et une consommation électrique bien plus faible qu'un GPU.

Depuis une bonne vingtaine d'années, les FPGA se programment à l'aide de languages de description de matériel, tels que VHDL. De plus en plus d'outils permettent de les programmer en C (avec des règles particulières, ca s'appelle "High Level Synthesis" et ca marche de mieux en mieux). Il est désormais erroné de cantonner les FPGA au prototypage d'ASICs : outre les productions en petites séries, ils sont maintenant de plus en plus utilisés comme co-processeurs dans les supercalculateurs.
Pour des applications particulières on peut même être amené à recréer une sorte de GPU avec un FPGA !

Et on peut aussi mettre plusieurs fonctions plus ou moins indépendantes dans un FPGA : des contrôleurs d'IO, du traitement de signal, des co-processeurs pour un processeur hôte, des fonctions de monitoring, etc.
Les dernières puces sur le marché intègrent aussi plusieurs cœurs ARM + GPU !

Une bonne introduction, suffisamment récente (en anglais) :
https://www.embeddedrelated.com/showarticle/195.php

Musikmesser 2013 - Bullshit Gourous - Tocxic Instruments - festivals Foud'Rock, Metal Sphère et la Tour met les Watts

[ Dernière édition du message le 19/03/2017 à 01:33:16 ]

1640
Citation de Jimbass :
Ca dépend énormément des algorithmes qu'on fait avec, et les critères de choix sont complexes : type de parallélisation, localité de chaque traitement (nombre d'IO ou d'accès mémoire par calcul), dépendances de données, calculs en virgule fixe ou flottante, contraintes de consommation... franchement on ne peut pas dire que l'un est meilleur que l'autre en général.

Tout à fait. En fait je pensais à des traitements très simples, mais qui correspondent par exemple à la "table de mixage virtuelle d'une interface audio". Pour donner une idée et expliquer ce que je voulais dire : sur une addition de nombres à virgule fixe avec multiplication par un gain, le FPGA a ses chances. Genre la table de mixage de la fameuse Guillemot ISIS :volatil: ; très bien fichue au demeurant.

Citation de Jimbass :
Il est désormais erroné de cantonner les FPGA au prototypage d'ASICs

Je pensais effectivement à des utilisations de FPGA dans le rôle d'un ASIC. Tu as donc raison et nous sommes effectivement d'accord. :bravo:


Question bête (mais premier degré) : quelle différence fondamentale entre un ASIC et un FPGA ?

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

[ Dernière édition du message le 19/03/2017 à 01:38:14 ]

1641
x
Hors sujet :
J'ai commencé à mettre des CPU dans des FPGA il y a quinze ans ... et à l'époque tout me monde me disait : "Ce n'est pas possible, un FPGA c'est seulement fait pour faire de la glue logique !" Sauf que la techno avait déjà fait de gros progrès, et continue à bien mieux bénéficier de la Loi de Moore que les autres sortes de processeurs. L'enjeu aujourd'hui est bien plus la bande passante d'IO (mémoire comprise) que la fréquence d'une ALU (il suffit d'en mettre plein).

Et il n'y avait pas de FPGA dans l'ISIS, seulement deux DSP. Je sais, j'ai tracé le schéma.

Musikmesser 2013 - Bullshit Gourous - Tocxic Instruments - festivals Foud'Rock, Metal Sphère et la Tour met les Watts

[ Dernière édition du message le 19/03/2017 à 01:58:28 ]

1642
:bravo:

Sale fucking breton ! :fache:
Mais cool, un super expert parmi nous. :bravo:




Néanmoins, pour moi qui a oublié mes cours (VHDL et dessin de circuits logiques, à l'AIME de Toulouse notamment), principale différence entre un ASIC et un FPGA ?

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

1643
Citation de Dr :
sur une addition de nombres à virgule fixe avec multiplication par un gain, le FPGA a ses chances.


Pour appliquer un gain et un offset différents sur chaque pixel d'une vidéo HD en temps réel aussi. Depuis plus de 10 ans. Tout en faisant d'autres trucs à côté. (littéralement : à un autre endroit de la puce)

Citation de Dr :
Question bête (mais premier degré) : quelle différence fondamentale entre un ASIC et un FPGA ?


Un ASIC est un circuit fixe, on a branché des transistors ensemble une fois pour toute pour réaliser une fonction. De l'ampli op au Core i7. Ca veut dire Application Specific Integrated Circuit, donc on sous-entend que c'est moins générique que ces deux exemples, mais le concept est le même. Il y a différentes technos où on essaye de partir d'une base plus ou moins standard (par exemple tout faire avec des portes NAND déjà optimisées) mais il y a aussi du "Full Custom". C'est ce qui permet, avec les technologies micro(nano)électroniques les plus avancées, d'obtenir les meilleurs performances, ainsi que le meilleur coût unitaire. Mais le développement, le test et la mise en production représentent des coûts énormes, plusieurs millions. Et si il y a un bug, on refait tout.

Un FPGA est un circuit configurable. On a plein de portes logiques, qu'on peut connecter comme on veut, une fois que la puce est fabriquée et soudée sur une carte. En pratique, c'est implémenté sous la forme de mémoires SRAM, qui contiennent la configuration des portes (sous forme de Look-Up Tables) et leurs connexions. En plus, on a maintenant plein de blocs câblés pour les fonctions utiles qui sont dures à faire avec des portes programmables. On trouve ainsi des blocs mémoires, des blocs DSP (essentiellement multiplieur-accumulateur), des interfaces d'IO (mémoire DDR, Ethernet, PCIe ... souvent à la pointe des nouvelles versions), maintenant des processeurs multi-coœur, et beaucoup d'entreées-sorties configurables. Et on branche tout ca ensemble à loisir.
En fréquence brute on sera beaucoup moins efficace qu'un ASIC, et sourtout ca dépend de comment on a fait les branchements. Mais la reconfigurabilité a plein d'avantages : moins coûteux à mettre au point, évolutif, voire reconfigurable dynamiquement au cours du fonctionnement. Le prix unitaire est plus élevé qu'un ASIC, mais il n'y a quasiment pas de mise de fonds initiale à faire, et on peut corriger les bugs après coup.

Musikmesser 2013 - Bullshit Gourous - Tocxic Instruments - festivals Foud'Rock, Metal Sphère et la Tour met les Watts

[ Dernière édition du message le 19/03/2017 à 02:16:48 ]

1644
Ok ! :boire:

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

1645
Bonjour à tous !

J'envisage d'organiser de temps en temps des workshops sur le SDK JUCE. Pour rappel, ce SDK fondé par Julian Storer lorsqu'il a créé le séquenceur Tracktion, qui aujourd'hui est développé par une équipe entière dans la société ROLI, est énormément utilisé dans l'industrie des applications audio, pour tout ce qui est plug-in voire applications smartphones.

Personnellement, ça fait 10 ans que je m'en sers vraiment pour tout, recherche, plug-ins, et dans mes activités de consulting je fais presque exclusivement du travail avec JUCE. Une des grandes forces du SDK par rapport à ce qui se fait autour c'est qu'on peut vraiment tout faire avec, ça permet d'avoir du code multi-plateformes et multi-format sur les plug-ins (Windows/Mac OS/Linux/iOS/Android et VST/AU/AAX), et que les classes disponibles avec permettent de concevoir n'importe quoi sans avoir besoin ou presque de librairies extérieures à quelques exceptions près. De plus, la communauté JUCE est très active sur les forums.

Donc j'aimerais savoir si des personnes parmi vous seraient intéressées pour participer à un tel évènement. J'imagine de louer une salle pour deux jours, et j'ai des tonnes de sujets possibles pour les workshops, de la découverte de JUCE, au codage en entier d'un plug-in multi plateformes avec presets, gestion de l'automation et tout ce qui est nécessaire, en passant peut-être par des sujets moins spécifiques à JUCE comme OpenGL, les animations, le codage de traitements en tout genre, la réalisation d'une modélisation de pédale analogique etc.

Donc certaines personnes ici seraient intéressées ? Plutôt par des trucs de découverte ou des sujets plus avancés et dans ce cas là lesquels ?

Merci des retours :bravo:

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

1646
Moi je serais intéressé si tu fais une session du côté de Lyon.

Citation :
Plutôt par des trucs de découverte ou des sujets plus avancés et dans ce cas là lesquels ?

Découverte/prise en main du SDK, bonnes pratiques, portage multi-plateformes ...

DubSide

1647
T'as pas ça en Angleterre ? Au cas où je change de framework :p

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

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

1648
C'est juste à Paris pour le moment :mdr: Pour l'angleterre, y a le JUCE ADC (Audio Developer Conference) 2017 qui aura lieu en Novembre avec deux jours de conférences et une journée de workshops aussi ;)

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

[ Dernière édition du message le 04/04/2017 à 08:32:48 ]

1649
C'est une très bonne idée, merci !
Pour ma part, je serais plus intéressé par le commencement, je n'y connais rien.
Donc plutôt "Découverte/prise en main du SDK, bonnes pratiques" comme VvSurLeRiddim.

Formateur en techniques sonores ; électronicien ; auteur @ sonelec-musique.com

1650
Citation de Wolfen :
C'est juste à Paris pour le moment :mdr: Pour l'angleterre, y a le JUCE ADC (Audio Developer Conference) 2017 qui aura lieu en Novembre avec deux jours de conférences et une journée de workshops aussi ;)

Je peux potentiellement y aller cette année, je serai Londonien... Peut-être mieux avec une pres, faudra que je réfléchisse.
Au fait, t'es passé au Newton Raphson avec SVF/ZDF pour tes plugins ?

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

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