MIDI 2.0

[Thomasch]

Aktuell kann man die 3 Controller, die Korg Desktops nutzen und ggf. ab Ableton Live 12 "anständig". Nervt die Hersteller, dass ihr das wollt. Je mehr das passiert, desto mehr werden sie es einbauen und dies bringt auch Hersteller dazu es mehr zu unterstützen.

Ich hab mir am WE nun auch die Beta von Live 12 installiert, hab aber bisher noch keine Hinweise zu MIDI 2.0 gefunden.
Ich hab allerdings auch keine 2.0 Hardware.
Google spuckt leider auch keine Infos bzgl Ableton Live 12 und MIDI 2.0 aus.

 

[khz]

Operating Systems:

• MIDI 2.0 on Linux:
  MIDI 2.0 on Linux — The Linux Kernel documentation 1

Frameworks:

• JUCE is working on their MIDI 2.0 implementation, it will be there in v7.1:
  GitHub - juce-framework/JUCE: JUCE is an open-source cross-platform C++ application framework for desktop and mobile applications, including VST, VST3, AU, AUv3, LV2 and AAX audio plug-ins.
• Cross Platform MIDI C++ Library:
  GitHub - jcelerier/libremidi: A modern C++ MIDI real-time & file I/O library. Supports Windows, macOS, Linux and WebMIDI. 1

Hardware:

• Korg Keystage:
  Keystage - POLY AT MIDI KEYBOARD | KORG (EU - DE)
• Roland A88 MkII:
  Roland - A-88MKII | MIDI Keyboard Controller

##############################################################################

MIDI 2.0 - It is really happening! What you can use right now, what is still missing?

 

[microbug]

Ja, es gab etliche Kenner, die dem keine Chance gegeben haben

Ich behaupte nach wie vor, daß es sich nicht (oder nur seeehr langsam) durchsetzen wird. MIDI 1.0 war ganz schnell überall, weil einfach zu implementieren - das ist hier halt nicht der Fall, und viele Hersteller scheuen einfach den Aufwand.

 

[Moogulator]

Ich hab mir am WE nun auch die Beta von Live 12 installiert, hab aber bisher noch keine Hinweise zu MIDI 2.0 gefunden.
Ich hab allerdings auch keine 2.0 Hardware.
Google spuckt leider auch keine Infos bzgl Ableton Live 12 und MIDI 2.0 aus.

Ja, dieses Problem hatte ich auch. Daher würde mich freuen, wenn jemand das konkret gesichert sagen kann.
Es gibt natürlich neue MIDI Features in 12, aber ich habe auf der Site kein einziges Mal den Begriff MIDI 2.0 gefunden.

Ich behaupte nach wie vor, daß es sich nicht (oder nur seeehr langsam) durchsetzen wird. MIDI 1.0 war ganz schnell überall, weil einfach zu implementieren - das ist hier halt nicht der Fall, und viele Hersteller scheuen einfach den Aufwand.

Ja, rasant ist es ja auch jetzt nicht.
Aber es ist zumindest so, dass das Protokoll von einigen nicht unwichtigen Herstellern wirklich angenommen wird.
Das ist ein Fortschritt.

Mir geht das, die Marslandung, die Einigung der Welt und die positiven Möglichkeiten auch zu langsam.

 

[juhunet]

einigen nicht unwichtigen Herstellern

Zumindest beschäftigt man sich auch bei Waldorf (Quantum und Iridium) bereits mit der Implementation von Midi 2.0.

 

[Moogulator]

Wir reden über MIDI 2.0 (21:05)

 

[ppp]

Es gibt (leider) kein Midi 2.0 in Live 12. Hat auch niemand niemals nirgendwo behauptet.

 

[GeoTeknique]

Der Thread-Verlauf inkl. Datumsangabe sollte mal an die MIDI-Association geschickt werden

 

[2bit]

Der Thread-Verlauf inkl. Datumsangabe sollte mal an die MIDI-Association geschickt werden

Die rollen jetzt wohl wirklich von alleine weiter...

...ich hab nämlich gerade noch mal eine Suchmaschine zum Thema "Midi 2.0" bemüht und bin dabei über zwei Videos von der MIDI-Association gestolpert, die zwar schon auf YT gelistet sind, aber erst am Freitagabend (20:30 bzw. 23:00 Uhr) freigeschaltet werden.




Die Beschreibung zum zweiten Video ist auch recht üppig:

Key members of The MIDI Association have come together to provide OPen Source tools and code to make it easier for companies and individuals to develop MIDI 2.0 products. They held a panel discussion at Winter NAMM 2024.

Here is a partial list of the tools and code available.

MIDI 2.0 Workbench

The MIDI 2.0 Workbench is a free tool to help developers develop, debug (and deploy) MIDI 2.0 Applications and Devices. It runs on Windows, Mac and Linux. The Workbench connects to your device or software, to test various MIDI 2.0 implementation features against official specifications. The MIDI 2.0 Workbench is the only automated tool that generates the MIDI 2.0 Compliance Checklist required to license the MIDI 2.0 Logo from the MIDI Association. The MIDI 2.0 Workbench is currently available as source code for you to compile. We will release binaries shortly.

AmeNote ProtoZOA and USB MIDI 2.0 Device
The AmeNote ProtoZOA hardware platform is a flexible prototyping tool for MIDI 2.0 and is the standard testing device chosen by and funded in part by the MIDI Association. Open source firmware provides MIDI 2.0 interfaces and functions for developers to use in their own hardware and software products. ProtoZOA provides a USB MIDI 2.0 Class Compliant Device on a Raspberry Pico, designed specifically to jump-start prototyping and validation of Universal MIDI Packet (UMP) functions and fuel the MIDI 2.0 revolution. ProtoZOA integrates closely with the MIDI 2.0 Workbench.

Tiny USB MIDI 2.0 Device
This is a Tiny USB Device driver for USB MIDI 1.0 and USB MIDI 2.0 as a unified device. Allows implementor to create hardware MIDI devices which are fully compliant with USB Device Class specifications. Includes the fallback mechanism from 2.0 to 1.0 as defined in USB MIDI 2.0.

USB MIDI 2.0 Descriptor Builder
This is tool for easily creating valid descriptors for USB MIDI 2.0 Devices, which are so easy to get wrong. Fill in properties in a form to generate an output of the necessary descriptors. Supports the tusb_ump library, a USB Device used in the ProtoZOA, and the Linux MIDI2 Gadget Driver.

ni-midi2
The library provides the basic functionality of UMP 1.1 and MIDI-CI 1.2 by providing base classes for all UMP 1.1 packet types, (Universal) System Exclusive messages and MIDI-CI messages. There are concrete types for controllers, velocity and pitch, plus type aliases for common message field types. Mathematical operators allow to do integer / fixed point math on pitches and controllers, type constructors allow initialization with values of different resolution. Conrete instances of packets or messages are created using factory functions. Incoming packets and messages are inspected using data views. The library is completed by a number of helper functionalities dealing with conversion from / to MIDI 1 byte stream data format, collecting sysex messages and more.

AM_MIDI2.0Lib
This is a general purposes Library for building MIDI 2.0 Devices and Applications. This library is targeted to work on everything from Arduinos through to large scale applications. It provides foundational building blocks, processing, and translations needed for most MIDI 2.0 Devices and Applications.

*Note: This MIDI2 Developer Collaboration is not a project of the The MIDI Association, but was founded by key participants in the development of MIDI 2.0, working as members of the MIDI Association. The MIDI 2.0 Logo is a registered trademark of the MIDI Association, used under license. The M2 Logo is a trademark of the MIDI2 Developer Collaboration at MIDI2.dev.

 

[microbug]

Ja, rasant ist es ja auch jetzt nicht.
Aber es ist zumindest so, dass das Protokoll von einigen nicht unwichtigen Herstellern wirklich angenommen wird.
Das ist ein Fortschritt.

