View Single Post
Old 08-04-2017, 04:24 PM   #11
Airal
Banned
 
Join Date: Nov 2015
Posts: 406
Default

No, you are failing to realize the difference.

Midi over USB is not Midi.

If it were, it would not be called Midi over USB.

Midi is a binary specification of how to interpret data bits and how those data bits are packed in a stream. It also has a hardware specification that says how one can connect devices physically.

Midi over USB is the binary specification(the protocol) that is transported not through the original hardware specification(else you would use midi cables) but through usb cables. But USB is not midi so that protocol must be encoded and then decoded to and from the USB protocol, which is vastly different than the midi protocol and not compatible.

e.g., you couldn't take a USB midi device cut the USB end off and attach it to a MIDI port(both only have 2 data pins(or technically one and a ground)) and it work.

Hence, Midi over USB is not Midi, it is USB. This is why it is called Midi *over* USB. It is Midi data packed in to a USB format in such a way that it can be transmitting over a USB interface.



It is no different than Midi over Bluetooth. Same principles apply EXCEPT both the receiver and transmitter must deal with the Bluetooth protocol, which is different than the USB protocol.


So, when a midi over bluetooth device sends "midi" data, it takes whatever data it has, converts it in to midi data(e.g., you hit a note, sends an electrical signal to a uP which then turns that in to a 3 byte midi note representation). That midi data is then put on the bluetooth stack like any other bluetooth data would(a bluetooth mic would do the same type of process but pack the audio data in to bluetooth packets).

That then streams to the computer over the air and in to a bluetooth receiver connected to the computer or whatever device. It is bluetooth data at this point, not midi data, regardless. Then the software connects to the bluetooth stack, gets the data and knows that it should interpret it(or tries to) as midi data. It then depacks the data and does whatever it does with it as normal midi.

Midi Out >--------- Midi Cable ---------> Midi In -> Computer Software
Midi -> BT Out >--------- BT Air ---------> BT In -> Computer Software -> Midi In

If the computer isn't designed to convert the BT data back to midi, it won't work. Same with USB or any other protocol.

There must be internal drivers and filters that do the work and that is what the Midi over Bluetooth protocol does. This is also why standard midi does not work with bluetooth... simply because the drivers couldn't anticipate the data being packed in bluetooth packets and so didn't add any code to deal with it.

Unfortunately, windows has implemented the bluetooth to midi unpacking in uwp rather than enhancing the original winmm services that are generally used for traditional midi. It could have been done but they didn't for whatever reason. Maybe in the future they will, as they've done most of the work for it... or they will expect programmers to add such abstraction capabilities through utilities or drivers.

So, as it stands,

Midi over Bluetooth can only be accessed using the uwp protocol or possibly through direct bluetooth decoding.

It's no different than VSTx86 and VSTx64. You can't run one process in the other. They are different things. If they could, they would be the same thing and no distinction would be made.

It took someone to come along and write a bridge app to allow one to go from one to the other, which has been done. It used to require external apps. Reaper, for example, has the bridge internally and does it all for us behind the scenes, which makes it very convenient, but it doesn't change what is really going on.

You can't just hook up stuff and expect things to work. It never works like this. If it does either you connected two things that understand each other by design or you are wrong. Can't have it any other way. Things must be designed to work together. Why? At the end of the day it's just a bunch of 0's and 1's. It's how we interpret them that makes it work and everyone has their own interpretations... this is why we have standards and protocols so we can actually get things to communicate.

You can claim all day long that reaper should already be able to deal with midi over bluetooth, but if reaper has not added that functionality, or whatever reaper is using has not added that functionality, then it can't be done. Someone must do the work somewhere for it to work. Reaper hasn't done this as far as I'm aware. Why? Because I added a midi over bluetooth device and reaper doesn't show it. It shows all the other midi devices but not the BT device. Why? either my device is not functioning properly, The computer is not setting things up properly, or reaper is not functioning properly.

It could be my device, because I only have one to test with and it is mainly designed for mac. But, given what I have read, the links I posted specifically state one must use uwp to access bluetooth over midi. This tells me that windows has not enhanced their standard winmm midi functions to interact with the bluetooth midi and instead created a new version and stuck it in uwp.

I seriously doubt reaper has added code to a use the new functionality. It would surely show up in the change log and chances are it would have found my device.

Again, you have to realize there is a big difference. A fundamental difference. Midi over X is not Midi, regardless of X. Even if X is Midi, we have Midi over Midi which is not Midi but an wrapper of Midi inside Midi... e.g., using sysEx messaging to send normal Midi commands.
Airal is offline   Reply With Quote