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

Reply
 
Thread Tools Display Modes
Old 11-26-2016, 04:47 AM   #1
CT Blaze
Human being with feelings
 
Join Date: Nov 2016
Posts: 1
Default Windows 10: use of new audio and MIDI APIs - e.g. for aggregating audio devices

Hi there,

I suggest/request, that REAPER becomes the first professional DAW with
- low latency aggregation of multiple audio devices
- integrated support for MIDI over Bluetooth
(both on Windows 10 and upwards)

For years, many people have been disappointed about Windows and ASIO being so unflexible in configuration of multiple audio devices. But for low latency, ASIO is still the way to go (WHAT? wait, a quasi standard introduced by another DAW manufacturer??? No wonder it's inflexible )

Technologically, the two suggestions above, are now possible, as quite recently major changes in Windows 10 regarding audio APIs and MIDI APIs have been implemented. It seems that with "AudioGraph" API for the first time it could / should be possible to aggregate audio devices w/o loosing any milliseconds of latency. Instead, we could get better latency!!! Please refer to the following MSDN article for a full picture on AudioGraph/WASAPI:
https://msdn.microsoft.com/windows/h...-latency-audio

As for MIDI, Reaper could be the first to have an integrated MIDI over Bluetooth connectivity, as the new MIDI APIs allow for this "easily":
Ple see the following blog entry by Pete Brown, a major audio developer from Microsoft:
https://blogs.windows.com/buildingap...-in-windows-10


For REAPER, these features could even boost it more (on the Windows side, that is), as tey are important USPs on the current market.

Anyone who is questioning the need for aggregating audio devices: it's only one scenario to cascade more inputs/outputs. But recently, so many devices, like synths, drum machines, FX gear have decent audio interfaces implemented on board (24bit/96kHz), that it's just a shame not to be able to uitilize those for direct input into the DAW but instead still having to record them via the main audio device OR switch audio devices in the project config. Both workaround approaches suck big time, and for live appliance there is not even a workaround. Just can't be done.

It is time for somebody to go ahead and implement either a REAPER only solution won the grounds of the new audio API possibilities, or relieve ASIO in Windows with something way better, utilizing the new capabilities of Windows. And then make it an industry quasi standard, because you were the first!

Go ahead, Cockos =8)

---
EDIT: examples of non typical devices having an audio interface:
Roland Aira series (incl. Modular FX!), Roland (Boutique) Synths, more Roland stuff, many other synths and modular systems

Last edited by CT Blaze; 11-26-2016 at 05:24 AM.
CT Blaze is offline   Reply With Quote
Old 11-26-2016, 04:59 AM   #2
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
Default

Sadly, Justin doesn't seem to be that ecstatic about it...

http://askjf.com/index.php?q=3235s

Also: http://askjf.com/index.php?q=3238s

All the API examples seem to be C#, which Justin&co. aren't using (or excited about)...
EvilDragon is online now   Reply With Quote
Old 11-26-2016, 12:01 PM   #3
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,686
Default

Quote:
Originally Posted by EvilDragon View Post
All the API examples seem to be C#, which Justin&co. aren't using (or excited about)...
That is very understandable !!

C#, like Java, (usually) is a language that needs a Framework to make thge programs run and hence is absolutely not appropriate to demo OS APIs, that (like Audio and any other "realtime"-stuff) needs low level access by the programmer.