Das Problem war ja bisher, daß der Standard zwar existierte, aber jeder Hersteller den Code (Libraries) dafür selbst entwickeln mußte (der ja deutlich komplexer ist als das klassiche MIDI), und das haben viele gescheut. Das haben die dann wohl auch eingesehen und daher jetzt diese OpenSource Libraries gebaut. Sowas kenne ich aus dem Embedded Bereich (mit dem wir es ja hier ebenfalls zu tun haben, wenns um Hardwaresysnths geht), dort gibts von den Herstellern auch Beispielapplikationen bzw Code-Libraries, damit man nicht bei Adam und Eva anfangen muß. Ich rede jetzt aber nicht von Raspberry Pi oder Arduino, sondern von den Multicore-ARMs diverser Hersteller und auch die davor besonders in Japan sehr verbreiteten H8, SuperH und R8/M16, die aber heute eigentlich kaum noch eine Rolle spielen.

 

[verstaerker]

habs noch nicht geschaut, aber ich glaube das wird interessant

 

[Makabäer]

Wäre MIDI vergleichbar mit Open-Source-Projekten, verliefe die Entwicklung deutlich schneller. Ein Hersteller, im besten Fall ein MA-Key-Member, entwickelt etwas neues, schickt es an MA, dort wird entschieden, ob es in den Standard übernommen wird, falls dem so ist folgt eine Veröffentlichung, fertig.

 

[verstaerker]

Wäre MIDI vergleichbar mit Open-Source-Projekten, verliefe die Entwicklung deutlich schneller. Ein Hersteller, im besten Fall ein MA-Key-Member, entwickelt etwas neues, schickt es an MA, dort wird entschieden, ob es in den Standard übernommen wird, falls dem so ist folgt eine Veröffentlichung, fertig.

außer es wäre ein Open-Source-Projekte das hunderte Entwickler, Hersteller beeinflusst .. auf 40 Jahre Geschichte zurückblickt und tausende Geräte zu denen es kompatibel sein soll berücksichtigt

damals als Dave Smith das entworfen hat , musste er auf Niemanden Rücksicht nehmen. Er hat halt was entwickelt um seine Synth zu steuern.

 

[Cello]

Wäre MIDI vergleichbar mit Open-Source-Projekten, verliefe die Entwicklung deutlich schneller. Ein Hersteller, im besten Fall ein MA-Key-Member, entwickelt etwas neues, schickt es an MA, dort wird entschieden, ob es in den Standard übernommen wird, falls dem so ist folgt eine Veröffentlichung, fertig.

Danke an Dave Smith und sein Konsortium, dass die Industrie auf einen Nenner brachte

 

[Makabäer]

außer es wäre ein Open-Source-Projekte das hunderte Entwickler, Hersteller beeinflusst .. auf 40 Jahre Geschichte zurückblickt und tausende Geräte zu denen es kompatibel sein soll berücksichtigt

damals als Dave Smith das entworfen hat , musste er auf Niemanden Rücksicht nehmen. Er hat halt was entwickelt um seine Synth zu steuern.

Klar, damals, aber seitdem hat sich sehr viel getan. Den MIDI-Standard schrittweise zu erweitern anstatt auf einen Schlag sehr viel zu ändern, das dann von allen Herstellern sehr zeitverzögert umgesetzt wird, brächte auch heute mehr sinnvolle und weniger sinnlose Neurungen (sinnlos finde ich beispielsweise 32000 Velocitystufen, 256 hätten absolut gereicht, und selbst diese könnten nur die wenigsten Pianisten spielen).

 

[microbug]

Danke an Dave Smith und sein Konsortium, dass die Industrie auf einen Nenner brachte

Wobei Dave Smith bei MIDI weder den Optokoppler noch Dynamikinformationen drin hatte. Beides kam von ehemaligen ARP-Leuten Philipp Dodds und Paul DeRocco.

 

