Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Claviers maîtres MIDI
Agrandir
Claviers maîtres MIDI
Informatique musicale
Claviers maîtres MIDI
Produits 683 683
Actu 440 440
Articles 61 61
Médias 42 296 42,3k
Tutoriels Tutos 101 101
Avis 2 203 2,2k
Petites annonces Annonces 299 299
Forums 5 815 5,8k

réactions au dossier L'histoire de la plus grande révolution des instruments électroniques

  • 43 réponses
  • 13 participants
  • 1 776 vues
  • 18 followers
Sujet de la discussion L'histoire de la plus grande révolution des instruments électroniques
5527.jpg
Nous avons eu la chance de rencontrer Benoît Bouchez. C'est le monsieur MIDI en France. En plus d'être ingénieur électronique et informatique accomplie, co-fondateur de KissBox, il est membre de la MMA (MIDI Manufacturers Association) qui travaille a établir les standards liés à la norme MIDI.


Lire l'article


Ce thread a été créé automatiquement suite à la publication d'un article. N'hésitez pas à poster vos commentaires ici !
Afficher le sujet de la discussion
31
Citation :
Comme le dit Bertrand
Perdu, c'est Benoît. Sinon, y'avait Bernard éventuellement.:mrg:
32
Citation de coyote14 :
Citation :
Comme le dit Bertrand
Perdu, c'est Benoît. Sinon, y'avait Bernard éventuellement.:mrg:

On va dire que je suis habitué à l'erreur de Odon... Et je ne parle même pas du nombre de professeurs qui voulaient systématiquement changer mon nom de famille en "Boulanger" :mrg:

Et pour la petite histoire, un nombre incroyable de personnes m'appelle régulièrement Olivier (et ce depuis mon enfance) :facepalm:.
33
Citation de .: Odon Quelconque :. :
Mais est-ce que les ASIC ne sont pas en train de disparaître justement, au profit des composants génériques ARM et des FPGA re-programmables après la mise sur le marché des produits ?

J'avais le sentiment que la propriété intellectuelle et le secret industriel tendaient à se déporter vers le logiciel.


