Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Feature Requests

Reply
 
Thread Tools Display Modes
Old 08-01-2017, 02:41 PM   #1
Airal
Banned
 
Join Date: Nov 2015
Posts: 406
Default 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.
Airal is offline   Reply With Quote
Old 08-01-2017, 10:27 PM   #2
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Germany
Posts: 5,729
Default

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
__________________
www.boa-sorte.de
mschnell is online now   Reply With Quote
Old 08-02-2017, 06:08 AM   #3
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 22,429
Default

Quote:
Midi via Bluetooth
Soundbrenner uses BTLE and without it Reaper can't interface with that device on Windows.
karbomusic is online now   Reply With Quote
Old 08-02-2017, 06:40 AM   #4
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Germany
Posts: 5,729
Default

Quote:
Originally Posted by karbomusic View Post
Soundbrenner uses BTLE and without it Reaper can't interface with that device on Windows.
Obviously.

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
__________________
www.boa-sorte.de
mschnell is online now   Reply With Quote
Old 08-02-2017, 06:52 AM   #5
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 22,429
Default

Correct, Reaper shouldn't have anything to add/code/change in order for this to work.
karbomusic is online now   Reply With Quote
Old 08-03-2017, 08:47 PM   #6
Airal
Banned
 
Join Date: Nov 2015
Posts: 406
Default

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.
Airal is offline   Reply With Quote
Old 08-03-2017, 09:36 PM   #7
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Germany
Posts: 5,729
Default

Quote:
Originally Posted by Airal View Post
To enumerate and activate the new midi over bluetooth devices, requires new code
Creating Midi devices that are incompatible with the existing API for Midi devices would be a severe shortcoming of Windows.

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
__________________
www.boa-sorte.de

Last edited by mschnell; 08-03-2017 at 09:42 PM.
mschnell is online now   Reply With Quote
Old 08-03-2017, 10:49 PM   #8
Airal
Banned
 
Join Date: Nov 2015
Posts: 406
Default

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.
Airal is offline   Reply With Quote
Old 08-03-2017, 11:19 PM   #9
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 22,429
Default

Quote:
It's not a shortcoming. Midi over bluetooth is not midi. < windows 10 doesn't even support it.
The links are a little misleading. They are trying to promote UWP (universal apps) in the examples - even the cakewalk statement is carefully worded. That's managed code, not native (Reaper is native) so that's not something Reaper will or should add. However, if the BTLT stack is accessible outside of .NET (probably is) then whomever owns the BTLT device can just expose standard MIDI ports as part of their driver and reaper (or other DAWS) could see those - otherwise it won't happen because again, native vs managed code/platform.
karbomusic is online now   Reply With Quote
Old 08-04-2017, 01:21 PM   #10
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Germany
Posts: 5,729
Default

Quote:
Originally Posted by Airal View Post
Midi over bluetooth is not midi.
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
__________________
www.boa-sorte.de
mschnell is online now   Reply With Quote
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
Old 08-04-2017, 04:41 PM   #12
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 22,024
Default

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.
EvilDragon is offline   Reply With Quote
Old 08-04-2017, 05:07 PM   #13
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 22,429
Default

Quote:
There must be internal drivers and filters that do the work and that is what the Midi over Bluetooth protocol does.
My Bluetooth speaker shows up as an audio device to the system even though it is regular BT. If I want to use it from Reaper, I choose it as my audio device. The end result here should be no different other than it shows up in MIDI Devices. With BT being a tiny bit special I see what you are saying but I don't agree it is the best path.

Quote:
Midi over USB is not Midi.
Just for clarity, we should keep data and transport mechanisms separate, USB, BT, BTLE, ETHERNET are all mechanisms for moving *data* from point A to point B. In this case the data is MIDI and it is the payload regardless of protocol used. Meaning, BTLE or carrier pigeon, both are carrying the actual MIDI data - a BTLE driver should unpack the data and present it as a local MIDI endpoint - that's sort of the entire point of abstraction - IOW, if MIDI is what is being transmitted, the application (in this case Reaper) should only need to deal with MIDI and MIDI "Devices".