[verstaerker]

(sinnlos finde ich beispielsweise 32000 Velocitystufen, 256 hätten absolut gereicht, und selbst diese könnten nur die wenigsten Pianisten spielen).

es macht aber vermutlich überhaupt keinen Unterschied ob man die 7 bit nun auf 8 bit umstellt oder gleich auf 32 bit (velocity hat glaube 16 bit bekommen und somit 64000 Stufen)

 

[Makabäer]

es macht aber vermutlich überhaupt keinen Unterschied ob man die 7 bit nun auf 8 bit umstellt oder gleich auf 32 bit (velocity hat glaube 16 bit bekommen und somit 64000 Stufen)

Stimmt, es waren 16 Bit, nicht 15, falsche Erinnerung. Bei manch anderen Dingen, bei denen eine Erweiterung sinnvoll gewesen wäre, ist man jedoch bei sieben bzw. vierzehn Bit geblieben.

 

[verstaerker]

bei denen eine Erweiterung sinnvoll gewesen wäre, ist man jedoch bei sieben bzw. vierzehn Bit geblieben.

hast du Beispiele wo man bei 7 bit geblieben ist und wo 14 bit nicht ausreichen? Weil generell kann das Protokoll 32 bit. Ich denke da könnte man, im Zweifel auch noch nachjustieren.

 

[Makabäer]

hast du Beispiele wo man bei 7 bit geblieben ist und wo 14 bit nicht ausreichen? Weil generell kann das Protokoll 32 bit. Ich denke da könnte man, im Zweifel auch noch nachjustieren.

Ich bin gerade am Suchen, da mir kein konkretes Beispiel einfällt.

Edit: Ich bin die Specs noch einmal durchgegangen. Sie scheinen mittlerweile alles auf mindestens acht Bit erweitert zu haben, abgesehen von den MIDI-Gruppen und den Kanälen pro Gruppe (jeweils sechzehn). Wobei es Gruppen ja vorher überhaupt nicht gab, was aber egal ist, da ein MIDI-Interface mit sechzehn Ports im Endeffekt auch nichts anderes ist.

 

[Moogulator]

Mir war nicht klar, dass die JETZT erst das eigentliche Protokoll für schnelle UDP Übertragungen machen.
MIDI Capability Inquiry (MIDI-CI), Version 1.1

			Dies ist was schon durch ist und klar:
			5PinDIN cable,USB, New 2 WayUART, Ethernet,OS API, VST,CoreMIDI	A MIDI-CI Discoveryestablishes the pairing ofan Input and Output forBidirectionalCommunication betweenDevices, independent ofhardware or softwareconnection medium.

DH - MIDI 2.0 wird erst wirklich vollständig, wenn das alles mit durch geht, denn Ethernet und Direktverbindungen wie sie im Video beschrieben werden sind ja genau das was man will. Das ist schon schade, dass sich quasi nur so wenig Leute um so etwas wichtiges kümmern - die laden ja geradezu alle ein und die Sache wäre sicher bald und schneller durch wenn sich die Korgs und Rolands dieser Welt damit befassen würden.

Die jetzigen MIDI Leute sind ja eher von kleinen Firmen die das voran treiben. Nicht ,dass Google klein wäre - aber Bome und Kiss Box sind eigentlich "kleine" Buden. Es ist trotzdem super, dass OS damit verbunden ist - hoffe der Apfel und der MS hören da zu und machen mit. Das wird dann sicher vor 2025 nichts - aber da es easy ist aus technischer Sicht, werden sie es wohl hinbekommen.

Ja, natürlich gibt es die Basics wie Anzahl und Adressen schon - das ist auch wichtig, aber aktuell liefe das alles über das normale TCP IP.
MIDI 2 setzt fast immer auf 16-32Bit. je nach Bereich. CCs sind also sehr hoch aufgelost und es gibt für JEDEN Synth genug um ALLE Parameter anzusprechen - wirklich ausnahmslos, auch additive Synths mit 65535 Bändern könnte man in Echtzeit steuern!
Also haben wir meist 65535 als Wertebereich und Adressbereich für kleinere Sachen wie Velocity, aber 32Bit für alles andere. Es gibt aber auch eine Art Quality of Service Request wo Geräte in mehreren Stufen ansagen können, was sie leisten und wie weit sie kommen.