La réponse est "oui et non". En réalité, ça fait longtemps que les industriels japonais sont passés sur une approche plus "logicielle". Je vais prendre un exemple concret : le composant SWP30B utilisé sur quasiment tous les synthés Yamaha des années 2000 est un DSP ultra spécialisé, mais fondu spécifiquement pour Yamaha (c'est donc techniquement un ASIC).

Sans rentrer dans les détails technique, les chips de la précédente génération (genre EMU8K) pouvaient "juste" être configurés par le processeur, mais à part jouer des tables d'ondes d'un format particulier, un EMU8K ne pouvait rien faire d'autre. On avait la même chose chez Ensoniq, avec des puces comme le OTTO, qui devait être associé à d'autres composants pour les effets par exemple (le OTTO est un lecteur de samples en ROM ou RAM)

A partir des années 2000, les chips ont commencé à basculer vers une approche de plus en plus micro-programmée. En gros, on est face à des composants optimisés pour la lecture de samples, avec de la circuiterie "on chip" faisant les calculs les plus critiques, comme par exemple l'interpolation entre échantillons. Du coup, on peut effectuer les traitements d'effets sur la même puce en implémentant en soft les algorithmes qui vont bien.

Il y a effectivement une tendance depuis quelques temps pour essayer de passer en pur soft, avec l'augmentation des performances des coeurs micro (cf le projet Zynthian par exemple ou même les Volca ou les Minilogues, ou quasiment tout est fait sur des composants "classiques" à coeur ARM).

Mais cette tendance est maintenant revue dans l'autre sens, car d'autres problèmes sont apparus à vouloir faire des chips passe-partout (il suffit de regarder sur un Raspberry Pi les contraintes qui sont apparues pour le refroidissement des puces). Finalement, l'industrie repart vers une solution intermédiaire, avec des coeurs micro "standards" associés à des périphériques spécialisés dans le traitement audio, voire carrément la synthèse.

Il suffit de regarder ce qui s'est passé avec les FPGA Cyclone par exemple : les Cyclone IV sont des FPGA "purs" (un peu comme des DSP spécialisés et ultra rapides dans leur domaine, si je peux me permettre cette comparaison) mais les Cyclone V sont des FPGA sur lesquels on a accolé un double coeur processeur ARM9, car on s'est aperçus que vouloir faire du soft sur un processeur "softcore FPGA" ne permettait jamais d'atteindre les performances d'un processeur dédié, mais que faire le traitement du signal sur le ARM ne permettait pas d'obtenir les performances d'un circuit DSP spécialisé.

La plupart des "ASIC" utilisés maintenant par Roland, Yamaha ou Korg suivent la même logique : ils ont accolés des fonctions standards (typiquement des coeurs ARM) à une logique spécialisée développée en interne (qui elle-même est souvent un DSP optimisé, donc programmable logiciellement, mais avec des périphériques spécialisés pour la lecture des tables d'onde par exemple)
34
Citation de veve_mao :
Salut @ tous,
midi.org est inaccessible depuis quelques jours, c'est normal ?

Normal... non :clin:

Le site devait être mis à jour juste après le NAMM (justement pour mettre à disposition du public tout ce qui avait été échangé durant le NAMM...), mais disons que le prestataire chargé de ce travail a... comment dire... on va dire "m**dé" totalement (et le mot est encore faible...) :facepalm:

Le lien vers le site en cours de mise à jour fonctionne encore, mais je suis en attente de savoir si j'ai le droit de le communiquer publiquement
35
Merci Bernard. :mrg: :oops2:

x
Hors sujet :
C'est vrai qu'on trouve en ligne pas mal de publications académiques - thèses et autres - sur les performances comparées des CPU, GPU, DSP et FPGA dans le domaine du traitement du signal (astronomie, radar), qui sont largement en dehors de mes forts modestes compétences, mais dont les résumés indiquaient effectivement les contraintes que tu éclaires largement.
La contrainte économique du rapport coût/performance y apparaissait aussi quant aux quantités.
De mémoire, pour moins de 10 000 unités, le FPGA était une bonne alternative au DSP.

Or, j'imagine que quand Yamaha ou Roland commandent un chip à Toshiba ou Renesas, c'est pour de très grandes quantités, et en s'engageant sur plusieurs années (~8/10 ans ?).

D'ailleurs, dans une logique industrielle bien comprise, on remarque les puces autour desquelles étaient construit certains produits se retrouvent souvent en puces périphériques dans les gammes suivantes.

Par exemple, au début des années 2000, dans la gamme des ROMpleur et sampleurs E-MU, la puce E-MU 8000 servait exclusivement de processeur d'effets, accolée aux puces G (osc) & H (filtres) programmées par le CPU ColdFire (+ un FPGA Xilinx pour orchestrer le tout).

Spoiler - Cliquer ici pour lire la suite


Ou encore la puce ESC2 de Roland/Boss, composant principal des processeurs COSM ou des Boutiques ACB, qu'on retrouve comme processeur d'effets et gestion des bus lents sur l'Integra-7 ou même sur les Fantom actuels, pour d'autres fonctions.

Pour revenir au MIDI 2.0 et aux interrogations de Will notamment, peut-on envisager que ce bus relativement lent autorise une compatibilité avec un large pan de machines pas trop anciennes dotée d'un port USB 2.0 (voire 1.1), pour peu que leur firmware soit mis à jour (vaste problématique !) et que la puissance de calcul de leur électronique soit suffisante ?

Mais les fabricants préfèreront sans doute vendre de nouvelles machines plutôt que mettre à jour celles qui pourraient l'être...

Surtout s'il y a moyen d'imposer une connectique propriétaire MIDI 2.0. :mrg:

« 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)

[ Dernière édition du message le 25/02/2024 à 14:09:22 ]

36
Ah zut, je n'avions point vu le message de Will... :(((

Alors on va faire simple : si le processeur est "moderne" (genre ARM, XMOS, PIC32, etc...), le fait de passer sur des structures uniformisées sur 32 bits rend le traitement plus efficace. Ca peut paraître paradoxal, mais en fait, les processeurs sont optimisés pour travailler sur ce genre de structure. Pour ceux qui connaissent un peu la programmation, les instructions "#pragma pack()" sont le meilleur moyen de tuer l'optimisation d'un flux de données, car ça va perturber l'alignement mémoire par rapport à ce que le processeur souhaite voir.

En gros, si vous laissez un compilateur faire, il va systématiquement arranger les données pour que le processeur perde le moins de temps possible pour y accéder, même si ça consomme de la place en mémoire !. Par exemple, si vous avez une structure de 16 bits suivie d'une structure 8 bits, le compilateur va quasiment à tous les coups allouer deux emplacements de 32 bits plutôt que d'accoler les deux structures dans un seul mot de 32 bits (puisque le total des deux structures ne fait que 24 bits).

Et donc, sur les processeurs modernes, le traitement d'un flux MIDI 1.0 s'avère en fait assez contre-productif quand il faut jongler avec les octets (avec en plus le fait qu'en MIDI 1.0, la taille d'un message va de 1 à 3 octets - sauf les SYSEX qui peuvent grimper très, très haut...)

Sur les prototypes que nous avons réalisés pour la validation du protocole, nous nous sommes aperçus que l'empreinte mémoire et la charge CPU du code pour traiter le MIDI 2.0 étaient plus faibles que pour le MIDI 1.0, à fonctionnalités égales. Il faut dire que les compilateurs C modernes sont de véritables tueurs en termes d'optimisation dès que les structures sont adaptées au modèle mémoire du processeur (donc 32 bits pour des processeurs 32 bits ou 64 bits)

Sur les processeurs plus anciens (16 bits par exemple), l'impact est globalement assez faible mais certes pas nul. Sauf à avoir un bouzin qui était déjà à la ramasse en MIDI 1.0 sur 8 bits (si, si, il y en a... :??:), le passage en MIDI 2.0 n'est normalement pas une tâche impossible pour peu que le code ait été écrit correctement et soit toujours accessible.

D'ailleurs je profite de cette réponse pour souligner que l'USB 2.0 est parfaitement adapté pour faire du MIDI (que ce soit du MIDI 1.0 ou du MIDI 2.0), la plupart des micro-contrôleurs utilisés n'étant de toute façon pas capables de traiter correctement l'USB 3.0.
Sans vouloir faire un cours sur l'USB, il faut savoir que l'USB 3 a surtout été conçu pour faire des échanges de gros volumes de données (genre vidéo ou mémoire de masse). Hors les messages MIDI (que ce soit du 1.0 ou du 2.0) sont très courts (4 octets pour le MIDI 1.0 sur USB, jusque 32 octets pour le MIDI 2.0). En gros, l'USB serait comme une autoroute dont l'accès est réglementé par une barrière dont l'ouverture est commandée par l'hôte (disons le PC ou le Mac pour faire simple). Quand la barrière s'ouvre, on ne laisse passer qu'un seul véhicule, qui ne peut transporter qu'un seul paquet de données. Et donc, le gain d'avoir des "véhicules" capables de transporter de plus gros paquets est nul, étant donnée la taille des paquets MIDI.

Et pour finir, il faut savoir que les couches basses de l'USB sont justement conçues pour que les hôtes puissent travailler avec des périphériques très lents (genre une souris ou un clavier, qui sont toujours en 1.1, voire en 1.0). Au niveau du microprocesseur du périphérique MIDI, il y a de toute façon un mécanisme de synchronisation qui fait que l'hôte attend que le périphérique soit prêt à transmettre, ce qui va rendre les échanges transparents même avec un processeur "lent"

[ Dernière édition du message le 25/02/2024 à 18:54:41 ]

37
Merci pour toutes tes explications. C'est très riche. :bravo:

Tu es un homme précieux, Olivier. :oops2: :mrg:
38
Citation de Will Zégal :
Merci pour toutes tes explications. C'est très riche. :bravo:

Tu es un homme précieux, Olivier. :oops2: :mrg:


Pas de quoi (mais je pense que mon message a été tronqué lors du premier enregistrement... Je t'ai notamment répondu plus en détail sur ta question Will, mais le texte complété est apparu plus tard me semble t'il...)
39
Ah oui. En effet, il manquait un gros bout. Merci de me l'avoir signalé, je serais passé à côté.
(sauf peut-être dans 6 mois quand je serais repassé sur le sujet pour me rafraîchir la mémoire)
40
Merci Benoit pour tous tes messages, tous très intéressants. :clin:

>> Mon live Fête de la Musique 2024, mon DJ mix 2023, quatre lives électro-piano en vidéo, la compo du mois AF Les Pieds Dans Le Patch Février 2020 et bien plus