(But if there is a decent documentation you don't necessarily need examples.)

-Michael
mschnell is offline   Reply With Quote
Old 11-26-2016, 12:05 PM   #4
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 29,260
Default

Better stated as .NET guys since C#, Managed C++ and others using the .NET framework all compile down to the same resulting machine code.
__________________
Music is what feelings sound like.
karbomusic is offline   Reply With Quote
Old 11-26-2016, 12:15 PM   #5
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,686
Default

AFAIK, you are right that C# can be compiled to machine code, but this additional stage of complexity is seldom used.

I don't vote strictly against C#, but in fact, IMHO, Microsoft failed to establish C# as a ubiquitous language and ".NET" (aka CIL) as a ubiquitous framework to have software run on multiple architectures without recompiling (even though the concepts seem to be really good), because Java, JVM and Dalvic took over. (You might know that Microsoft already dumped "Silverlight" (aka C# programs running in a browser).

Anyway. using C# for API example is a really bad idea, as with example the programmer needs to be really close at the low level to check performance and site-effects. C# - be it compiled or running in the framework makes it problematic to measure these things.

-Michael
mschnell is offline   Reply With Quote
Old 11-26-2016, 12:46 PM   #6
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 29,260
Default

Quote:
Originally Posted by mschnell View Post
AFAIK, you are right that C# can be compiled to machine code, but this additional stage of complexity is seldom used.

I don't vote strictly against C#, but in fact, IMHO, Microsoft failed to establish C# as a ubiquitous language and ".NET" (aka CIL) as a ubiquitous framework to have software run on multiple architectures without recompiling (even though the concepts seem to be really good), because Java, JVM and Dalvic took over. (You might know that Microsoft already dumped "Silverlight" (aka C# programs running in a browser).



-Michael
I'm not supporting C#, just making sure we have the right terminology that we are talking managed code not the language. However, you might be surprised to find that C# is far more ubiquitous than you think and has replaced gobs and gobs of native code (so has Java) but that isn't really the point I'm trying to make other than so many people tend to misunderstand what it actually is and how much it is used.

There would be some latentcy issues with extremely time-sensitive needs which is about the only places native code remains but I will predict here and now that native code, will eventually become mostly obsolete with everything that needs it being served up as underlying libraries. It's just a matter of time at this point (whether that be Java, C#, managed C++ whathaveyou). There is a LOT of code in apps like Reaper where being managed would make no performance difference at all.

Quote:
Anyway. using C# for API example is a really bad idea, as with example the programmer needs to be really close at the low level to check performance and site-effects. C# - be it compiled or running in the framework makes it problematic to measure these things.
As managed catches up and exposes more and more underlying functionality this will matter less and less until it doesn't matter any more - at best, developers will write small components native and the rest as managed (there is nothing preventing an app from using both). It's the same reason people moved to slow ass native code from assembly because at some point, we don't need to reinvent the wheel every time we need a wheel. Native code is exponentially slower to develop in, it can't last as the mainstay forever. It is a little harder to debug until you get over the curve and XPerf is your friend hint hint.

As far as Silverlight, it was outgrown. It was originally part of the Avalon project which served a number of purposes, which turned into the presentation framework which was designed (and does) solve all those issues with ugly theming, square buttons and the like - AKA all those graphical elements people complain about in reaper that still use antiquated UI libraries going back to the '90s. The Silverlight browser component was just the piece of that which was to compete with flash but again, those became obsolete outside of the framework itself and has nothing really to do with managed code.
__________________
Music is what feelings sound like.

Last edited by karbomusic; 11-26-2016 at 12:55 PM.
karbomusic is offline   Reply With Quote
Old 11-26-2016, 11:53 PM   #7
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,686
Default

Quote:
Originally Posted by karbomusic View Post
Native code is exponentially slower to develop in, ...
Why do you think so ? There are multiple languages that can create as well managed as native code from the same source. Where is the difference when creating software? IMHO the advantage of managed code is just with the distribution of the product (including "libraries", as you stated).

Quote:
Originally Posted by karbomusic View Post
The Silverlight browser component was just the piece of that which was to compete with flash but again, those became obsolete outside of the framework itself and has nothing really to do with managed code.
With Silverlight browser based projects obviously only managed code can be used, as it needs to run in the framework, independent of the (unknown at compile time) target architecture and boxed in a jail. Flash (hence "Action Script" managed code) is phased out, as well. Right now "WebAssembler" (Java "byte-" (i.e. managed) code running in the browser) is getting standardized (Firefox with WebAssembler support due out Q1 2017). WebAssembler with HTML4+ obviously will replace as well Flash as Silverlight, and this is yet another blow in favor of JVM/Dalvic against .NET/CIL as the leading managed code / arch independent framework infrastructure.


-Michael

Last edited by mschnell; 11-27-2016 at 12:57 AM.
mschnell is offline   Reply With Quote
Old 11-28-2016, 07:38 AM   #8
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 29,260
Default

Quote:
Originally Posted by mschnell View Post
Why do you think so ? There are multiple languages that can create as well managed as native code from the same source. Where is the difference when creating software? IMHO the advantage of managed code is just with the distribution of the product (including "libraries", as you stated).
Honestly, I don't know how anyone couldn't be aware how writing in native code vs managed is quite long-handed in comparison unless maybe they haven't really spent much time in the later iterations of managed code. I won't go into all the productivity differences which is one of two reasons managed code exists, the other is thread/type safety and not having to manage your own memory and a number of other advantages which is almost absurd to have to worry about in 2016.

This isn't my pushing it, I get no benefit here, it's just observing that native will become 'more' obsolete except for the few areas where it can't be done in managed which is always getting smaller. Care to make a friendly wager on that one?
__________________
Music is what feelings sound like.

Last edited by karbomusic; 11-28-2016 at 07:48 AM.
karbomusic is offline   Reply With Quote
Old 11-29-2016, 04:06 AM   #9
Kadmium
Human being with feelings
 
Join Date: Aug 2012
Posts: 11
Default

As far as the BLE MIDI stuff is concerned, there's a C++ DLL that hooks into UWP and provides that for native apps.
https://github.com/stammen/winrtmidi
Kadmium is offline   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 10:03 AM.


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