Profile ID Byte 5 Profile Level	Profile Support Level
0x00	Partial
0x01	Minimum Required
0x02-7E	Minimum Required plus optional, Extended Feature Sets as defined by the Profile specification.
0x7F	Highest Possible

Die ID zB hat heute 5 Byte 3 SysEx IDs und 2 Spezial IDs gegenüber einem einzigen vorher.
7F ist die höchste MIDI Adresse, also 127 "MIDI Ports". Es gibt aber auch noch Groups und deshalb gibt es am Ende 256. Sollte reichen.
Da müsste sogar ein Bernie mit auskommen können.
Kanäle sind nach wie vor aber 16 (0F) - wie gesagt in Groups organisiert (16 gibts) = 256.
Sicher auch wegen Kompatibelität.
Vieles wird also so gemacht wie man das kennt - nur mit mehr Datenplatz.

Aber richtig spannend in 2.0 ist das hier

MIDI-CI Device – A Device that has the ability to act as a Responder that replies to inquiries received from an Initiator. The ability to act as an Initiator is recommended but optional.

Sieht so aus (schon verabschiedet)

Value	Parameter
F0	System Exclusive Start
7E	Universal System Exclusive
1 byte	Device ID: Source or Destination (depending on type of message) 7F = to/from MIDI Port 00-0F = to/from MIDI Channels 1-16 10-7E = Reserved
0D	Universal System Exclusive Sub-ID#1: MIDI-CI
1 byte	Universal System Exclusive Sub-ID#2: Category and Type of MIDI-CI Message 0x00-0F Reserved 0x10-1F Protocol Negotiation Messages 0x20-2F Profile Configuration Messages 0x30-3F Property Exchange Messages 0x40-6F Reserved 0x70-7F Management Messages
1 byte	MIDI-CI Message Version/Format
4 bytes	Source MUID (LSB first*)
4 bytes	Destination MUID (LSB first*)
nb bytes	Data. Includes any necessary fields to suit the needs of each type of MIDI-CI message.
F7	End Universal System Exclusive

Das sind quasi Geräte und Daten die überall drauf gesetzt werden können und ausgehandelt werden, da wird es unfassbar viel an Controller und krassen Synthesen geben die das nutzen werden oder sollten, denn damit wäre ein Osmose Echtzeit Controller über MPE hinaus.

Man sieht - das ist schon dicker als ein normales MIDI 1.0. Und das sind nur die CI Messages.
Da geht also theoretisch viel - man wird wohl sehen ob da ein Microcontroller oder ein dicker Synth dahinter sitzt und ob das eher so gemacht wird wie zB bei Korg immer mal gespart wurde und dann gar nicht mehr viel Platz für MIDI und CCs - oder eben nicht. Das wird in Zukunft extrem viel wichtiger werden was die dafür nutzen. Heute ist ja ein Cortex ARM Chip eher normal geworden selbst für kleine Geräte.

MIDI Transport – Carries MIDI data between Bidirectional Endpoints. Acts as MIDI-CI Proxy for Endpoints whenever necessary. Passes both MIDI 1.0 and MIDI 2.0 Protocol messages. Does NOT do any protocol translation.


MUID (MIDI Unique Identifier) – A 28 bit random number generated by a Device used to uniquely identify the Device in MIDI-CI messages to or from that Device.

Das hier ist auch schon bekannt und wird also schon gemacht.

Es gibt viele Levels von "Rechten", sgnt Authority Levels und so weiter.

