réactions au dossier L'histoire de la plus grande révolution des instruments électroniques
- 48 réponses
- 13 participants
- 2 557 vues
- 19 followers

Red Led

Lire l'article
Ce thread a été créé automatiquement suite à la publication d'un article. N'hésitez pas à poster vos commentaires ici !
- 1
- 2

Will Zégal

(p*** que je déteste ce nom



VE

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 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 microsecondesce qui change un tout petit peu de l'horloge MIDI 1.0 qui était de 24 tops à la noire...) en indiquant à quel moment chaque message MIDI 2.0 est transmis par rapport à cette horloge.
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


.: Odon Quelconque :.

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

On ne pourra pas avoir de configuration automatique (Properties) ou tout ce qui ressortira du MIDI-CI,
D'après ce que j'ai compris, MIDI-CI travaille à partir de "tableaux de propriétés".
Je me demande ce qui empêcherait d'implémenter manuellement (ou par IA comme tu le dis) des tableaux des synthés classiques.
Cela ne permettrait évidemment pas de bénéficier de tous les apports de MIDI 2.0, mais au moins pourrait-on avoir les descriptions directement dans nos stans, même s'il faut sélectionner à la main à quel synthé la piste parle.
Après tout, on le faisait déjà bien avec des "Control Panel" comme permettait d'en créer Cakewalk à un époque (je ne sais pas pourquoi ils ont viré cette fonctionnalité) ce logiciel permet aussi d'affecter des instruments à des ports MIDI (et de définir ainsi automatiquement s'ils sont par exemple GM, GS, GSX...)
On retrouve ainsi directement les CC standards.
J'en veux d'ailleurs terriblement à Steinberg de ne pas avoir intégré la démarche dans VST3. De ce que m'ont expliqué des développeurs, les descriptions de contrôles dans VST, c'est la foire à la saucisse. Non seulement tout le monde peut affecter n'importe quel CC à n'importe quoi, mais il n'y a dans la norme aucune description du type de contrôle (ON/OFF, switch à n positions, potard/fader...). Quant aux noms, tu peux appeler ta fréquence de coupure de filtre "filter cutoff" ou "0985àç82!" ou "tarte à la myrtille". Ce qui rend impossible de réaliser des configurations automatiques de surfaces de contrôles (et qui a été le point faible de l'Automap, pourtant par ailleurs très malin et performant, mais obligeant de fait à faire la première fois ses affectations à la main*).
Steinberg aurait au moins pu corriger ça dans VST3. Cela aurait représenté un grand bond en avant, des années avant MIDI 2.0, et préparé l'avènement de celui-ci.
Peut-être que le projet de MIDI 2.0 les a encouragés à ne se faire ch..., mais que d'années perdues.
[ Dernière édition du message le 23/02/2024 à 12:54:03 ]

Coyote14

Comme le dit Bertrand


BebDigitalAudio

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

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)

BebDigitalAudio

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 :.



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 suitehttps://rven.se/emu-ultra/
Citation :The main DAC gets it I2S data from the outputs of the EMU8000 effects chip. The 8k is actually a sample-based synthesizer in its own right, often found on PC sound cards, but all the sound memory pins are simply left unconnected! It is connected to the regular data and address bus, and receives a single stream audio stream from the FPGA which is hard-wired to the main DAC. The other DACs are connected directly to the FPGA.
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


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...

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


Tu es un homme précieux, Olivier.



BebDigitalAudio

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

(sauf peut-être dans 6 mois quand je serais repassé sur le sujet pour me rafraîchir la mémoire)

VE



BebDigitalAudio


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

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



.: Odon Quelconque :.

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
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...
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 :.

Le DAW utilisé est Multitrack Studio dont la version MIDI 2.0 est prête : https://www.multitrackstudio.com/techspecs.php
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 ?
« 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/01/2025 à 23:19:33 ]

Will Zégal


BebDigitalAudio

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 :.

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

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