08-01-2017, 02:41 PM | #1 |
Banned
Join Date: Nov 2015
Posts: 406
|
Bluetooth over MIDI support in Reaper
Would be great! Surely not too hard to add?
Heres some info https://blogs.windows.com/buildingap...JewZlbjkisQ.99 https://github.com/Microsoft/Windows...r/Samples/MIDI Last edited by Airal; 08-01-2017 at 02:50 PM. |
08-01-2017, 10:27 PM | #2 |
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,787
|
In fact I use a TEC BBC that features a rater delicate Midi Cable and enhancing it with a portable battery powered Midi-USB to Bluetooth box would be fantastic. (Unfortunately I am very reluctant to convert my live setup to windows 10...)
While it would be great to be able to use Midi via Bluetooth I don't see how Reaper would be in that game. Supposedly, in fact the Windows Midi via USB driver would provide just another standard Midi device Reaper could attach to. -Michael |
08-02-2017, 06:08 AM | #3 | |
Human being with feelings
Join Date: May 2009
Posts: 29,269
|
Quote:
__________________
Music is what feelings sound like. |
|
08-02-2017, 06:40 AM | #4 | |
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,787
|
Quote:
But Win10 is supposed to provide the Midi via BTLE device driver as stated in the first post. Reaper should be able to see and use such a midi device if the compatible hardware and the Windows configuration is in place. -Michael |
|
08-02-2017, 06:52 AM | #5 |
Human being with feelings
Join Date: May 2009
Posts: 29,269
|
Correct, Reaper shouldn't have anything to add/code/change in order for this to work.
__________________
Music is what feelings sound like. |
08-03-2017, 08:47 PM | #6 |
Banned
Join Date: Nov 2015
Posts: 406
|
Wrong, that is not true. Read the article. To enumerate and activate the new midi over bluetooth devices, requires new code that reaper has not added, which is why it can't do it.
The article gives the code on how to do this which is why I linked it. I doubt it gets implemented though because it seems the devs are only focused on automation items and other enhancements rather than any real bug fixes or issues. I posted an issue with reaper screwing up certain file formats and that hasn't been addressed for over two months. |
08-03-2017, 09:36 PM | #7 | |
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,787
|
Quote:
But M$ is known to be carelessly incompatible to themselves now and again ... Is there any hardware thingy tunneling an existing Midi stream (USB or 5-pin) via Bluetooth using the "Win10 Midi over Bluetooth" Windows core functionality to decently check out this independently from the midi-stream generating device (which might introduce it's own quirks ) ? -Michael Last edited by mschnell; 08-03-2017 at 09:42 PM. |
|
08-03-2017, 10:49 PM | #8 |
Banned
Join Date: Nov 2015
Posts: 406
|
It's not a shortcoming. Midi over bluetooth is not midi. < windows 10 doesn't even support it. They might eventually add some type of internal connection between winmm and windm but as of now it simply doesn't work that way. Read the articles and you'll see how it works, no guessing.
Of course, you have to realize that M$ could easily do whatever they want but they'd rather push people in the direction of their new toys rather than investing in old tech that has inherent problems... they'd rather create new tech with inherent problems. It's a business model and keeps the money flowing like water. There are devices that take traditional midi inputs and outputs of a midi device like a midi keyboard and packages them up in to midi over bluetooth. Far what I understand though, they are generally unusable due to the latency issues with bluetooth. |
08-03-2017, 11:19 PM | #9 | |
Human being with feelings
Join Date: May 2009
Posts: 29,269
|
Quote:
__________________
Music is what feelings sound like. |
|
08-04-2017, 01:21 PM | #10 |
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,787
|
If this is true then it's a really bad idea.
Bluetooth is a transport layer usable for multiple different types of data streams. USB is a transport layer usable for multiple different types of data streams. Ethernet is a transport layer usable for multiple different types of data streams. WLAN is a transport layer usable for multiple different types of data streams. Midi over USB is midi. Midi over Ethernet is midi. Midi over WLAN is midi. -Michael |
08-04-2017, 04:24 PM | #11 |
Banned
Join Date: Nov 2015
Posts: 406
|
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. |
08-04-2017, 04:41 PM | #12 |
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,798
|
If MIDI over BT is really just UWP, chances of Reaper getting that are really slim, I'd say - unless somebody backports it to win32 (which is again, probably slim chance). UWP apps still cannot touch the performance of native win32 code.
__________________
Edit poly aftertouch in MIDI editor! Entirely (un)dockable UI! | Improve Render Queue! |
08-04-2017, 05:07 PM | #13 | ||
Human being with feelings
Join Date: May 2009
Posts: 29,269
|
Quote:
Quote:
__________________
Music is what feelings sound like. Last edited by karbomusic; 08-04-2017 at 05:19 PM. |
||
08-04-2017, 10:44 PM | #14 |
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,787
|
Terminological Nonsense !
With the same right you could say a telephone call is not a conversation, ... or a telephone call is not a telephone call it the telephone equipment uses Voice over IP (hence the Internet) as a transport medium. Regarding the input (e.g. a 5 pin connector) and the output (e.g. a virtual Midi port a DAW can attach to), "Midi over usb" (using the appropriate equipment and software), is not distinguishable from plain old Midi from either site. -Michael Last edited by mschnell; 08-04-2017 at 11:01 PM. |
08-04-2017, 10:54 PM | #15 |
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,787
|
So it got a misleading name. Another extremely nasty choice of M$.
In fact lately they were very successful reaming "virtual machine" to ".NET" and "embedded computing" to "IOT" (Internet Of Things), just trying to claim that they are the ones that rule the world. But happily in these cases they did not borrow a name for obviously well defined stuff. -Michael Last edited by mschnell; 08-05-2017 at 02:06 AM. |
08-04-2017, 11:07 PM | #16 | |||
Banned
Join Date: Nov 2015
Posts: 406
|
Quote:
As your probably aware, the traditional way to enumerate midi devices is using winmm. But those functions will not enumerate BT devices as midi devices(how could they? They were created before BT was even invented) and because microsoft has not extended them to do so(yet... or they have and my system is just fubar'ed). I was able to use the example code in a non uwp app to enumerate the devices but I still had to call in to the uwp libraries. My bluetooth device was listed. One simply has to go to device manager and look under software devices and sound, video, and game controllers. Not all the devices are listed in both. Specifically, Midi over Bluetooth devices will probably not be listed in the second category unless they were installed with a specific driver. Windows just added Midi over BT support in windows10+ so all this is relatively new. I'm sure it will change in the future. The main point I am making is that, unless I am proven wrong, reaper will not enumerate and list midi over BT devices in it's midi devices window and therefor cannot use them. At least, that seems to be the case on my machine, I have not seen any contradictions of it, and all the articles about Midi over BT supports my claim. Now, I imagine it would be quite simple for someone to write some type of bridge so that midi over BT devices can be enumerated through the traditional techniques but I imagine this is non trivial and requires creating a normal midi device to wrap the midi over BT device so the winmm enumeration functions will find it. It's not difficult but I've not seen anything out there that does it. Quote:
We are not talking about what should be but what is. It is obvious that with enough work anything can be done. But is Midi over BT devices are not enumerated as midi devices then one cannot access them as normal midi devices, simple as that and no easy way around it. It may be that BT audio devices are also enumerated as normal audio devices by an internal bridge M$ created and so it isn't an issue. 1. "Let’s take a look at MIDI. Windows has had built-in MIDI support going back to the 16-bit days. Since then, most MIDI interfaces have moved to USB and our in-box support has kept pace, with a class driver and APIs that support those new interfaces." 2. "Those unfamiliar with music technology may think of MIDI as just .mid music files. But that’s only a tiny part of what MIDI really is. Since its standardization in 1983, MIDI has remained the most used and arguably most important communications protocol in music production. It’s used for everything from controlling synthesizers and sequencers and changing patches for set lists, to synchronizing mixers and even switching cameras on podcasts using a MIDI control surface. Even the Arduino Firmata protocol is based on MIDI. ... New Bluetooth LE MIDI support in Windows 10 Anniversary Update ... " Now, the bullet point is what is important. It says that windows 10 anniversary is what adds support for Midi over Bluetooth. It does not specifically say if a win32 api can be used and is geared towards UWP though. Searching for win32 midi over bluetooth gives something like "Until now, wireless MIDI products in the market have only catered to the macOS and iOS communities. When we set out to build ACPAD, we wanted to disrupt MIDI music industry. We wanted to make sure that each and every person who gets an ACPAD would be able to use all the features in their favorite operating system without having to make a switch from Windows to MacOS. Industry has ignored Windows users for far too long. We are glad to reveal that our software team’s research and development has finally paid off and ACPAD is currently the only company in the market to provide ultra-low latency wireless MIDI on Windows 10 platform without any external hardware. A big shout out to our software developer, Deepak Kumar, whose hard work has finally made it possible for all our users to use Wireless MIDI in Windows 10. You will be able to download the software from our website when we start shipping out ACPADs. If there is enough demand ACPAD may be looking at offering this general purpose application for use on all MIDI controllers." Which, again, suggests that custom software is needed... which reaper does not currently have. My main point is that reaper has to add these capabilities, like what was done before, if BT MIDI devices will be usable. That is it. I could be wrong, but again, hard proof is required rather than desire to contradict me. What I do know is that my BT MIDI device is not found by reaper nor other programs. (I think I read somewhere that Sonar supports such things but didn't investigate) Quote:
Reaper obviously does not have direct capabilities to do MIDI over Wifi, (well, it might, since it has a lot of stuff but no one has standardized MIDI over Wifi protocols that reaper could use directly in any sensical way). But obviously with rtpMIDI, which bridges the gap between MIDI and MIDI over Wifi, it can be done. The same thing can be done, and must be done with BT MIDI. It's not, which is unfortunate because I have such a BT MIDI device that is useless right now since it cannot be used with windows(works fine for mac stuff, since they already standardized the it). Time and work will solve many of these problems, but reaper could take the initiative to provide support now if they wanted. Again, my point with all this crap is very simple: Reaper is not listing my BT MIDI device. I'm not the only one... therefor, something needs to be done(By cockos, or others) to get them working. Again, it could just be me. Maybe my system is screwed up and it's suppose to work and all this has been done. I only have one such device to test so I can't say. But I'm not the only one and I've not found any contradictory statements to my claims so I will stand by them until otherwise. |
|||
08-04-2017, 11:17 PM | #17 | ||
Human being with feelings
Join Date: May 2009
Posts: 29,269
|
No way I'm reading all of ^that
Quote:
Here is another example, Soundbrenner Pulse. The maker of the device is taking care of the BTLE side of the house (because they are responsible for communicating with their device) and presenting a MIDI device to the DAW: Quote:
AFAIK, it isn't available in Windows just yet since BTLE support is new in Windows. That's not the DAW's problem to solve.
__________________
Music is what feelings sound like. Last edited by karbomusic; 08-04-2017 at 11:43 PM. |
||
08-05-2017, 02:01 AM | #18 |
Banned
Join Date: Nov 2015
Posts: 406
|
@karbo
Wow, your approach is pretty ignorant(get offended if you want, but you are being illogical). You are picking an choosing what the DAW should implement and not based on magic... on your whims... or on trying to to find a leg to stand on. With your logic, one could say before reaper had midi support, that it is up to the OS to implement it(or drivers or whatever excuse you want). Before it had OSC support you could say it is not up to the DAW. Before it had support for surfaces you could say it is up to someone else to do the work. You can say whatever you want. And note, we are not talking about reaper implementing drivers for every single device that exists, or any specific device. We are talking about reaper adding support for modern technologies by using the new API's that were designed for apps like reaper to implement. We are not asking for reaper to do anything that it isn't suppose to like implementing a CNC machine control program. BECAUSE at the end of the day, if reaper wants to stay competitive it has to stay current. That is what it all boils down to. One day you will get a BT MIDI device and it will either work or it won't. If, by that time, and other DAWS have support, you will request that reaper do the same. Then you will be in the same boat. And some person that doesn't understand the problem and say "Hey, that's not reapers problem" and you will try to explain why it is(or most likely is) and that person, being thick, will argue until they are blue in the face and neither side will get anywhere because one side is ignorant of the facts and will refuse to learn them to understand the problem enough to make valid decisions, cause, at the end of the day, they don't care because it is not effecting them. You are not a flat earther or believe the moon landing was a fake, are you? Don't take this as a personal attack, we are all ignorant at something. But you have no chips in the game and it is obvious and you have not backed up your side with any facts what so ever so I have no alternative but to conclude what I have until I'm proven wrong. Come up with facts if you want to continue this discussion in an meaningful way. Or better yet, go do something more useful like create music, since that is what we are ultimately arguing about. By trying to piss on my parade just because you have to piss is not helpful to anyone and eventually someone will do the same to because what comes around goes around. |
08-05-2017, 02:04 AM | #19 |
Banned
Join Date: Nov 2015
Posts: 406
|
@karbo
Wow, your approach is pretty ignorant(get offended if you want, but you are being illogical). You are picking an choosing what the DAW should implement and not based on magic... on your whims... or on trying to to find a leg to stand on. With your logic, one could say before reaper had midi support, that it is up to the OS to implement it(or drivers or whatever excuse you want) and magically hand that data to reaper. Before it had OSC support you could say it is not up to the DAW. Before it had support for surfaces you could say it is up to someone else to do the work. You can say whatever you want. And note, we are not talking about reaper implementing drivers for every single device that exists, or any specific device. We are talking about reaper adding support for modern technologies by using the new API's that were designed for apps like reaper to implement. We are not asking for reaper to do anything that it isn't suppose to like implementing a CNC machine control program. BECAUSE at the end of the day, if reaper wants to stay competitive it has to stay current. That is what it all boils down to. One day you will get a BT MIDI device and it will either work or it won't. If, by that time, and other DAWS have support, you will request that reaper do the same. Then you will be in the same boat. And some person that doesn't understand the problem and say "Hey, that's not reapers problem" and you will try to explain why it is(or most likely is) and that person, being thick, will argue until they are blue in the face and neither side will get anywhere because one side is ignorant of the facts and will refuse to learn them to understand the problem enough to make valid decisions, cause, at the end of the day, they don't care because it is not effecting them. You are not a flat earther or believe the moon landing was a fake, are you? Don't take this as a personal attack, we are all ignorant at something. But you have no chips in the game and it is obvious and you have not backed up your side with any facts what so ever so I have no alternative but to conclude what I have until I'm proven wrong. Come up with facts if you want to continue this discussion in an meaningful way. Or better yet, go do something more useful like create music, since that is what we are ultimately arguing about. By trying to piss on my parade just because you have to piss is not helpful to anyone and eventually someone will do the same to because what comes around goes around. |
08-05-2017, 02:12 AM | #20 | ||
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,787
|
Quote:
Such a device driver would be called a "Midi over Midi-over-BT" driver. I do know that such device drivers do exist for "midi over Ethernet" and are provided for free by community projects. Quote:
I totally disagree. Its not sensible to enable a transport mechanism in a dedicated user program, while a device driver could enable it far a complete class of user programs. Of course it would be a nice move if the friendly engineers at Cockos would provide such a device driver -Michael Last edited by mschnell; 08-05-2017 at 02:25 AM. |
||
08-05-2017, 02:24 AM | #21 |
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,798
|
There does seem to be a win32 wrapper for UWP MIDI API, it seems.
https://blogs.windows.com/buildingap...in-windows-10/
__________________
Edit poly aftertouch in MIDI editor! Entirely (un)dockable UI! | Improve Render Queue! |
08-05-2017, 02:29 AM | #22 | |
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,787
|
Quote:
So Reaper just needed to follow. -Michael |
|
08-05-2017, 02:32 AM | #23 | |
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,787
|
Quote:
Do you suggest it creates a standard Midi device in Windows ? If yes, why should that not work in Win 64 ? I would be especially interested in Win7 support ! So somebody should try it with Reaper . OTOH: does anybody know a hardware device that connects to the PC by BlueTooth and provides a Midi-over-USB and/or 5-Pin-Midi interface for appropriate equipment ? -Michael |
|
08-05-2017, 02:36 AM | #24 |
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,798
|
Not sure if it creates a MIDI device, but it allows using all UWP MIDI API commands in a win32 application. So I assume somebody would still need to write a driver that converts MIDI BT devices to regular MIDI devices. Not sure. Code can be checked on github, though!
Related: https://askjf.com/index.php?q=3751s https://askjf.com/index.php?q=3757s
__________________
Edit poly aftertouch in MIDI editor! Entirely (un)dockable UI! | Improve Render Queue! |
08-05-2017, 04:52 AM | #25 | |
Banned
Join Date: Nov 2015
Posts: 406
|
Quote:
He says they cannot be enumerated but you can do this using the the link I originally gave. I basically wrote a small program to do it and it did list my devices: "Ah yeah, hopefully we can include that wrapper at some point. The wrapper is missing a few things though, like the ability to get device IDs..." So, if that's all he needs to get support in reaper I'm sure he could hack something together. It requires using two uwp dll's: Windows.winmd and System.Runtime.WindowsRuntime.dll. Here's the code(It's C# and .Net but I see no reason why it couldn't be used, if necessary, to modify winrtmidi... which probably have the deviceID's somewhere anyways): Code:
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; using System.Windows.Threading; using System.Windows; using Windows.Devices.Midi; using Windows.Devices.Enumeration; namespace UWPMidiTest { class UWPMidi { public List<MidiInPort> midiInPorts = new List<MidiInPort>(); public List<DeviceInformation> midiInDevices = new List<DeviceInformation>(); public void CloseMidiDevices() { // Close all MidiInPorts foreach (MidiInPort inPort in midiInPorts) inPort.Dispose(); midiInPorts.Clear(); } public async void ListMidiDevices() { // Enumerate Input devices var deviceList = await DeviceInformation.FindAllAsync(MidiInPort.GetDeviceSelector()); foreach (var deviceInfo in deviceList) { System.Diagnostics.Debug.WriteLine(deviceInfo.Id); System.Diagnostics.Debug.WriteLine(deviceInfo.Name); System.Diagnostics.Debug.WriteLine("----------"); Console.WriteLine(deviceInfo.Id); Console.WriteLine(deviceInfo.Name); Console.WriteLine("----------"); midiInDevices.Add(deviceInfo); } // Output devices are enumerated the same way, but // using MidiOutPort.GetDeviceSelector() } public async void InitMidiInDevice(int index) { var devInfo = midiInDevices[index]; //var currentMidiInputDevice = midiInPorts[index]; var currentMidiInputDevice = await MidiInPort.FromIdAsync(devInfo.Id); if (currentMidiInputDevice == null) { Console.WriteLine("Unable to create MidiInPort from input device"); return; } // We have successfully created a MidiInPort; add the device to the list of active devices, and set up message receiving if (!midiInPorts.Contains(currentMidiInputDevice)) { midiInPorts.Add(currentMidiInputDevice); currentMidiInputDevice.MessageReceived += MidiInputDevice_MessageReceived; } // Clear any previous input messages } public void MidiInputDevice_MessageReceived(MidiInPort sender, MidiMessageReceivedEventArgs args) { IMidiMessage receivedMidiMessage = args.Message; // Build the received MIDI message into a readable format StringBuilder outputMessage = new StringBuilder(); outputMessage.Append(receivedMidiMessage.Timestamp.ToString()).Append(", Type: ").Append(receivedMidiMessage.Type); // Add MIDI message parameters to the output, depending on the type of message switch (receivedMidiMessage.Type) { case MidiMessageType.NoteOff: var noteOffMessage = (MidiNoteOffMessage)receivedMidiMessage; outputMessage.Append(", Channel: ").Append(noteOffMessage.Channel).Append(", Note: ").Append(noteOffMessage.Note).Append(", Velocity: ").Append(noteOffMessage.Velocity); break; case MidiMessageType.NoteOn: var noteOnMessage = (MidiNoteOnMessage)receivedMidiMessage; outputMessage.Append(", Channel: ").Append(noteOnMessage.Channel).Append(", Note: ").Append(noteOnMessage.Note).Append(", Velocity: ").Append(noteOnMessage.Velocity); break; case MidiMessageType.PolyphonicKeyPressure: var polyphonicKeyPressureMessage = (MidiPolyphonicKeyPressureMessage)receivedMidiMessage; outputMessage.Append(", Channel: ").Append(polyphonicKeyPressureMessage.Channel).Append(", Note: ").Append(polyphonicKeyPressureMessage.Note).Append(", Pressure: ").Append(polyphonicKeyPressureMessage.Pressure); break; case MidiMessageType.ControlChange: var controlChangeMessage = (MidiControlChangeMessage)receivedMidiMessage; outputMessage.Append(", Channel: ").Append(controlChangeMessage.Channel).Append(", Controller: ").Append(controlChangeMessage.Controller).Append(", Value: ").Append(controlChangeMessage.ControlValue); break; case MidiMessageType.ProgramChange: var programChangeMessage = (MidiProgramChangeMessage)receivedMidiMessage; outputMessage.Append(", Channel: ").Append(programChangeMessage.Channel).Append(", Program: ").Append(programChangeMessage.Program); break; case MidiMessageType.ChannelPressure: var channelPressureMessage = (MidiChannelPressureMessage)receivedMidiMessage; outputMessage.Append(", Channel: ").Append(channelPressureMessage.Channel).Append(", Pressure: ").Append(channelPressureMessage.Pressure); break; case MidiMessageType.PitchBendChange: var pitchBendChangeMessage = (MidiPitchBendChangeMessage)receivedMidiMessage; outputMessage.Append(", Channel: ").Append(pitchBendChangeMessage.Channel).Append(", Bend: ").Append(pitchBendChangeMessage.Bend); break; case MidiMessageType.SystemExclusive: var systemExclusiveMessage = (MidiSystemExclusiveMessage)receivedMidiMessage; outputMessage.Append(", "); // Read the SysEx bufffer /* var sysExDataReader = DataReader.FromBuffer(systemExclusiveMessage.RawData); while (sysExDataReader.UnconsumedBufferLength > 0) { byte byteRead = sysExDataReader.ReadByte(); // Pad with leading zero if necessary outputMessage.Append(byteRead.ToString("X2")).Append(" "); }*/ break; case MidiMessageType.MidiTimeCode: var timeCodeMessage = (MidiTimeCodeMessage)receivedMidiMessage; outputMessage.Append(", FrameType: ").Append(timeCodeMessage.FrameType).Append(", Values: ").Append(timeCodeMessage.Values); break; case MidiMessageType.SongPositionPointer: var songPositionPointerMessage = (MidiSongPositionPointerMessage)receivedMidiMessage; outputMessage.Append(", Beats: ").Append(songPositionPointerMessage.Beats); break; case MidiMessageType.SongSelect: var songSelectMessage = (MidiSongSelectMessage)receivedMidiMessage; outputMessage.Append(", Song: ").Append(songSelectMessage.Song); break; case MidiMessageType.TuneRequest: var tuneRequestMessage = (MidiTuneRequestMessage)receivedMidiMessage; break; case MidiMessageType.TimingClock: var timingClockMessage = (MidiTimingClockMessage)receivedMidiMessage; break; case MidiMessageType.Start: var startMessage = (MidiStartMessage)receivedMidiMessage; break; case MidiMessageType.Continue: var continueMessage = (MidiContinueMessage)receivedMidiMessage; break; case MidiMessageType.Stop: var stopMessage = (MidiStopMessage)receivedMidiMessage; break; case MidiMessageType.ActiveSensing: var activeSensingMessage = (MidiActiveSensingMessage)receivedMidiMessage; break; case MidiMessageType.SystemReset: var systemResetMessage = (MidiSystemResetMessage)receivedMidiMessage; break; case MidiMessageType.None: throw new InvalidOperationException(); default: break; } Console.WriteLine(outputMessage.ToString()); } } static class Program { /// <summary> /// The main entry point for the application. /// </summary> [STAThread] static void Main() { var uwpMidi = new UWPMidi(); for (int i = 0; i < 10; i++) uwpMidi.ListMidiDevices(); uwpMidi.InitMidiInDevice(3); Console.ReadKey(); } } } Last edited by Airal; 08-05-2017 at 08:45 AM. |
|
08-05-2017, 05:05 AM | #26 |
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,798
|
And now put all the code in CODE tags, please
Also note there are some (yet unresolved) hanging issues with the wrapper: https://github.com/stammen/winrtmidi/issues So it doesn't seem quite safe to use just yet.
__________________
Edit poly aftertouch in MIDI editor! Entirely (un)dockable UI! | Improve Render Queue! |
08-05-2017, 05:50 AM | #27 | |
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,787
|
You can't (in any easy way) use .NET (managed code / CIL code) from a native code program. (While it is supported the other way round.)
Quote:
As seemingly a CIL/.NET -only API is provided by M$, translating the C# code to C++ is not an option. -Michael Last edited by mschnell; 08-05-2017 at 11:14 AM. |
|
08-05-2017, 07:00 AM | #28 | |
Human being with feelings
Join Date: May 2009
Posts: 29,269
|
Quote:
__________________
Music is what feelings sound like. Last edited by karbomusic; 08-05-2017 at 07:20 AM. |
|
08-05-2017, 07:11 AM | #29 | |
Human being with feelings
Join Date: May 2009
Posts: 29,269
|
Quote:
Looking at the OPs code sample, it has ZERO to do with BTLE directly making this nothing more than a .NET vs Native discussion. I love .NET and have programed and debugged it at the Enterprise level for a decade now (but began with it in 2004 with version 1.1) but it does potentially break Reaper out of it's long-standing "dependencyless" existence IMHO unless there is a native method to access these devices minus .NET. Then again, .NET has been part of the OS for years now. Best case scenario may be a checkbox in the Reaper installer (like some of the other options) so that the support isn't added if it isn't needed.
__________________
Music is what feelings sound like. Last edited by karbomusic; 08-05-2017 at 08:09 AM. |
|
08-05-2017, 08:44 AM | #30 | |
Banned
Join Date: Nov 2015
Posts: 406
|
Quote:
I didn't see you state anything technical so I didn't bother replying in a technical way. Might have been oversight or you might have not have said anything technical. But this thread has become a huge time waster anyways so lets just leave it at that. What I desired has somewhat materialized, which is getting the ball rolling. That's all I really care about because it's not my ball to roll. |
|
08-05-2017, 08:48 AM | #31 | |
Banned
Join Date: Nov 2015
Posts: 406
|
Quote:
I didn't catch that implementation of the wrapper but I'm glad it exists. Not sure where the problem lays though and if it will be a blocker or not. From a cursory glance, it seems relatively minor. Just sysEx and dual mode devices. It shouldn't stop an implementation from moving forward. Reaper could just prevent sysEx messages or the dual mode devices temporarily until the bug is fixed then remove a few lines of code. |
|
08-05-2017, 09:12 AM | #32 | ||
Human being with feelings
Join Date: May 2009
Posts: 29,269
|
Quote:
Quote:
Unless there is no other choice or a breaking reason such as latency, it would be inefficient for every DAW to write code to access MIDI data just because it travels over BT when the maker of the device could write the code once and serve everyone which is the method most hardware uses currently - again unless there is no other choice.
__________________
Music is what feelings sound like. Last edited by karbomusic; 08-05-2017 at 09:19 AM. |
||
08-06-2017, 08:12 AM | #33 |
Banned
Join Date: Nov 2015
Posts: 406
|
karbo: That isn't how it works any more. The movement is towards unified standards that are plug in play. Instead of every hardware device having to implement custom drivers that are basically all identical, a single common driver class is used and those devices can use that. e.g., the USB audio standard, Midi over bluetooth, USB Cameras, HID interfaces, etc.
There is no need to reinvent the wheel any more, we live in a proverbial junkyard and tires are all over the place. M$ is trying to trying to unify all these seemingly disparate technologies with uwp. e.g., we used to have to compile a program for each platform it was to be ran on but humans soon learned that was a huge waste of time because we could write programs in such a way that they could be compiled once and ran on multiple platforms(e.g., java). Even though it is not has performant, it is more commercial... and that is the direction everything is moving. Writing windows devices drivers is no easy task and most programmers couldn't do it(properly, and this is born out of the fact of all the problems people have with getting their hardware to work). It can be quite complex due to the original design, lack of documentation, difficulty debugging, etc. (of course, it's much easier now than it was but it's still more challenging) Being able to speed of that process, in a similar way how java is "universal" allows hardware manufacturers to fire their high end programmers and higher more peon recent graduates to write the the UI's and get the product out quicker and cheaper. The same thing is happening in the hardware world too. SoC's integrated devices, etc. It's all about $$$ at the end of the day, of course... but there is a direction of how technology and industrialization is moving. Sorta like how you can now buy anything on amazon rather than having to leave your house and interact with other human beings... is it the best way for humanity? Who knows... but it best way for those companies pushing this direction to make more money $$$? Obviously, or it wouldn't be done. TLDR(since you seem to be a slow reader or just don't like to waste your time): What is is not what should be. [interpret that how you want, it's general purpose, fast acting, completely biologically non-toxic, and will deodorizer your brain if you order in the next 5min]. |
08-06-2017, 08:14 AM | #34 |
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,798
|
Class-compliant drivers in majority of cases cannot yield the best possible performance out of a specific device, which is why some vendors who care about performance of their devices still write their own (RME, Roland...)
As always, everything is about tradeoffs.
__________________
Edit poly aftertouch in MIDI editor! Entirely (un)dockable UI! | Improve Render Queue! |
08-06-2017, 10:46 AM | #35 |
Banned
Join Date: Nov 2015
Posts: 406
|
If only performance were actually a big deal. If humans did everything the way they should we wouldn't even be here discussing these problems. Windows itself, and even the PC design itself is build on a flaky foundation that limits performance greatly. If I had my way, I'd have the world trash everything they have created since the dawn of time and start over from scratch and do things the right way.
Most devices do not need to eek out the last few percentage points of performance. E.g., midi devices(which operate at 32kbps max... quite slow compared to todays standards)... Most keyboard and input devices, etc. It's even surprising how many audio channels you can fit down a USB2 pipe using USB Audio. Obviously for higher end stuff you generally require higher end performance, software, and such... but it's gonna cost you. At some point when things move over to the newer technologies such issues won't be a big deal. The main issue is has always been just getting data from point A to B. Adding real time constraints to that generally is where the headaches lay and all the work is done... but those are becoming a thing of the past with the transmission rates that are now being achieved over wire and wireless. One day there will probably be a single transport layer that suits everyones needs... well, if humans last that long. |
08-06-2017, 11:52 AM | #36 | ||
Human being with feelings
Join Date: May 2009
Posts: 29,269
|
Quote:
However, UWP has nothing to do with class compliant other than it is likely talking to a class compliant driver for you but that is sort of irrelevant because the point I made talks to a class compliant driver and offers up the MIDI endpoint to all apps on the machine. Consider, I could be missing some requirement but beyond that and programming one to prove my point, I'll stick with my point that the best scenario (possible or not), is that the application (reaper) shouldn't have to write new code to support the exact same MIDI data just because it travels differently across the wire/air. And I'll add, as a UWP programmer (when I have time), that plug and play is all about writing an application once and being able to deploy it to any device as-is. I do that all the time to the extent I have apps I've written that run on my computer, my Surface, my phone, my laptop and my Raspberry Pi. So the real problem is Windows isn't (yet) offering this up as native, they are only supporting access via .NET right now. Quote:
You are essentially stating that C#/.NET is easier than writing a classic driver using the driver kit, that's nothing to do with drivers per se, just programming platform. Native will overall always be at the heart of drivers because higher level platforms compile down to more CPU instructions in some cases and in others it's the latency from being further away from the hardware. That's cool, I hate C++ from a productivity standpoint but we want to make sure we are clear about what we are comparing and here it is the level of code, not the fact it is a driver.
__________________
Music is what feelings sound like. Last edited by karbomusic; 08-06-2017 at 11:59 AM. |
||
08-06-2017, 12:23 PM | #37 |
Banned
Join Date: Nov 2015
Posts: 406
|
karbomatic: Wow, we keep going in circles here.
But you seem not to realize that reaper is using 20+ year old technology. Winmm was written around win3.1 and that is what reaper uses and 99% of other daws(a few of the progresses daws out there are just now updating their code base for it). I am not arguing at all that windows could write a bridge for it... what I am arguing is the reality of the situation... which is, that hey haven't... At least officially. It is not a question of whether reaper should or should not have to do anything but a question if does it need to do it to support a large set of modern devices. --- Have you actually ever written a device driver? Or worked through the ddk? Be honest! I have! Now it's been over 15 years since I've done it, and things have changed quite a bit since then... but it is not an easy task and it is NOT the same as writing a C# app or even a typical C/C++ app. It is more akin to assembly and it is not object oriented(all win32 stuff, but you can't just do stuff like you can in ordinary programming). There are pitfalls and order of operations that must be taken or you will crash the OS. So, it is entirely different in that regard. A kernel mode driver can crash the instantly while a user mode app will rarely crash the OS(well, today at least). Also, debugging was usually done by console methods rather than what we use today.(I'm not sure how far it has advanced). Not only that, but the amount of documentation and examples is much smaller. For doing certain things, yes, it is not too complicated. But for many things, it is much more complicated than your standard programs(specially today with most things being abstracted away). Either your a pretty good programmer and fail to take in to account the collective of modern programming or you haven't done much in depth programming. Most programmers are script kiddies that couldn't write a proper app if their life depended on it. Ruby, python, etc are not real systems programming languages and, IMO, are not really much of a programming language in the first place. In fact, Object oriented assembly is where it's all at, but no one has bothered to write a compiler for it. Essentially what you are arguing is that bare metal microprocessing programming is equivalent to high level javascript web script programming like greasemonkey. If you really think your average programmer can walk in in and write a well written device driver in the same time, approximately, that they can write a some web script or whatever, then you are pretty ignorant of the state of affairs. Again, they may be the same for you depending on your skill level, but you are not everyone else. C# and .NET are easier languages not because they are higher level, in any real sense, but because they are more unified, better put together, and have more plumbing. The .NET is a very nicely designed framework. Basically the only one in the world that actually was put together well IMO. It's almost a pleasure to use. But, I actually use D to program in now days and it's pretty sorry. It has one of the worst libraries I've ever had the displeasure to use... but the language itself is awesome. The meta programming capabilities blows anything I've ever used(20+ languages) out of the water. I can do things that I've only dreamed of doing in other languages. (it's compile time capabilities are astonishing). It's not perfect, and the language itself could be much better organized, but it is extremely expressive(relatively speaking). As far as drivers in C#, one could do it if the kernel allows IR to be ran... I've not looked in to it so I don't know. The issue isn't so much with instruction amount... you can write whatever core optimized functionality you need in native code and bring it in if you want. Anyways, this is starting to get pointless. Neither of us can prove our opinions... I think I have more facts on my side, but I'm sure you think the same. One of us is almost surely more right than the other though and I'll just assume that that person is me Cause I'm sure you'll do the same. Cause, at the end of the day today I still don't know what your ultimate point is. Is it that cockos should simply not implement any code to try to use midi over bluetooth and wait for someone else to make it happen? If is, then that is just your opinion. My point is that reaper cannot use these devices(or many of them)... and that is fact. It's ultimately up to cockos to decide what they want to do. My main issue with you is the mentality that you take about leaving it up to someone else to make something work(assuming that is your position, which is what it sounds like). If everyone had that mentality nothing would get done. Everyone would just point the finger at someone else... that is also fact. Any time anything gets done is when someone decides to do it. That might be trying get others to do the work, as I have tried to do with this post. But it's better than pointing fingers, which is as close to absolutely useless as one can get. I could, of course, write my own DAW and implement design my own processors and audio interfaces and all that. I'd love to do that one day but, of course, there is only so much a single person can do. |
08-06-2017, 01:47 PM | #38 | |
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,787
|
Quote:
Hence neither a good choice for drivers not for DAWs, when latency is a decent issue. (Nor is any non-native code.) (This is not just an impression, but a friend of mine support a system that ia to process hundreds of telephone calls in a single box, and needs to do this using a huge count of threads. He did some research regarding .NET and declined to use it. Regarding DAWS that can be used for live performing, the latency demand is even 10 time greater.) -Michael |
|
08-06-2017, 03:27 PM | #39 | |
Banned
Join Date: Nov 2015
Posts: 406
|
Quote:
Again, the world isn't perfect. I'd prefer everything written in assembly. It could be done. Train people properly, stop pursuing things for $$$ and simply do them right from the get go. You can wrap assembly in higher level routines(which is exactly what a HLL does anyways) and abstract most of the complexity. Make it object oriented, etc. Of course, with my logic one could say we should write directly in Hex. Ideally, that would be the way to go... but I think assembly is a good balance if we had the proper tools for it. The problem with modern society is that when an inch is given a yard is taken. The faster computers become the more crap is added that slows them down forcing people to upgrade to repeat the cycle... the problem is that it never seems to end. |
|
08-06-2017, 05:48 PM | #40 |
Human being with feelings
Join Date: May 2009
Posts: 29,269
|
Yes, yes and yes. I also debug fortune 50 level software (.NET and Native) and at the driver and assembly level but that's neither here nor there but you did ask. Either way, I agree about the circles. Take care.
__________________
Music is what feelings sound like. Last edited by karbomusic; 08-06-2017 at 09:34 PM. |
Thread Tools | |
Display Modes | |
|
|