réactions à la news Les spécifications du MIDI 2.0 sont à présent publiques
- 67 réponses
- 24 participants
- 4 601 vues
- 32 followers
Banshee in Avalon
27934
Administrateur·trice du site
Membre depuis 17 ans
Sujet de la discussion Posté le 26/02/2020 à 12:00:09Les spécifications du MIDI 2.0 sont à présent publiques
La MIDI Association (ou MMA) a mis en ligne cinq documents détaillant les spécifications adoptées en début d’année au NAMM.
Lire la news
Ce thread a été créé automatiquement suite à la publication d'une news pour ce produit. N'hésitez pas à poster vos commentaires ici !
Lire la news
Ce thread a été créé automatiquement suite à la publication d'une news pour ce produit. N'hésitez pas à poster vos commentaires ici !
Beatless
13705
Drogué·e à l’AFéine
Membre depuis 20 ans
11 Posté le 26/02/2020 à 16:22:59
Citation de Emma :
Tous ça, c'est très bien. Mais on désespère de voir la généralisation de l'AT polyphonique et de la vélocité de relâchement sur tous les claviers, alors que ces options existent depuis si longtemps et qu'elles suffisent à égayer le jeu
Oui, c'est pour ça que je garde mon Ensoniq VFX.
Citation de Emma :
Vu le conservatisme obsessionnel compulsif des fabricants de claviers, on va devoir attendre encore 40 ans avant que le MIDI 2.0 ne soit praticable.
C'est pas faux. Je plussoie.
S'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
[ Dernière édition du message le 26/02/2020 à 16:23:31 ]
ClaudeLeBelge
198
Posteur·euse AFfiné·e
Membre depuis 11 ans
12 Posté le 26/02/2020 à 16:24:16
La norme MIDI est une totale anomalie dans un monde dirigé par les $! Pour ceux qui sont nés après, il est bon de rappeler que toutes ces normes se sont mises en place au milieu des années 80 (quand Roland a sorti sa TR-707).
Certaines machines de cette époque étaient construites "comme des tanks" (exemple: Akaï DR-8, 18Kgs) et durent encore, et bien sûr elles communiquent en MIDI 1. La vraie démocratie, c'est ça: pouvoir faire fonctionner ENSEMBLE, les maigres et les gros, les jeunes et les vieux, et je passe sur les couleurs de peau.
Certaines machines de cette époque étaient construites "comme des tanks" (exemple: Akaï DR-8, 18Kgs) et durent encore, et bien sûr elles communiquent en MIDI 1. La vraie démocratie, c'est ça: pouvoir faire fonctionner ENSEMBLE, les maigres et les gros, les jeunes et les vieux, et je passe sur les couleurs de peau.
Beatless
13705
Drogué·e à l’AFéine
Membre depuis 20 ans
13 Posté le 26/02/2020 à 16:29:37
ClaudeLeBelge, l'AES/EBU n'a rien à voir avec le MIDI. La première démo du MIDI 1.0 était sur un Prophet 600.
S'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
Analog_Keys
7020
Je poste, donc je suis
Membre depuis 3 ans
14 Posté le 26/02/2020 à 16:52:47
Citation :
Si je t'aie bien compris les avec cette nouvelle norme 2.0, les prises midi In et Out comme celles du Microfreak vont se généraliser
ça c'est pas une bonne noouvelle...
Made In Breizh
2737
Squatteur·euse d’AF
Membre depuis 20 ans
15 Posté le 26/02/2020 à 19:28:46
Bonjour,
La spécification 2.0 ne définit pas les connecteurs, elle liste simplement l'existant pour rester compatible avec l'existant, notamment 5 Pin DIN cable, USB, New 2 Way UART, Ethernet, OS API, VST, CoreMIDI, MIDI over Bluetooth LE.
Ce que j'ai lu d'intéressant dans la norme c'est :
- Un MIDI 16-bit : ce sera un progrès par rapport au MIDI actuel 7-bit (=128 pas) actuels qui oblige, quand on a besoin de plus de 128 pas, de passer en MIDI étendu en couplant 2 messages MIDI, un MSB (Most Significant Byte) et un LSB (Least Significant Byte) sur un même contrôle. La difficulté, c'est que quand un utilisateur final (et non un programmeur) veut mapper manuellement un logiciel dont l'apprentissage MIDI fonctionne en 7-bit alors que son contrôleur envoie des Control Change en MIDI étendu, son mapping ne fonctionnera que s'il capture l'information MSB et non la LSB, mais ça, il a 1 chance sur 2 d'y arriver, et s'il capture le LSB, le contrôle n'envoie pas la bonne commande au logiciel parce que l'apprentissage de la commande MIDI n'a pas été pensé pour apprendre 2 commandes MIDI en même temps. Le MIDI 16-bit devrait résoudre cette difficulté.
- les profils MIDI : si ça fonctionne, si les profils sont assez ouverts pour couvrir tous les cas possibles, alors on n'aura plus besoin de mapper les contrôleurs MIDI : le contrôleur MIDI enverra son profil, le logiciel lira le profil et saura que cette commande, c'est le volume général, celle là, c'est la vitesse de lecture, celle là, le play de la piste 1 etc..., et le logiciel fonctionnera directement avec le contrôleur MIDI, sans faire de mapping.
- Les formats de paquet : c'est important de les définir parce que le MIDI 1.0 était conçu comme un protocole frugal, donc véhiculant peu de données, mais actuellement on arrive à des paquets de données importants et faute de norme de paquets de données MIDI, on doit mettre des temporisations (=ralentir les transferts) pour espacer les blocs et ne pas perdre de données quand on en envoie un paquet important. Avec la définition de paquet, on va pouvoir à nouveau envoyer des données sans les ralentir simplement en respectant la typologie des paquets.
La spécification 2.0 ne définit pas les connecteurs, elle liste simplement l'existant pour rester compatible avec l'existant, notamment 5 Pin DIN cable, USB, New 2 Way UART, Ethernet, OS API, VST, CoreMIDI, MIDI over Bluetooth LE.
Ce que j'ai lu d'intéressant dans la norme c'est :
- Un MIDI 16-bit : ce sera un progrès par rapport au MIDI actuel 7-bit (=128 pas) actuels qui oblige, quand on a besoin de plus de 128 pas, de passer en MIDI étendu en couplant 2 messages MIDI, un MSB (Most Significant Byte) et un LSB (Least Significant Byte) sur un même contrôle. La difficulté, c'est que quand un utilisateur final (et non un programmeur) veut mapper manuellement un logiciel dont l'apprentissage MIDI fonctionne en 7-bit alors que son contrôleur envoie des Control Change en MIDI étendu, son mapping ne fonctionnera que s'il capture l'information MSB et non la LSB, mais ça, il a 1 chance sur 2 d'y arriver, et s'il capture le LSB, le contrôle n'envoie pas la bonne commande au logiciel parce que l'apprentissage de la commande MIDI n'a pas été pensé pour apprendre 2 commandes MIDI en même temps. Le MIDI 16-bit devrait résoudre cette difficulté.
- les profils MIDI : si ça fonctionne, si les profils sont assez ouverts pour couvrir tous les cas possibles, alors on n'aura plus besoin de mapper les contrôleurs MIDI : le contrôleur MIDI enverra son profil, le logiciel lira le profil et saura que cette commande, c'est le volume général, celle là, c'est la vitesse de lecture, celle là, le play de la piste 1 etc..., et le logiciel fonctionnera directement avec le contrôleur MIDI, sans faire de mapping.
- Les formats de paquet : c'est important de les définir parce que le MIDI 1.0 était conçu comme un protocole frugal, donc véhiculant peu de données, mais actuellement on arrive à des paquets de données importants et faute de norme de paquets de données MIDI, on doit mettre des temporisations (=ralentir les transferts) pour espacer les blocs et ne pas perdre de données quand on en envoie un paquet important. Avec la définition de paquet, on va pouvoir à nouveau envoyer des données sans les ralentir simplement en respectant la typologie des paquets.
ClaudeLeBelge
198
Posteur·euse AFfiné·e
Membre depuis 11 ans
16 Posté le 26/02/2020 à 20:05:29
@Beatless: "ClaudeLeBelge, l'AES/EBU n'a rien à voir avec le MIDI. La première démo du MIDI 1.0 était sur un Prophet 600."
Moi aussi je peux me servir de google, et tu devrais lire 2x avant de poster. Que les 2 normes soient sorties la même année, et qu'elles n'aient rien à voir ensemble, ça c'est toi qui décides. Mais moi je n'ai rien dit de plus.
C'était une époque excitante, où tout changeait d'une année sur l'autre. Moi j'y étais, et toi pas, et voilà. Pourquoi s'attarder là-dessus?
Moi aussi je peux me servir de google, et tu devrais lire 2x avant de poster. Que les 2 normes soient sorties la même année, et qu'elles n'aient rien à voir ensemble, ça c'est toi qui décides. Mais moi je n'ai rien dit de plus.
C'était une époque excitante, où tout changeait d'une année sur l'autre. Moi j'y étais, et toi pas, et voilà. Pourquoi s'attarder là-dessus?
Beatless
13705
Drogué·e à l’AFéine
Membre depuis 20 ans
17 Posté le 26/02/2020 à 22:17:00
x
Hors sujet :Citation de ClaudeLeBelge :Moi j'y étais, et toi pas, et voilà.
Quelle pretention!!!
Tu ne me connais même pas. Prophet 600 et DX7 j'y étais, et même avant si tu veux savoir.
Citation de ClaudeLeBelge :Moi aussi je peux me servir de google
Moi je n'en ai pas eu besoin. Je connais mes classiques. Et bien tu aurais dû le faire.
Ne t'attarde pas.
S'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
skarabee.nc
1099
AFicionado·a
Membre depuis 17 ans
18 Posté le 27/02/2020 à 06:47:00
Rhooo, vous battez pas... De toute façon le premier midi, c'est moi qui l'ai trouvé, à 14 heures.
...non, rien....
Beatless
13705
Drogué·e à l’AFéine
Membre depuis 20 ans
19 Posté le 27/02/2020 à 07:54:52
S'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
Brandski
965
Posteur·euse AFfolé·e
Membre depuis 13 ans
20 Posté le 27/02/2020 à 10:10:35
Citation :
Pense un peu, au lieu de devoir courir l'internet, à la recherche du bon pilote, à chaque fois que tu installes un simple truc (une imprimante) suite à un upgrade (non désiré), si ta nouvelle imprimante de chez Leclerc contenait, sur une petite puce, TOUS les drivers jusqu'à Windows 98 et même avant, comme la vie serait facile, et tes machines (enfin) efficaces? Non, ça c'est réservé aux musiciens, dans le "monde réel" en 64 bits, ça n'existe pas. La vie est un upgrade sans fin?
L'imprimante est le mauvais exemple. Sur Mac en tout cas , l'OS va justement chercher et installer les Drivers tout seul comme un grand !
studio geek - synths nerd - producteur italo, electro, indie dance, EBM
- < Liste des sujets
- Charte