Weiter oben haben wir ja schon dargelegt, dass da 32Bit für CCs da sind, die MIDI Kanäle sind eigentlich bis 256 hochgedreht worden, die einfach nur in 16 weitere "Gruppen" gepackt wurden, damit das noch immer MIDI im alten Sinne ist.
Einzelne Werte wie Velocity agiert nun mit 16Bit, was zB in Logic schon geht weil MIDI 2.0 bei Apple bereits im OS drin steckt, Aftertouch hat 32Bit, also "osmotisch" wie nur was!
Wartet also mal darauf, dass das umgesetzt wird.

Gesendet wird aber dann eben klassisch. Und muss für UDP und SysEx Blocks ideal auf das UDP Ding "warten". Weil das haben die ja offenbar jetzt umgesetzt.

 

[verstaerker]

Mir war nicht klar, dass die JETZT erst das eigentliche Protokoll für schnelle UDP Übertragungen machen.


DH - MIDI 2.0 wird erst wirklich vollständig, wenn das alles mit durch geht, denn Ethernet und Direktverbindungen wie sie im Video beschrieben werden sind ja genau das was man will. Das ist schon schade, dass sich quasi nur so wenig Leute um so etwas wichtiges kümmern - die laden ja geradezu alle ein und die Sache wäre sicher bald und schneller durch wenn sich die Korgs und Rolands dieser Welt damit befassen würden.

das hat mich auch sehr überrascht - vor allem wenn man bedenkt das schon 2012 (oder wohl vorher) Leute bemerkt haben das Midi Rtp ein paar Probleme hat und deswegen ihr eigenes Protokoll entwickelt haben.

Ich stell hier erst auf Midi 2.0 um wenn es das über Ethernet gibt - ich traue USB einfach nicht. Ja dauert noch Jahre, aber ich denke das ich Zeit habe

 

[Makabäer]

Ich traue USB durchaus, aber kein Rechner kann so viele USB-Geräte verwalten, wie ich sie in meinen synthreichen Zeiten benötigt hätte. Aktive Hubs oder PCIE-USB-Karten bringen da auch nichts. Die bis zu 128 Geräte scheinen leider graue Theorie zu sein. Deshalb warte ich auch, bis MIDI über Ethernet vollständig implementiert und praxiserprobt ist.

 

[Moogulator]

Du kannst schon einigen offiziellen MIDI 2.0 Umsetzungen trauen, nur ist es dann natürlich technisch genau so umgesetzt.
Ich hoffe schwer, dass die Umsetzung auch optimiert wird wenn das verabschiedet wird - denn was jetzt über TCP/IP oder den USB Standard läuft müsste ja dann nur optional ggf. in ein Global Menü gesetzt werden "use UDP M2.0" - das wird dann nicht jeder kapieren aber viel bringen.

Ich glaube selbst MIDI 2 zu verwenden ist nicht falsch, noch kann man nicht viel darauf umstellen, weil es ja nur wenige Geräte gibt die es verwenden. Später könnte es aber sein, dass eine Firma aus "Faulheit" ggf. das andere Format nutzt ohne Not.

MIDI richtig zu machen ist ja jetzt schon nicht immer garantiert.
Schwer wird nur das was wirklich in der Praxis gemeinsam über das Kabel wirklich läuft und dann am Microcontroller von irgendeinem EurorackModul scheitern und ausgebremst werden könnte.
Und dann heißt es "Scheiß MIDI" - und eigentlich ist es nur das eine Ding oder jemand der das nicht anständig gemacht hat oder aber - nicht so genutzt wie es gemeint war - der Modulhersteller kann ja schreiben - ja, MIDI2.0 nutzen wir aber nur um das Modul zu warten, also bitte abstecken oder aus der Kette raus halten fürs Studio.

Sowas könnte passieren.

 

[2bit]

Naja, der Netzwerkstack muss ja quasi zuletzt kommen. Das zeigt aber auch, dass die betriebssystemspezifischen Arbeiten bei den großen Playern wohl weitestgehend abgeschlossen sein müssen, wenn man sich jetzt über eine OS-agnostische Ausprotokollierung via UDP Gedanken macht.

