réactions à la news Commentaires sur la news : BEB présente UMP-OX, une patchbay / toolbox gratuite pour MIDI 2.0
- 18 réponses
- 6 participants
- 401 vues
- 11 followers
BebDigitalAudio
122
Posteur·euse AFfiné·e
Membre depuis 19 ans
Lire la news
Ce sujet a été créé automatiquement suite à la publication d’une news. N’hésitez pas à poster vos commentaires ici !
Silicon Machine Extended
4752
Squatteur·euse d’AF
Membre depuis 16 ans
coldwave
1296
AFicionado·a
Membre depuis 6 ans
Braillerie Prod.
245
Posteur·euse AFfiné·e
Membre depuis 2 ans
BebDigitalAudio
122
Posteur·euse AFfiné·e
Membre depuis 19 ans
BebDigitalAudio
122
Posteur·euse AFfiné·e
Membre depuis 19 ans
Citation de Braillerie Prod. :
En effet c'est magnifique. peut-il aussi translater des midi cc ? du genre cc1 en entrée ressort en cc4 ?
Pour répondre directement à ta question : oui, il peut le faire, en passant par le mécanisme des scripts Lua associés aux routeurs UMP de sortie. Ca fait partie des choses pour lesquelles je dois faire un tutoriel pour expliquer comment coder ce genre de choses.
Pour faire simple, on peut associer à chaque routeur UMP de sortie (qui va vers un port MIDI, un port RTP-MIDI, un port Network UMP, etc...) un script en Lua. Chaque message UMP (et donc MIDI 1.0) qui atteint le routeur peut être interprété et modifié à volonté. On peut changer un CC1 en CC4, ou transformer un Note On en Control Change, etc...
Pour accéder à cette fonction, il suffit de faire un clic droit sur le routeur de sortie qu'on veut scripter, puis choisir "Set output filter script". Dans le dialogue qui s'affiche, il suffit de choisir le script Lua (à écrire soi-même...
) et de valider. Le script peut être testé sur ce même dialogue.Les scripts Lua pour UMP-OX s'écrivent sous la forme
function filter(n1, n2, n3, n4)
-- n1 à n4 représentent les quatre mots de 32 bits formant un message UMP
-- la fonction peut agir sur les quatre mots à volonté pour modifier le message
-- la ligne ci-dessous est obligatoire pour renvoyer le message UMP vers UMP-OX
return n1, n2, n3, n4
end
Benoit
.: Odon Quelconque :.
11977
Drogué·e à l’AFéine
Membre depuis 23 ans
Excellent ! J'imagine que le MIDI 2.0 ne sera supporté sous Windows (11) que quand la mise à jour définitive sera disponible ?
Merci Benoit.
Merci Benoit.
« 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)
BebDigitalAudio
122
Posteur·euse AFfiné·e
Membre depuis 19 ans
Citation de .: Odon Quelconque :. :
Excellent ! J'imagine que le MIDI 2.0 ne sera supporté sous Windows (11) que quand la mise à jour définitive sera disponible ?
Merci Benoit.
Bonjour Odon,
alors, pour être franc, le sujet de MIDI 2.0 sous Windows est assez polémique. Initialement, il avait été annoncé que le service MIDI2 serait disponible sous Win10 et Win11... sauf qu'apparemment, la décision a été prise de retirer Windows 10 du panel et de ne garder que Windows 11 dans le giron de la compatibilité MIDI 2 (qui a dit que c'est une manière comme une autre de forcer les récalcitrants à passer sous Windows 11 ?
)Sauf que la sortie officielle du service MIDI 2 (car le système de drivers sera remplacé par un service sous Windows) est maintenant annoncée pour février 2026, lors de la prochaine "grosse" mise à jour... sauf annonce contraire entre-temps
C'est une des raisons pour lesquelles j'ai inclus Network MIDI 2.0 sous forme native dans UMP-OX, pour ne pas être tributaire du driver Microsoft (même sujet concernant le driver Apple soit-dit en passant). En gros, si on choisit le profil "Network MIDI 2.0" dans UMP-OX pour des routeurs, ceux-ci utilisent un moteur interne et non pas un driver externe, ce qui permet de commencer à manipuler du MIDI 2.0 dès maintenant
BebDigitalAudio
122
Posteur·euse AFfiné·e
Membre depuis 19 ans
Will Zégal
78278
Will Zégal
Membre depuis 23 ans
Merci Benoît
.: Odon Quelconque :.
11977
Drogué·e à l’AFéine
Membre depuis 23 ans
Merci Benoit pour ton travail et pour toutes ces infos.
Pete a fait des réponses peut être plus corporate, mais comme à son habitude très bien argumentées pour expliquer pourquoi personne n'a souhaité que Windows 10 bénéficie d'une mise à jour risquant de compromettre d'autres éléments de l'OS qui ne pourraient jamais être corrigés.
https://gearspace.com/board/showpost.php?p=17571424&postcount=293
Et que mettre à disposition la pile MIDI 2.0 et les nouveaux pilotes USB MIDI aux risques et périls des utilisateurs d'un OS qui n'est plus officiellement supporté n'était pas possible non plus, faute pré-requis techniques qui n'existent pas dans Win10 :
https://gearspace.com/board/showpost.php?p=17571982&postcount=298
Il a aussi écrit que le connecteur propriétaire évoqué un temps, et dont tu nous avait fugacement montré un proto (USB-C avec leds d'état) était abandonné.
https://gearspace.com/board/showpost.php?p=17658840&postcount=144
Citation de BebDigitalAudio :
alors, pour être franc, le sujet de MIDI 2.0 sous Windows est assez polémique. Initialement, il avait été annoncé que le service MIDI2 serait disponible sous Win10 et Win11... sauf qu'apparemment, la décision a été prise de retirer Windows 10 du panel et de ne garder que Windows 11 dans le giron de la compatibilité MIDI 2 (qui a dit que c'est une manière comme une autre de forcer les récalcitrants à passer sous Windows 11 ?
Pete a fait des réponses peut être plus corporate, mais comme à son habitude très bien argumentées pour expliquer pourquoi personne n'a souhaité que Windows 10 bénéficie d'une mise à jour risquant de compromettre d'autres éléments de l'OS qui ne pourraient jamais être corrigés.
https://gearspace.com/board/showpost.php?p=17571424&postcount=293
Citation de Pete_Brown :
We weren't able to hit the dates to back-port to Windows 10. Additionally, our partners were clear that pushing it to Windows 10 last-minute would be a Very Bad Idea, because we would have no way to fix any bugs we introduce there. We would potentially break MIDI in Windows 10 for everyone, forever.
So it's Windows 11 only.
Et que mettre à disposition la pile MIDI 2.0 et les nouveaux pilotes USB MIDI aux risques et périls des utilisateurs d'un OS qui n'est plus officiellement supporté n'était pas possible non plus, faute pré-requis techniques qui n'existent pas dans Win10 :
https://gearspace.com/board/showpost.php?p=17571982&postcount=298
Citation :
Everything is open source with the exception of the OS-level changes that had to be made to support the new MIDI 2.0 driver and the integration with the new service.
If those were not required, you could theoretically install it all yourself on latest Windows 10. But our old USB Audio Class 2 driver claimed MIDI 2.0 compatibility and prevents MIDI 2.0 device detection without the USB stack changes in place. The new driver also use the Audio Class eXtensions for driver development, which are not in Windows 10.
I actually looked at what it would take to do exactly what you're saying, and it turned out not to be reasonably possible. I really did want to find a way to enable this for folks even if they were willing to do without the USB MIDI 2.0 part. But in addition to the driver, there are several other internal services and code paths that had to be changed to allow the new service to take over everything for MIDI 1.0 for device enumeration and communication. Anything that's in our open source repo is reasonable to adapt, but AudioEndpointBuilder, WinRT MIDI 1.0, some of the internal WinMM stuff are tied to the OS directly, with no way to offer an alternative.
Il a aussi écrit que le connecteur propriétaire évoqué un temps, et dont tu nous avait fugacement montré un proto (USB-C avec leds d'état) était abandonné.
https://gearspace.com/board/showpost.php?p=17658840&postcount=144
Citation :
The USB-C-like connector was for the proposed serial protocol -- a replacement for DIN and unrelated to USB itself. But that has been shelved. It was an investigation and prototype, and not yet a standard.
For many use-cases, the Network MIDI 2.0 transport, which works over Ethernet is the better choice. It's faster, goes over longer distances, and uses current standards. Most microcontrollers these days already have just about everything that's needed for Ethernet connectivity.
« 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 17/12/2025 à 17:05:06 ]
BebDigitalAudio
122
Posteur·euse AFfiné·e
Membre depuis 19 ans
@Odon Quelconque,
merci pour avoir apporté ces éclairages complémentaires. Comme tu le dis, Pete Brown a fourni des arguments tout à fait justifiés.
Sur ce point, je dois apporter un éclairage supplémentaire, car l'utilisation du protocole série reste d'actualité, il a même été remis sur la table lors d'une réunion avec le MMA il y a quelques semaines. Pour faire simple, plusieurs membres du groupe de travail "Transport" (qui a produit notamment la spécification MIDI Network 2.0) ont continué à travailler sur le sujet, notamment sur la définition du protocole d'encapsulation des données.
Le sujet du connecteur est en revanche un peu délicat. A l'origine, un premier connecteur avait été proposé, mais celui-ci était "propriétaire", ce qui posait plusieurs problèmes. Plusieurs membres ont proposé d'utiliser alors le connecteur USB-C, car ce dernier comporte des lignes dédiées à la communication série et dont le rôle est défini par la spécification USB-C. Mais le problème est que la propriété intellectuelle de ce connecteur appartient à l'USB-IF (le groupe de professionnels qui gèrent toutes les spécifications USB), et que l'utilisation de ces lignes pour un protocole autre que celui défini par l'USB-IF nécessite une autorisation/dérogation de la part de l'USB-IF.
Et donc en l'état, c'est le connecteur qui reste le caillou dans la chaussure du protocole série pour MIDI 2.0
merci pour avoir apporté ces éclairages complémentaires. Comme tu le dis, Pete Brown a fourni des arguments tout à fait justifiés.
Citation :
The USB-C-like connector was for the proposed serial protocol -- a replacement for DIN and unrelated to USB itself. But that has been shelved. It was an investigation and prototype, and not yet a standard.
Sur ce point, je dois apporter un éclairage supplémentaire, car l'utilisation du protocole série reste d'actualité, il a même été remis sur la table lors d'une réunion avec le MMA il y a quelques semaines. Pour faire simple, plusieurs membres du groupe de travail "Transport" (qui a produit notamment la spécification MIDI Network 2.0) ont continué à travailler sur le sujet, notamment sur la définition du protocole d'encapsulation des données.
Le sujet du connecteur est en revanche un peu délicat. A l'origine, un premier connecteur avait été proposé, mais celui-ci était "propriétaire", ce qui posait plusieurs problèmes. Plusieurs membres ont proposé d'utiliser alors le connecteur USB-C, car ce dernier comporte des lignes dédiées à la communication série et dont le rôle est défini par la spécification USB-C. Mais le problème est que la propriété intellectuelle de ce connecteur appartient à l'USB-IF (le groupe de professionnels qui gèrent toutes les spécifications USB), et que l'utilisation de ces lignes pour un protocole autre que celui défini par l'USB-IF nécessite une autorisation/dérogation de la part de l'USB-IF.
Et donc en l'état, c'est le connecteur qui reste le caillou dans la chaussure du protocole série pour MIDI 2.0
[ Dernière édition du message le 18/12/2025 à 15:02:25 ]
Will Zégal
78278
Will Zégal
Membre depuis 23 ans
Le RJ45 ne ferait pas l'affaire ?
Sinon, c'est l'occasion de recycler les connecteurs FireWire.
Sinon, c'est l'occasion de recycler les connecteurs FireWire.
.: Odon Quelconque :.
11977
Drogué·e à l’AFéine
Membre depuis 23 ans
Un connecteur propriétaire aurait pu constituer une rente pour la MMA.
Sinon, il y a le GPMI, dont une composante USB-C existe, mais qui est sans doute overkill pour de la communication série :
https://en.wikipedia.org/wiki/GPMI
Si tu as le temps, pourrais tu préciser quel cas d'usage nécessite de maintenir un protocole série sur un nouveau connecteur, qui ne serait pas couvert par l'USB pour les courtes distances ou le RJ45 pour le reste ?
Sinon, il y a le GPMI, dont une composante USB-C existe, mais qui est sans doute overkill pour de la communication série :
https://en.wikipedia.org/wiki/GPMI
Citation de BebDigitalAudio :
l'utilisation du protocole série reste d'actualité, il a même été remis sur la table lors d'une réunion avec le MMA il y a quelques semaines.
Si tu as le temps, pourrais tu préciser quel cas d'usage nécessite de maintenir un protocole série sur un nouveau connecteur, qui ne serait pas couvert par l'USB pour les courtes distances ou le RJ45 pour le reste ?
« 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 19/12/2025 à 12:21:11 ]
BebDigitalAudio
122
Posteur·euse AFfiné·e
Membre depuis 19 ans
Citation :
Si tu as le temps, pourrais tu préciser quel cas d'usage nécessite de maintenir un protocole série sur un nouveau connecteur, qui ne serait pas couvert par l'USB pour les courtes distance ou le RJ45 pour le reste ?
Les grands esprits se rencontrent... J'y ai justement pensé et je me suis connecté ce matin pour parler de ça (et du coup, merci pour la transition Odon
comme on dit à la télé)Techniquement, quand Pete affirme que la plupart des micro-contrôleurs ont assez de ressources pour faire tourner une connexion Ethernet, ce n'est pas faux (encore qu'il faille modérer le concept de "la plupart"...)
Le problème avec Ethernet, c'est que ce n'est pas uniquement du logiciel, il y a du matériel à ajouter. A minima, sur un micro équipé d'un MAC (Medium Access Controller), il faut ajouter :
- un contrôleur PHY
- un circuit à base de transformateur Ethernet
- une connectique RJ45
- et pas mal de composants passifs annexes
Concrètement, ça alourdit déjà pas mal la facture, avec un impact sur le prix final de plusieurs dizaines d'euros, selon notamment la qualité des composants. Il suffit de prendre un exemple comme les Korg Volca pour comprendre l'impact sur le prix final. Soit dit en passant, c'est exactement le problème auquel j'avais dû faire face quand j'ai développé les modules Horus il y a quelques années (https://www.youtube.com/watch?v=VCUCrNaFwxo). Le coût de l'interface Ethernet représentait à lui seul 50% du prix de vente final du produit... Et c'est ce qui a plombé le développement de l'Horus...
Par ailleurs, la communication sur Ethernet nécessite pas mal de ressources en RAM. Il faut donc utiliser des composants avec plus de mémoire RAM, qui sont plus chers. De même, une interface Ethernet doit être configurée, ce qui impose soit la présence d'une interface utilisateur physique, soit un développement logiciel sous forme d'un serveur Web, soit sous forme d'un outil de configuration.
Le développement et l'intégration d'une pile de communication Ethernet / IP n'est pas non plus quelque chose qui se fait sur un coin de table, donc nouvel impact sur le prix de vente du produit. Il n'y a que sur les produits très grand public avec des volumes de production énormes qu'on peut diluer ce coût de développement logiciel, ou sur des produits pour lesquels le coût de l'interface Ethernet reste minime ou supportable par rapport au prix de vente final
Sans oublier le fait que certains produits sont développés en poussant les composants à leurs limites. Rajouter le traitement de la communication Ethernet va imposer de passer sur des composants plus performants et potentiellement plus chers, faute de quoi les performances de la communication Ethernet seront impactées (et concrètement, le premier impact sera la latence sur le traitement du MIDI)
Et quand je parle de la qualité des composants, c'est basé sur mon expérience personnelle : toute souplesse sur le choix des composants se paie rapidement. Il suffit de voir que certains connecteurs RJ45 d'entrée de gamme ne sont garantis par le fabricant que pour 50 connexions/déconnexions...
Quant à la comparaison avec USB, plusieurs problèmes se posent :
- on devient tributaires soit des drivers système (il suffit de regarder les innombrables discussions sur les performances des drivers natifs), soit du développement d'un driver propriétaire
- le développement d'une interface USB est très lourd en termes de compétences (il suffit de regarder le code source d'une pile open source comme TinyUSB pour comprendre)
- tout produit USB doit disposer d'un VID/PID (et donc payer une cotisation annuelle à l'USB-IF)... (Oui, je sais, pas mal de constructeurs situés dans un pays peu réputé pour le respect de la propriété intellectuelle se moquent de cette contrainte et utilisent des identifiants non déclares
)Donc oui, il existe selon moi un segment de marché où une interface sérielle (ou équivalente...
- trop tôt pour en parler ici) se justifie encore.[ Dernière édition du message le 19/12/2025 à 11:45:10 ]
Will Zégal
78278
Will Zégal
Membre depuis 23 ans
.: Odon Quelconque :.
11977
Drogué·e à l’AFéine
Membre depuis 23 ans
Citation de BebDigitalAudio :
Donc oui, il existe selon moi un segment de marché où une interface sérielle (ou équivalente...
Super post !
Merci
« 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 19/12/2025 à 12:41:14 ]
BebDigitalAudio
122
Posteur·euse AFfiné·e
Membre depuis 19 ans
Citation de Will Zégal :
Concernant Ethernet, je n'avais pas connaissance que son coût fut aussi élevé.
Juste pour clarifier : les coûts que j'évoquais pour une interface Ethernet sont ceux que l'acheteur voit (donc en incluant les marges revendeurs / distributeurs). C'est pour ça que je parlais également des coûts liés au développement soft et pas uniquement le coût des composants, car les choses étant ce qu'elles sont, pour qu'une société soit viable, il faut que tous les coûts soient reportés (y compris, et ce n'est pas rien, les coûts liés au support technique après vente soit dit en passant)
Ce qui met en lumière d'ailleurs un sujet très différent mais connexe : le fait que des produits à très faible prix soient disponibles sur le marché, et qui amène à se poser la question de "mais comment font-ils pour vendre un machin moins cher que le prix des composants qu'il y a dedans ?"
Dans pas mal de cas, on se retrouve avec des produits construits autour de composants de mauvaise qualité, et dont le développement consiste surtout à piquer ce que d'autres ont conçu bien avant eux (donc coût de développement hardware limité au strict minimum) et/ou en récupérant du code source développé par d'autres (qui ont passé des mois à l'écrire) qu'ils ont juste à recompiler
Le problème est alors que ces produits biaisent l'image des produits "originaux" qui apparaissent comme vendus avec des marges de malade (alors que le concepteur original essaie juste de rentrer dans ses frais)
Et cerise sur le gâteau : j'ai également eu à faire face dans ma carrière professionnelle à des "kamikaze" qui vendent des produits avec une marge nulle (voire en perdant de l'argent - bien que officiellement, ce soit interdit), et dont l'optique est de tuer la concurrence en apparaissant moins chers lors des phases de lancement de leurs produits (le produit a prix cassé disparaissent par la suite, dès que la concurrence est suffisamment affaiblie).
Will Zégal
78278
Will Zégal
Membre depuis 23 ans
- < Liste des sujets
- Charte