Last edited by karbomusic; 08-04-2017 at 05:19 PM.
karbomusic is online now   Reply With Quote
Old 08-04-2017, 10:44 PM   #14
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Germany
Posts: 5,729
Default

Quote:
Originally Posted by Airal View Post
Midi over USB is not Midi.
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
__________________
www.boa-sorte.de

Last edited by mschnell; 08-04-2017 at 11:01 PM.
mschnell is online now   Reply With Quote
Old 08-04-2017, 10:54 PM   #15
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Germany
Posts: 5,729
Default

Quote:
Originally Posted by EvilDragon View Post
If MIDI over BT is really just UWP
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
__________________
www.boa-sorte.de

Last edited by mschnell; 08-05-2017 at 02:06 AM.
mschnell is online now   Reply With Quote
Old 08-04-2017, 11:07 PM   #16
Airal
Banned
 
Join Date: Nov 2015
Posts: 406
Default

Quote:
Originally Posted by EvilDragon View Post
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.
Midi over Bluetooth is not UWP but, as of now, that is the only way microsoft allows one to enumerate those devices on windows machines. You can enumerate BT devices in other ways of course(non uwp and now uwp has it's own method).

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:
Originally Posted by karbomusic
My Bluetooth speaker shows up as an audio device to the system even though it is regular BT. If I want to use it from Reaper, I choose it as my audio device. The end result here should be no different other than it shows up in MIDI Devices. With BT being a tiny bit special I see what you are saying but I don't agree it is the best path.
That is not necessarily true. Did you install any drivers what so ever for your audio? I am not familiar enough with BT audio device programming to say if it should be the same or not.

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:
Just for clarity, we should keep data and transport mechanisms separate, USB, BT, BTLE, ETHERNET are all mechanisms for moving *data* from point A to point B. In this case the data is MIDI and it is the payload regardless of protocol used. Meaning, BTLE or carrier pigeon, both are carrying the actual MIDI data - a BTLE driver should unpack the data and present it as a local MIDI endpoint - that's sort of the entire point of abstraction - IOW, if MIDI is what is being transmitted, the application (in this case Reaper) should only need to deal with MIDI and MIDI "Devices".
Yes, that was my point with the long post. BUT the transport is what makes all the difference. Reaper maybe shouldn't have to support those those transport layers, but something has to. If reaper uses the old school communication layer then it will never be able to communicate with them until something bridges the gap. Reaper can do this internally itself(using the uwp code or possibly new Win32 routines) or someone could write a bridge utility that does it... sorta like rtpMIDI/MIDI over Wifi from Tobias Erichsen.

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.
Airal is offline   Reply With Quote
Old 08-04-2017, 11:17 PM   #17
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 22,429
Default

No way I'm reading all of ^that

Quote:
Did you install any drivers what so ever for your audio?
That should be your big clue right there. If I did or didn't install "drivers"... they *did not* come from Reaper, they were either built in to the OS (class compliant) or they were written by the maker of the device itself NOT Reaper. If there is MIDI to be had, it matters not from whence it came, it should show up as a MIDI device to the system which then shows up in Reaper's MIDI device list.

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:

Soundbrenner


DAW Tools
Soundbrenner DAW Tools for Mac OS X was created for our advanced users. Just start the app and it will show up as a MIDI Clock destination in your favorite Digital Audio Workstation. It will automatically adjust the tempo of the Soundbrenner Pulse to whatever you set in the DAW
.
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.

Last edited by karbomusic; 08-04-2017 at 11:43 PM.
karbomusic is online now   Reply With Quote
Old 08-05-2017, 02:01 AM   #18
Airal
Banned
 
Join Date: Nov 2015
Posts: 406
Default

@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.
Airal is offline   Reply With Quote
Old 08-05-2017, 02:04 AM   #19
Airal
Banned
 
Join Date: Nov 2015
Posts: 406
Default

@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.
Airal is offline   Reply With Quote
Old 08-05-2017, 02:12 AM   #20
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Germany
Posts: 5,729
Default

Quote:
Originally Posted by Airal View Post
... reaper will not enumerate and list midi over BT devices in it's midi devices window and therefor cannot use them.
So the correct way is to create a Windows device driver that converts "midi over BT" devices to standard Midi devices to make the usable for any Midi aware software and not just for Reaper.

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:
Originally Posted by Airal View Post
Reaper obviously does not have direct capabilities to do MIDI over Wifi, ...
Well it does not need to, as appropriate software is available (e.g. by Bome) that creates a standard Midi device routed to a hardware connected via WiFi or LAN (Ethernet)

Quote:
Originally Posted by Airal View Post
My main point is that reaper has to add these capabilities,
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
__________________
www.boa-sorte.de

Last edited by mschnell; 08-05-2017 at 02:25 AM.
mschnell is online now   Reply With Quote
Old 08-05-2017, 02:24 AM   #21
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 22,024
Default

There does seem to be a win32 wrapper for UWP MIDI API, it seems.

https://blogs.windows.com/buildingap...in-windows-10/
EvilDragon is offline   Reply With Quote
Old 08-05-2017, 02:29 AM   #22
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Germany
Posts: 5,729
Default

Quote:
Originally Posted by Airal View Post
With your logic, one could say before reaper had midi support, that it is up to the OS to implement it
When Reaper got Midi support there already was a standard for Midi data streams as well in Windows as in Mac, provided by the OS and/or many hardware and software tool suppliers, and used by many other user software products.

So Reaper just needed to follow.

-Michael
__________________
www.boa-sorte.de
mschnell is online now   Reply With Quote
Old 08-05-2017, 02:32 AM   #23
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Germany
Posts: 5,729
Default

Quote:
Originally Posted by EvilDragon View Post
There does seem to be a win32 wrapper for UWP MIDI API, it seems.

https://blogs.windows.com/buildingap...in-windows-10/
Great !!!!
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
__________________
www.boa-sorte.de
mschnell is online now   Reply With Quote
Old 08-05-2017, 02:36 AM   #24
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 22,024
Default

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
EvilDragon is offline   Reply With Quote
Old 08-05-2017, 04:52 AM   #25
Airal
Banned
 
Join Date: Nov 2015
Posts: 406
Default

Quote:
Originally Posted by EvilDragon View Post
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!
Cool!

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.
Airal is offline   Reply With Quote
Old 08-05-2017, 05:05 AM   #26
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 22,024
Default

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.
EvilDragon is offline   Reply With Quote
Old 08-05-2017, 05:50 AM   #27
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Germany
Posts: 5,729
Default

Quote:
Originally Posted by Airal View Post
It's C# and .Net but I see no reason why it couldn't be used,
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:
Originally Posted by Airal View Post
It requires using two uwp dll's: Windows.winmd and System.Runtime.WindowsRuntime.dll.
And the complete ".NET" Framework, blowing up the footprint of the program incredibly.

As seemingly a CIL/.NET -only API is provided by M$, translating the C# code to C++ is not an option.

-Michael
__________________
www.boa-sorte.de

Last edited by mschnell; 08-05-2017 at 11:14 AM.
mschnell is online now   Reply With Quote
Old 08-05-2017, 07:00 AM   #28
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 22,429
Default

Quote:
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.
I'd not have made it this far if I cared what any random joe says on the internet. You didn't answer any of my technical points in that reply so turning to statements like the above are annoying at best. If you want to win your points (and I am fair when convinced), you need to address technical rebuttals with technical answers.

Last edited by karbomusic; 08-05-2017 at 07:20 AM.
karbomusic is online now   Reply With Quote
Old 08-05-2017, 07:11 AM   #29
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 22,429
Default

Quote:
Originally Posted by mschnell View Post

And the complete ".NET" Framework, bowing up the footprint of the program incredibly.


-Michael
Typically this isn't the case, the program doesn't distribute .NET and the needed binaries are part of the OS already. There is an exception if it used .NET Core which is self-contained (depending) but in that instance, only the DLLs that are actually used are copied and... that is usually reserved for non-standard systems - think running a web server on a Raspberri Pi that is totally self-contained.

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.

Last edited by karbomusic; 08-05-2017 at 08:09 AM.
karbomusic is online now   Reply With Quote
Old 08-05-2017, 08:44 AM   #30
Airal
Banned
 
Join Date: Nov 2015
Posts: 406
Default

Quote:
Originally Posted by karbomusic View Post
I'd not have made it this far if I cared what any random joe says on the internet. You didn't answer any of my technical points in that reply so turning to statements like the above are annoying at best. If you want to win your points (and I am fair when convinced), you need to address technical rebuttals with technical answers.
That's good to know, most people get butt hurt pretty quick when someone tells them their wrong. I guess you are more mature than you look

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.
Airal is offline   Reply With Quote
Old 08-05-2017, 08:48 AM   #31
Airal
Banned
 
Join Date: Nov 2015
Posts: 406
Default

Quote:
Originally Posted by EvilDragon View Post
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.
As you wish master! Thanks for doing the dirty work and finding something that might get reaper to support this. Might be a while but at least Justin is aware.

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.
Airal is offline   Reply With Quote
Old 08-05-2017, 09:12 AM   #32
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 22,429
Default

Quote:
Originally Posted by Airal View Post
That's good to know, most people get butt hurt pretty quick when someone tells them their wrong. I guess you are more mature than you look
I look like my overdrive pedal per my avatar but telling me I'm wrong doesn't make me wrong.

Quote:
I didn't see you state anything technical so I didn't bother replying in a technical way.
The point that Soundbrenner appears to do exactly what I suggested - there is nothing stopping the maker of device X to create a driver that just handles all of this and presents a standard MIDI device to the OS. That's just basic separation of concerns 101 which is quite normal and expected in programming - it's not something I made up.

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.

Last edited by karbomusic; 08-05-2017 at 09:19 AM.
karbomusic is online now   Reply With Quote
Old 08-06-2017, 08:12 AM   #33
Airal
Banned
 
Join Date: Nov 2015
Posts: 406
Default

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].
Airal is offline   Reply With Quote
Old 08-06-2017, 08:14 AM   #34
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 22,024
Default

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.
EvilDragon is offline   Reply With Quote
Old 08-06-2017, 10:46 AM   #35
Airal
Banned
 