Das vorher zu machen, eh noch nicht alles in Windows* quasi final implementiert ist, macht ja null Sinn.

*War ja ewig und drei Tage ein richtiges Sorgenkind, weil die Basisroutinen von MIDI 1.0 unter Windows, gelinde gesagt, Jahrzehntelang einfach kacke waren.

 

[Moogulator]

Es ist GUT wenn die OS Hersteller alles was da ist implementieren aber nicht aufhören weiter zu machen. Unter anderen Standards hat man auch "transitional" Technik eingeführt - das ist schon richtig, damit das System da ist und allgemein genutzt werden kann. Nachteil - das man Apple oder Google dann hasst, weil sie in einem neuen OS MIDI 2.0 umgestellt haben mit den neuen Protokollen und die laufen dann anders und User beschweren sich dann bei dem OS Hersteller. So entscheiden manche vielleicht "macht ihr mal und wenns fertig ist machen wir".

 

[verstaerker]

Das vorher zu machen, eh noch nicht alles in Windows* quasi final implementiert ist, macht ja null Sinn.

*War ja ewig und drei Tage ein richtiges Sorgenkind, weil die Basisroutinen von MIDI 1.0 unter Windows, gelinde gesagt, Jahrzehntelang einfach kacke waren.

Windows ist doch eh hintendran.. Apple hat schon letztes Jahr vorgelegt. Logic kann schon Midi 2.0 und das Midi unter macOs fest implmentiert ist ist schon angenehm

 

[Moogulator]

Richtig, aber die haben das natürlich nach damaligem Stand implementiert. Dh die müssen dann die neuen Sachen nachliefern. Finde ich richtig so. Siehe post - man könnte es anders halten, wäre aber schlecht für den Fortschritt. Gut wäre wenn MS und Apple so wie Google da eine Schlüsselperson in MIDI setzen würde und das dann auch einfach sofort umsetzten sobald es klappt und abgesegnet wurde.

 

[2bit]

Gut wäre wenn MS und Apple so wie Google da eine Schlüsselperson in MIDI setzen würde

"Ungefähr 9 Mitglieder" arbeiten ja dran...



Wer immer das jetzt auch ist. Vielleicht hatten die anderen "fünf" für einen YT-Talk grad einfach keinen Bock...?!

 

[Moogulator]

Ja, die die man da sieht sind die die es immer tun. Die haben Bock.
Und manche haben an einigen Features sicher mehr Interesse als an anderen.

Das ist aber vergleichsweise wenig für eine "Organisation" die für uns ja faktisch alles bedeutet. Ohne MIDI und Festlegung wären wir bei CV und 100 Sonderlösungen geblieben und hier wäre es gut wenn alles was sinnvoll ist natürlich drin ist.
Das umsetzen ist dann quasi leichter - man hängt sich dran. Ob da einer von Apple dabei ist? Weiss ich nicht, aber von MS gab es Aussagen. Das ist aber wie man in der Praxis sieht halbherzig oder nicht so progressiv wie es eben scheint.

Und mit Pech muss man dann bis W12 oder 13 warten, bei MacOs würde sowas dann aber auch im jahresbeat der Updates wohl rein kommen. Das ist Firmenpolitik und auch gerade bei Apple eine Art von Abhängigkeit die man da hat - nicht wegen MIDI sondern wegen der Firma und deren "Kultur". Was noch ein nettes Wort ist für das was die da so draus machen.

Es wird nie schnell gehen wenn eben eine Hand voll Leute das alles durchdenken.
Zu viele geht natürlich auch nicht, damit das trotzdem zusammen passt, aber - wir werden es sehen.
Ich finde das spannend als solches. Aber lieber würde ich eben damit arbeiten können und dann werden viele Synthhersteller eher ein neues Gerät bauen als ein altes mit 2.0 auszustatten. Meist. Das ist meine Vermutung.
Weil HW muss dazu passen und das auch leisten können.