All of these companies are public traded and so have to be somewhat close to the chest in terms of discussing what they are working on. Regarding OS/API developers, we held meetings at NAMM with Apple, Google and Microsoft. ![]() They are available in a link at the top of the article on MIDI 2.0. ![]() We have been focused on getting the MIDI 2.0 specs signed off and ready for public download which happened TODAY! Sorry, we haven't responded here recently. P.S Would the first byte of the message with b7=0 not confuse the driver of running status ? Why going through MIDI-CI protocol negotiation if a new descriptor or drivers is needed that could just indicate 2.0 capabilities ?. There seems to be no information on the MIDI website to address any of such concerns. so MIDI 2.0 is only for MIDI UWP applications, that would mean most DAWs are left out in the cold, How will this impact Linux ALSA ? Many folks may not have the funding for an annual MIDI membership like larger companies, but like me, many may have these questions and some clarification for this would help. AFAIK Microsoft does not plan to make changes to the Win32 MIDI API anymore but only for Windows UWP. How will Windows Win32 API support the packet interface. How will this have to be implemented by MIDI USB device manufacturers and well as on the Mac, Windows and Linux OSes side ? Treat it like an Sysex packet ? that would be inefficient and cause processing code overhead. ![]() Since MIDI 2.0 only support USB (for now), will MIDI 2.0 need a new or updated OS class driver for the 32/64 bit universal packet interface and device descriptor for devices ? of the USB MIDI class driver spec defines support for 1,2 or 3 bytes transfers only, not 4 or 8.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |