réactions au dossier L'histoire de la plus grande révolution des instruments électroniques
- 48 réponses
- 13 participants
- 2 568 vues
- 19 followers
Afficher le sujet de la discussion
Très intéressant comme le disait Odon. Par contre, et désolé d'insister, ce n'est pas parce qu'ils s'appuient sur des ASICs (après MMA et UMP...) que ça justifie forcément une entité indépendante de la MMA. Ils pouvaient / peuvent très bien faire des réunions entre eux (pour les raisons que tu viens de mentionner) en étant dans la MMA.
Et pour bien comprendre un autre point de ta réponse, cela veut dire qu'ils ne veulent pas communiquer des secrets industriels... mais entre eux oui ?
OK donc en vue macro, mais n'hésite pas à corriger si ce n'est pas exact, tout instrument armé de MIDI (1.0) passant via USB peut basculer en MIDI 2.0 via mise à jour de firmware (et ça serait donc porteur d'espoir notamment pour des instruments pouvant s'appuyer sur l'horloge MIDI comme des séquenceurs, sampleurs, arpégiateurs ou LFOs de synthétiseurs, etc.). Et donc la connectique en DIN est elle vouée à rester bloquée en MIDI 1.0.
En attendant plus d'infos de la part de Beb, si on regarde un peu, on voit que l'AMEI est une émanation du MITI, en relation directe avec l'organisme de normalisation industrielle japonais, lui-même en charge de la définition, du respect et la promotion des normes, de leur intégration aux cursus des universités, etc.
https://www.amei.or.jp/about/outline_e1.html
https://en.wikipedia.org/wiki/Association_of_Musical_Electronics_Industry
https://en.wikipedia.org/wiki/Japan_MIDI_Standards_Committee
Je n'ai pas l'impression que la MMA ait ce niveau d'intégration institutionnelle aux USA ou ailleurs dans le monde.
Les fabricants ont besoin de se coordonner pour assurer l'interopérabilité de leurs produits, dans leur intérêt mutuel. C'est une entente entre industriels sur un protocole de communication externe, donc partagé.
Ce qu'ils font du MIDI en interne dans leurs composants et logiciels ne regarde qu'eux, même si on se doute bien que l'état de l'art est le même pour tout le monde, et que leurs ingénieurs viennent des mêmes écoles.
D'ailleurs, en ce moment, ils virtualisent à tout va leurs moteurs pour qu'ils tournent sur ordinateurs (Roland d'abord, puis Korg et maintenant Yamaha).
BeB nous tancera sans doute, mais a priori, je dirais que l'électronique qui gère le MIDI DIN est calibrée pour une communication en mode série, avec les débits des ports série tels qu'ils sont définis par les spécifications qui datent des années70/80 1960 ! (RS-232 et autres).
Les tentatives d'augmenter ce débit - comme par exemple le Turbo-MIDI d'Elektron - se sont toujours heurtées à la compatibilité matérielle de l'électronique du récepteur (son opto-coupleur ou son UART déjà) et à la limite du protocole à ce format (115200 bit/s).
Même aux 31250 bit/s de la spec, qui n'a jamais eu de message « MIDI Buffer Full » lors d'interactions avec un ordinateur sur un synthé des années 90 ou 2000 ?
Le MIDI 2.0 s'appuie sur un protocole de transport sous forme de paquets, dont la couche physique peut être l'USB, l'Ethernet (RTP-MIDI qui sera apparemment redéfini pour la spec), BT LE, etc. à des débits infiniment plus élevés.
https://fr.wikipedia.org/wiki/D%C3%A9bits_et_port%C3%A9es
Pour les machines exclusivement dotées de MIDI DIN, voire d'USB 1.1, le bénéfice des fonctionnalités du MIDI 2.0 s'arrêtera donc logiquement au niveau de l'interface MIDI "intelligente" comme il en a toujours existé, qui sera capable de traiter les paquets UMP et d'en extraire les informations pour les envoyer au format et à la vitesse du meilleur port de communication disponible sur le hardware concerné. C'est un goulet d'étranglement incontournable.
On ne pourra pas avoir de configuration automatique (Properties) ou tout ce qui ressortira du MIDI-CI, mais, s'il est utilisé par la source (STAN ou séquenceur hw), on pourra bénéficier du Jitter Reduction, qui fonctionnera ensuite comme c'était le cas avec les protocoles propriétaires style Steinberg LTB (Midex-3 ou 8) ou emagic AMT (AMT-8, Unitor-8), lesquelles utilisaient un CPU et une horloge interne pour transmettre les messages MIDI au meilleur timing possible.
Evidemment, si on utilise un vieux séquenceur, ou un ordinosaure, ce ne sera pas possible non plus. La qualité de la chaine dépendra du maillon le plus faible.
Pour donner un exemple, j'utilisais l'éditeur logiciel Roland du Jupiter-Xm indifféremment en mode MIDI DIN ou MIDI USB puisque l'éditeur supportait les deux.
Ce qui entre parenthèse permettait de contourner l'inexistence des pilotes USB MIDI et audio Roland pour Windows 7 (i.e. sur une plate-forme obsolète ou non supportée, la vieille norme permet encore de se passer du protocole propriétaire).
Les deux modes de communication fonctionnaient parfaitement.
Mais ça allait nettement plus vite en USB MIDI 2.0 vu le volume très important de SysEx échangés en permanence.
En spéculant un peu, on peut par contre imaginer des convertisseurs MIDI-CI <-> SysEx, qui permettraient d'exposer en MIDI 2.0 les paramètres SysEx de machines particulières.
Ce qui suppose un travail de transcription et de mise en correspondance des paramètres sans doute long et fastidieux, mais techniquement, je pense que ce sera possible.
Au pire on demandera à une IA.
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"
Et pour la petite histoire, un nombre incroyable de personnes m'appelle régulièrement Olivier (et ce depuis mon enfance)
.
Normal... non
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...)
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
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...)
Non, le site à utiliser reste midi.org.
Mais bonne nouvelle : le site mis à jour est enfin en ligne
Apparemment, il y a encore quelques petits problèmes de connexion pour les membres du MMA, mais le plus gros est fait et les spécifications sont à nouveau accessibles
Alors, attention sujet brûlant...
La RJ45 dont Pete parle, c'est pour le Network MIDI 2.0, donc sur Ethernet. Pour faire simple, c'est actuellement la seule interface qui existe officiellement à côté de l'USB pour faire passer le MIDI 2.0 (puisqu'il existe également une spécification de classe USB pour le MIDI 2.0)
La prise USB qu'on voit sur le module présenté pendant l'interview à laquelle j'ai participé, c'est pour remplacer le connecteur DIN (techniquement, le MIDI sur port série). Etant soumis à la confidentialité concernant ce qui se passe au sein du MMA, il y a des informations que je n'ai pas le droit de révéler. Mais pour faire simple : il y a actuellement de grosses discussions en interne au sein du MMA pour savoir quel modèle de connecteur sera spécifié officiellement pour le MIDI 2.0 sur port série, le connecteur USB-C étant l'une des deux solutions (j'ai pas le droit de dire quelle est l'autre...
)
Le problème de ce connecteur est qu'il est lié au groupe USB-IF qui gère toute la partie "licensing" liée à tout ce qui est lié à l'USB (c'est l'USB-IF qui gère entre autres les Vendor ID / Product ID sans lesquels on n'est pas autorisé à mettre un produit USB sur le marché). Et le hic, c'est que techniquement, pour le MIDI sur port série, ça ne sera pas de l'USB qui passera dans le connecteur....
Bref, ça discute, ma bonne dame...
- 1
- 2
Will Zégal
77938
Will Zégal
Membre depuis 23 ans
C'est vrai. Mais les chips qui se contentent jusqu'à présent de transmettre par USB du MIDI 1.0 sont-ils aussi capables de gérer de l'UMP ? Je ne parle pas de juste le transmettre.
(p*** que je déteste ce nom )
(p*** que je déteste ce nom
)VE
4517
Squatteur·euse d’AF
Membre depuis 22 ans
Citation de BebDigitalAudio :
Citation de VE :- Par rapport à "l'indépendantisme japonais" j'avoue ne pas comprendre. Les arguments indiqués dans la vidéo ne sont pas clairs, au moins pour moi. Si l'AMEI suit le MMA tout le temps à quoi bon avoir l'AMEI / à quoi bon avancer côté MMA, devoir tout envoyer à l'AMEI (qui doit valider à son tour ?)
Le mécanisme de fonctionnement est plus subtil que simplement un envoi du MMA vers l'AMEI et commentaires. Il y a des choses que je ne peux pas révéler ici, mais je vais essayer de simplifier. Il faut comprendre un point très important qui différencie les industriels japonais du "reste du monde" (je caricature un peu mais c'est globalement l'idée). Les machines japonaises sont pour la plupart équipées de circuits intégrés spécifiques qu'on appelle les ASIC qui coutent une véritable fortune à concevoir et qui nécessitent de très gros moyens industriels (pour se donner une idée, une simple modification de masque de fabrication se chiffre en centaines de k€). Ces puces représentent le savoir faire de chaque constructeur, avec ses propres algorithmes, etc... La plupart (si ce n'est la totalité) des constructeurs européens et américains utilisent quant à eux des puces standards.
Les japonais ne peuvent pas (et ne veulent pas) communiquer sur les détails de leur circuits, sinon ça reviendrait à divulguer des secrets industriels. Et le problème est que toute évolution de la norme impacte la conception de ces puces, et ils sont les seuls à pouvoir évaluer ces impacts. On pourrait un peu comparer ce fonctionnement entre un bureau de R&D et une équipe chargée de l'industrialisation. Tout ce qui sort de la R&D n'est pas forcément transposable sur un produit en production et il faut alors des retours pour s'assurer qu'on ne part pas des délires impossibles à réaliser.
Après, il faut reconnaître qu'il y a aussi un aspect un peu politique/financier à la chose et qu'un blocage de la part des poids lourds du marché est quasiment assuré de faire échouer une évolution.
Très intéressant comme le disait Odon. Par contre, et désolé d'insister, ce n'est pas parce qu'ils s'appuient sur des ASICs (après MMA et UMP...) que ça justifie forcément une entité indépendante de la MMA. Ils pouvaient / peuvent très bien faire des réunions entre eux (pour les raisons que tu viens de mentionner) en étant dans la MMA.
Et pour bien comprendre un autre point de ta réponse, cela veut dire qu'ils ne veulent pas communiquer des secrets industriels... mais entre eux oui ?
Citation de BebDigitalAudio :
Citation de VE :J'ai peut-être déjà oublié mais est-ce que le sujet de la synchro d'horloge / tempo est bien réglé avec le MIDI 2.0 ?
La réponse est "en théorie, oui". La spécification MIDI 2.0 a défini un concept qu'on appelle "Jitter reduction" (je crois que j'en parle un peu dans l'interview mais j'ai un doute). Le principe est de transmettre une horloge à très haute résolution dans le flux MIDI (la résolution est de 32 microsecondes
Maintenant, tout dépend de la qualité de l'implémentation logicielle tant côté DAW que côté récepteurs... Quand on voit les performances de certaines interfaces MIDI en termes de jitter, le fait d'avoir un protocole qui a "tout" prévu ne garantit pas que les programmeurs soient capables de faire un travail propre par derrière
Citation de VE :Au niveau technique, est-ce qu'un Osmose d'Expressive E pourra(it) bien basculer sur du MIDI 2.0 uniquement via mise à jour de firmware
Alors là... tu m'en demandes beaucoup. Je ne travaille pas avec Expressive-E et je n'ai aucune idée de comment est implémenté leur logiciel de contrôle (et ma boule de cristal est tombée en panne ce matin
Toutefois, si l'Osmose dispose d'un port USB qui supporte déjà le MIDI 1.0, alors oui, en principe, une "simple" mise à jour du firmware permet de passer en MIDI 2.0 via l'USB, puisque c'est juste le format des données échangées sur USB qui change, pas le fonctionnement de l'USB lui-même.
On a d'ailleurs la même situation chez KissBox (pour parler de ma société) par exemple, où tous nos produits compatibles RTP-MIDI (donc MIDI 1.0 sur réseau Ethernet) sont "de facto" compatibles Network UMP (MIDI 2.0 sur Ethernet) moyennant une simple mise à jour du firmware, puisque la couche réseau Ethernet / IP ne change pas, c'est uniquement le contenu des trames UDP qui évolue.
OK donc en vue macro, mais n'hésite pas à corriger si ce n'est pas exact, tout instrument armé de MIDI (1.0) passant via USB peut basculer en MIDI 2.0 via mise à jour de firmware (et ça serait donc porteur d'espoir notamment pour des instruments pouvant s'appuyer sur l'horloge MIDI comme des séquenceurs, sampleurs, arpégiateurs ou LFOs de synthétiseurs, etc.). Et donc la connectique en DIN est elle vouée à rester bloquée en MIDI 1.0.
Will Zégal
77938
Will Zégal
Membre depuis 23 ans
.: Odon Quelconque :.
11745
Drogué·e à l’AFéine
Membre depuis 23 ans
Citation de VE :
Très intéressant comme le disait Odon. Par contre, et désolé d'insister, ce n'est pas parce qu'ils s'appuient sur des ASICs (après MMA et UMP...) que ça justifie forcément une entité indépendante de la MMA. Ils pouvaient / peuvent très bien faire des réunions entre eux (pour les raisons que tu viens de mentionner) en étant dans la MMA.
Et pour bien comprendre un autre point de ta réponse, cela veut dire qu'ils ne veulent pas communiquer des secrets industriels... mais entre eux oui ?
En attendant plus d'infos de la part de Beb, si on regarde un peu, on voit que l'AMEI est une émanation du MITI, en relation directe avec l'organisme de normalisation industrielle japonais, lui-même en charge de la définition, du respect et la promotion des normes, de leur intégration aux cursus des universités, etc.
https://www.amei.or.jp/about/outline_e1.html
https://en.wikipedia.org/wiki/Association_of_Musical_Electronics_Industry
https://en.wikipedia.org/wiki/Japan_MIDI_Standards_Committee
Je n'ai pas l'impression que la MMA ait ce niveau d'intégration institutionnelle aux USA ou ailleurs dans le monde.
Les fabricants ont besoin de se coordonner pour assurer l'interopérabilité de leurs produits, dans leur intérêt mutuel. C'est une entente entre industriels sur un protocole de communication externe, donc partagé.
Ce qu'ils font du MIDI en interne dans leurs composants et logiciels ne regarde qu'eux, même si on se doute bien que l'état de l'art est le même pour tout le monde, et que leurs ingénieurs viennent des mêmes écoles.
D'ailleurs, en ce moment, ils virtualisent à tout va leurs moteurs pour qu'ils tournent sur ordinateurs (Roland d'abord, puis Korg et maintenant Yamaha).
Citation de VE :
OK donc en vue macro, mais n'hésite pas à corriger si ce n'est pas exact, tout instrument armé de MIDI (1.0) passant via USB peut basculer en MIDI 2.0 via mise à jour de firmware (et ça serait donc porteur d'espoir notamment pour des instruments pouvant s'appuyer sur l'horloge MIDI comme des séquenceurs, sampleurs, arpégiateurs ou LFOs de synthétiseurs, etc.). Et donc la connectique en DIN est elle vouée à rester bloquée en MIDI 1.0.
BeB nous tancera sans doute, mais a priori, je dirais que l'électronique qui gère le MIDI DIN est calibrée pour une communication en mode série, avec les débits des ports série tels qu'ils sont définis par les spécifications qui datent des années
Les tentatives d'augmenter ce débit - comme par exemple le Turbo-MIDI d'Elektron - se sont toujours heurtées à la compatibilité matérielle de l'électronique du récepteur (son opto-coupleur ou son UART déjà) et à la limite du protocole à ce format (115200 bit/s).
Même aux 31250 bit/s de la spec, qui n'a jamais eu de message « MIDI Buffer Full » lors d'interactions avec un ordinateur sur un synthé des années 90 ou 2000 ?
Le MIDI 2.0 s'appuie sur un protocole de transport sous forme de paquets, dont la couche physique peut être l'USB, l'Ethernet (RTP-MIDI qui sera apparemment redéfini pour la spec), BT LE, etc. à des débits infiniment plus élevés.
https://fr.wikipedia.org/wiki/D%C3%A9bits_et_port%C3%A9es
Pour les machines exclusivement dotées de MIDI DIN, voire d'USB 1.1, le bénéfice des fonctionnalités du MIDI 2.0 s'arrêtera donc logiquement au niveau de l'interface MIDI "intelligente" comme il en a toujours existé, qui sera capable de traiter les paquets UMP et d'en extraire les informations pour les envoyer au format et à la vitesse du meilleur port de communication disponible sur le hardware concerné. C'est un goulet d'étranglement incontournable.
On ne pourra pas avoir de configuration automatique (Properties) ou tout ce qui ressortira du MIDI-CI, mais, s'il est utilisé par la source (STAN ou séquenceur hw), on pourra bénéficier du Jitter Reduction, qui fonctionnera ensuite comme c'était le cas avec les protocoles propriétaires style Steinberg LTB (Midex-3 ou 8) ou emagic AMT (AMT-8, Unitor-8), lesquelles utilisaient un CPU et une horloge interne pour transmettre les messages MIDI au meilleur timing possible.
Evidemment, si on utilise un vieux séquenceur, ou un ordinosaure, ce ne sera pas possible non plus. La qualité de la chaine dépendra du maillon le plus faible.
Pour donner un exemple, j'utilisais l'éditeur logiciel Roland du Jupiter-Xm indifféremment en mode MIDI DIN ou MIDI USB puisque l'éditeur supportait les deux.
Ce qui entre parenthèse permettait de contourner l'inexistence des pilotes USB MIDI et audio Roland pour Windows 7 (i.e. sur une plate-forme obsolète ou non supportée, la vieille norme permet encore de se passer du protocole propriétaire).
Les deux modes de communication fonctionnaient parfaitement.
Mais ça allait nettement plus vite en USB MIDI 2.0 vu le volume très important de SysEx échangés en permanence.
En spéculant un peu, on peut par contre imaginer des convertisseurs MIDI-CI <-> SysEx, qui permettraient d'exposer en MIDI 2.0 les paramètres SysEx de machines particulières.
Ce qui suppose un travail de transcription et de mise en correspondance des paramètres sans doute long et fastidieux, mais techniquement, je pense que ce sera possible.
Au pire on demandera à une IA.
« 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 23/02/2024 à 12:58:21 ]
Will Zégal
77938
Will Zégal
Membre depuis 23 ans
Coyote14
16650
Modérateur·trice thématique
Membre depuis 21 ans
Citation :
Perdu, c'est Benoît. Sinon, y'avait Bernard éventuellement.Comme le dit Bertrand
BebDigitalAudio
117
Posteur·euse AFfiné·e
Membre depuis 19 ans
Citation de coyote14 :
Citation :Perdu, c'est Benoît. Sinon, y'avait Bernard éventuellement.Comme le dit Bertrand
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"
Et pour la petite histoire, un nombre incroyable de personnes m'appelle régulièrement Olivier (et ce depuis mon enfance)
.BebDigitalAudio
117
Posteur·euse AFfiné·e
Membre depuis 19 ans
BebDigitalAudio
117
Posteur·euse AFfiné·e
Membre depuis 19 ans
Citation de veve_mao :
Salut @ tous,
midi.org est inaccessible depuis quelques jours, c'est normal ?
Normal... non
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...)
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
.: Odon Quelconque :.
11745
Drogué·e à l’AFéine
Membre depuis 23 ans
Merci Bernard. 
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.
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).
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.
« 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 ]
BebDigitalAudio
117
Posteur·euse AFfiné·e
Membre depuis 19 ans
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"
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 ]
Will Zégal
77938
Will Zégal
Membre depuis 23 ans
Merci pour toutes tes explications. C'est très riche.
Tu es un homme précieux, Olivier.
Tu es un homme précieux, Olivier.
BebDigitalAudio
117
Posteur·euse AFfiné·e
Membre depuis 19 ans
Citation de Will Zégal :
Merci pour toutes tes explications. C'est très riche.
Tu es un homme précieux, Olivier.
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...)
Will Zégal
77938
Will Zégal
Membre depuis 23 ans
VE
4517
Squatteur·euse d’AF
Membre depuis 22 ans
Merci Benoit pour tous tes messages, tous très intéressants.
BebDigitalAudio
117
Posteur·euse AFfiné·e
Membre depuis 19 ans
Et finalement quelques nouvelles du site midi.org (avec le droit de me distribuer quelques claques à propos de ma médisance sur le prestataire derrière les opérations )
Voici la communication officielle du MMA suite à l'indisponibilité du site :
MIDI.org was hit by a perfect storm in the middle of transitioning to a new website platform. We were moving from a Joomla based website to a Wordpress website with much more security in place. But only a few days before the transition, we were hit by a series of DoS attacks which took the site down. We apologize for the inconvenience and are working to rectify the problem by transitioning completely to the new site.
)Voici la communication officielle du MMA suite à l'indisponibilité du site :
MIDI.org was hit by a perfect storm in the middle of transitioning to a new website platform. We were moving from a Joomla based website to a Wordpress website with much more security in place. But only a few days before the transition, we were hit by a series of DoS attacks which took the site down. We apologize for the inconvenience and are working to rectify the problem by transitioning completely to the new site.
BebDigitalAudio
117
Posteur·euse AFfiné·e
Membre depuis 19 ans
Citation de VE :
Il faut aller sur midi2.org maintenant.
Non, le site à utiliser reste midi.org.
Mais bonne nouvelle : le site mis à jour est enfin en ligne
Apparemment, il y a encore quelques petits problèmes de connexion pour les membres du MMA, mais le plus gros est fait et les spécifications sont à nouveau accessibles
Will Zégal
77938
Will Zégal
Membre depuis 23 ans
.: Odon Quelconque :.
11745
Drogué·e à l’AFéine
Membre depuis 23 ans
Une vidéo (en anglais) indexée sur les fonctionnalités du MIDI 2.0, ainsi que ses conséquences sur les matériels et logiciels :
Martin, le développeur du petit bijou que sont les Electra One Mk1 et Mk2, est également en train de bosser sur la compatibilité MIDI 2.0 de sa machine, afin de faire ce qu'on évoquait plus haut : une passerelle entre SysEx et MIDI-CI.
https://forum.electra.one/t/midi-2-0/63
https://gearspace.com/board/electronic-music-instruments-and-electronic-music-production/1376412-midi-2-0-news-9.html#post16930962
Et apparemment, pour quelqu'un qui maîtrise tout de même pas mal le sujet, il en ch...
Citation :
Exploring MIDI 2.0: A Conversation with Microsoft's Pete Brown
00:00 Introduction
00:19 Intro to Pete
02:09 What is MIDI?
07:22 Why do we need MIDI 2.0?
09:18 MIDI MPE
10:26 Bi-directional communication
12:10 MIDI CI
13:33 MIDI CI over 1.0 / CI over 2.0 UMP
14:04 Why is Microsoft implementing MIDI 2.0?
18:23 Network MIDI 2.0
19:20 Is this the end of OEM MIDI drivers?
22:40 App to app MIDI communication
25:32 What do developers need to do?
28:21 Bringing old devices into MIDI 2.0
31:17 MIDI 2.0 tools in Windows
32:05 Live demo of the new MIDI 2.0 tools in Windows 11
42:31 Bluetooth MIDI
43:45 Windows as MIDI router
45:17 Open Source Project
47:19 How will it ship?
50:58 Links for developers
52:02 Pete's Windows Audio workstation guides
53:10 What's your favorite synth?
Martin, le développeur du petit bijou que sont les Electra One Mk1 et Mk2, est également en train de bosser sur la compatibilité MIDI 2.0 de sa machine, afin de faire ce qu'on évoquait plus haut : une passerelle entre SysEx et MIDI-CI.
https://forum.electra.one/t/midi-2-0/63
https://gearspace.com/board/electronic-music-instruments-and-electronic-music-production/1376412-midi-2-0-news-9.html#post16930962
Citation :
I have been recently working on extending Electra One firmware with the MIDI 2.0 support. The idea is that the controller will bridge/proxy parameters of connected MIDI 1.0 gear (say a vintage sysex based synth) to CI properties. These would be then exposed to DAW software or any USB host.
Et apparemment, pour quelqu'un qui maîtrise tout de même pas mal le sujet, il en ch...
Citation :
I must say that the MIDI 2.0 tech docs are easy to follow and use. That's great. But using 2.0 is actually quite hard
« 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 08/03/2024 à 08:14:38 ]
.: Odon Quelconque :.
11745
Drogué·e à l’AFéine
Membre depuis 23 ans
Will Zégal
77938
Will Zégal
Membre depuis 23 ans
BebDigitalAudio
117
Posteur·euse AFfiné·e
Membre depuis 19 ans
Citation de .: Odon Quelconque :. :
La remarque intéressante : le RJ45 va remplacer le DIN MIDI. On ne parlerait donc plus d'un nouveau connecteur propriétaire en complément de l'USB-C ?
Alors, attention sujet brûlant...
La RJ45 dont Pete parle, c'est pour le Network MIDI 2.0, donc sur Ethernet. Pour faire simple, c'est actuellement la seule interface qui existe officiellement à côté de l'USB pour faire passer le MIDI 2.0 (puisqu'il existe également une spécification de classe USB pour le MIDI 2.0)
La prise USB qu'on voit sur le module présenté pendant l'interview à laquelle j'ai participé, c'est pour remplacer le connecteur DIN (techniquement, le MIDI sur port série). Etant soumis à la confidentialité concernant ce qui se passe au sein du MMA, il y a des informations que je n'ai pas le droit de révéler. Mais pour faire simple : il y a actuellement de grosses discussions en interne au sein du MMA pour savoir quel modèle de connecteur sera spécifié officiellement pour le MIDI 2.0 sur port série, le connecteur USB-C étant l'une des deux solutions (j'ai pas le droit de dire quelle est l'autre...
)Le problème de ce connecteur est qu'il est lié au groupe USB-IF qui gère toute la partie "licensing" liée à tout ce qui est lié à l'USB (c'est l'USB-IF qui gère entre autres les Vendor ID / Product ID sans lesquels on n'est pas autorisé à mettre un produit USB sur le marché). Et le hic, c'est que techniquement, pour le MIDI sur port série, ça ne sera pas de l'USB qui passera dans le connecteur....
Bref, ça discute, ma bonne dame...
.: Odon Quelconque :.
11745
Drogué·e à l’AFéine
Membre depuis 23 ans
Merci Benoit pour cette petite actualisation.
Par MIDI 2.0 série, tu veux dire la transmission de paquets UMP sur une couche transport série qui ne soit pas l'USB ? Genre pour relier plusieurs synthés entre eux sans les contraintes du Host ?
Si la bande passante et la résistance mécanique ou aux interférences du mini-jack n'est pas suffisante, HDMI ou mini-HDMI, comme sur le OXI Instruments Pipe (certes, chez eux, c'est pour transmettre du CV/Gate et du signal d'horloge) ?
Robuste, largement répandu, avec détrompeur, plein de broches pour faire du bi-directionnel ou faire passer d'autres signaux avec un seul câble (audio analogique, audio numérique, ...) tout en étant plus souple que le eSATA...
Par MIDI 2.0 série, tu veux dire la transmission de paquets UMP sur une couche transport série qui ne soit pas l'USB ? Genre pour relier plusieurs synthés entre eux sans les contraintes du Host ?
Si la bande passante et la résistance mécanique ou aux interférences du mini-jack n'est pas suffisante, HDMI ou mini-HDMI, comme sur le OXI Instruments Pipe (certes, chez eux, c'est pour transmettre du CV/Gate et du signal d'horloge) ?
Robuste, largement répandu, avec détrompeur, plein de broches pour faire du bi-directionnel ou faire passer d'autres signaux avec un seul câble (audio analogique, audio numérique, ...) tout en étant plus souple que le eSATA...
« 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 10/07/2025 à 21:30:36 ]
Will Zégal
77938
Will Zégal
Membre depuis 23 ans
Hors sujet :
RJ45 :
pas cher
hyper répandu
compact
solide
permettant de faire des prises courtes, coudées...
Pas sexy pour deux sous pour des musiciens
- < Liste des sujets
- Charte
- 1
- 2