Join Date: Nov 2015
Posts: 406
Default

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.
Airal is offline   Reply With Quote
Old 08-06-2017, 11:52 AM   #36
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 22,429
Default

Quote:
Originally Posted by Airal View Post
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.
.
^That idea is 20 years old now, it's what I've been trying to explain to you as the reason Reaper really shouldn't need to write code for it. It's exactly what I've been saying, glad you came around to saying exactly what I said.

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:

Writing windows devices drivers is no easy task and most programmers couldn't do it
Not true, the only difference between a driver and just a piece of software that talks to hardware is the fact the driver loads when the OS does and/or runs as a service, that's it. I've written a few for my own hardware (I program microprocessors for IOT and some music related stuff).

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.

Last edited by karbomusic; 08-06-2017 at 11:59 AM.
karbomusic is online now   Reply With Quote
Old 08-06-2017, 12:23 PM   #37
Airal
Banned
 
Join Date: Nov 2015
Posts: 406
Default

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.
Airal is offline   Reply With Quote
Old 08-06-2017, 01:47 PM   #38
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Germany
Posts: 5,729
Default

Quote:
Originally Posted by Airal View Post
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.
While I don't doubt this, C# and .NET have not been designed with realtime in mind, but for "office"-type of applications.

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
__________________
www.boa-sorte.de
mschnell is online now   Reply With Quote
Old 08-06-2017, 03:27 PM   #39
Airal
Banned
 
Join Date: Nov 2015
Posts: 406
Default

Quote:
Originally Posted by mschnell View Post
While I don't doubt this, C# and .NET have not been designed with realtime in mind, but for "office"-type of applications.

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
Yes, that is the draw back of .NET. In fact, for some things it's quite fast when used right and you can also split up the time critical parts and write them in whatever you want then link them in to .NET. So it's not a total loss. .NET is also not great for graphics(well, maybe wpf). But like most things, there are workarounds if one wants to put in the effort.

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.
Airal is offline   Reply With Quote
Old 08-06-2017, 05:48 PM   #40
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 22,429
Default

Quote:
Originally Posted by Airal View Post
---

Have you actually ever written a device driver? Or worked through the ddk?
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.

Last edited by karbomusic; 08-06-2017 at 09:34 PM.
karbomusic is online now   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 11:30 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.