|
|
|
11-26-2016, 04:47 AM
|
#1
|
Human being with feelings
Join Date: Nov 2016
Posts: 1
|
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.
|
|
|
11-26-2016, 12:01 PM
|
#3
|
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,686
|
Quote:
Originally Posted by EvilDragon
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
|
|
|
11-26-2016, 12:05 PM
|
#4
|
Human being with feelings
Join Date: May 2009
Posts: 29,260
|
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.
|
|
|
11-26-2016, 12:15 PM
|
#5
|
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,686
|
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
|
|
|
11-26-2016, 12:46 PM
|
#6
|
Human being with feelings
Join Date: May 2009
Posts: 29,260
|
Quote:
Originally Posted by mschnell
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.
|
|
|
11-26-2016, 11:53 PM
|
#7
|
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,686
|
Quote:
Originally Posted by karbomusic
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
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.
|
|
|
11-28-2016, 07:38 AM
|
#8
|
Human being with feelings
Join Date: May 2009
Posts: 29,260
|
Quote:
Originally Posted by mschnell
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.
|
|
|
11-29-2016, 04:06 AM
|
#9
|
Human being with feelings
Join Date: Aug 2012
Posts: 11
|
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
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 10:03 AM.
|