gustabo
To connect a non-vst standalone midi capable app with a daw host.

+1
 
Yup!

abacab

gustabo
To connect a non-vst standalone midi capable app with a daw host.

+1
 
Yup!

I use it to connect a standalone app that remaps midi channels and note assignments of my e-drums to Sonar.
 

AdamGrossmanLG

arachnaut
I use Loopbe30 all the time to send MIDI data from external programs (like Reaktor, Fractal Tune Smithy, etc.) to Sonar.
 
I've used it in Windows since the XP days.
 
I don't ever recall any type of crash where the system was hung in the LoopeBE driver.
 
I have 2 MIDI ports enabled and do not use the shortcut detection monitor.
 

 
wait, but cant you just insert Reaktor as a VST synth?   Why do you need LoopBe for it?

Yes, that is true now, but previous versions of Sonar were not very reliable with multiple channels of MIDI.
So it is a habit I got into.
 

Update: I did some more testing and it does appear that LoopBe30 is multi-client.  I can run a standalone application (Liquid Notes) that uses a single port routed to a VSTi in my DAW, as well as using that same port to drive a standalone soft synth at the same time.  I'm not sure that I need to do this, but it proves that I can.
 
Anyway, the point of whether the driver is actually active in Windows after a DAW crash is not clear to me at this point.  The fact that this is a multi-client driver makes it hard to determine if it is really stuck.  The driver is still available and works when called on by an application, even after it appears to have a "stuck" stream in Windows powerfcg.
 
Bottom line:  So maybe this is just a Windows powercfg issue.  Anyway, once powercfg shows LoopBe with an active stream, it can prevent Windows 10 from sleeping with an idle timer.  The only solution I have found for that so far is to reboot.
 
Sonar rarely crashes for me, so this is not a huge issue.  But wondering why my PC was not sleeping intermittently was driving me nuts!  I will continue to use LoopBe and Sonar and enjoy both
 
Anyway, here is the free version: http://www.nerds.de/en/loopbe1.html
and the 30 port version http://www.nerds.de/en/loopbe30.html
 
LoopBe1 is a native Windows™ WDM kernel mode driver, so expect the lowest possible latency. Programs do not need to link with special libraries, so LoopBe1 works with every MIDI or DirectMusic™-capable application.

I'm guessing, but what I think might be happening is this.

Loop.be gets the 'in use' signal from the DAW. The driver then does as it should and notifies Windows that it's in use. Amongst other things that should prevent Windows paging the driver out to the swap file or allowing the driver/device to go to sleep.

Loop.be will then notify Windows it's no longer in use when and if it receives a "thanks, done with you now” signal from the software it's providing a service for. If that software, Sonar in this instance, crashes then it doesn't send the 'release' signal to the driver which in turn doesn't tell Windows it's no longer in use. The crashing application might even be supposed to send that signal on crash, but once into a crash situation all bets are off as to what happens.

I've used Loop.be for years and never had a problem with it causing crashes, but I've seen Sonar crashes leave it active. I've also seen both Sonar and Live not release the audio driver either if they crash. I've also seen games and Photoshop crash and leave the video driver locked to the application's resolution or even a frozen screen and/or the audio driver emitting a constant (loud) noise and Windows unable to return to the usual state of affairs without a reboot.

I guess the motto is that if something crashes on a Windows system then at least log off and back on again and if that doesn't return things to normal then it's time for that old faithfull - reboot Windows.

tlw
I'm guessing, but what I think might be happening is this.

Loop.be gets the 'in use' signal from the DAW. The driver then does as it should and notifies Windows that it's in use. Amongst other things that should prevent Windows paging the driver out to the swap file or allowing the driver/device to go to sleep.

Loop.be will then notify Windows it's no longer in use when and if it receives a "thanks, done with you now” signal from the software it's providing a service for. If that software, Sonar in this instance, crashes then it doesn't send the 'release' signal to the driver which in turn doesn't tell Windows it's no longer in use. The crashing application might even be supposed to send that signal on crash, but once into a crash situation all bets are off as to what happens.

I've used Loop.be for years and never had a problem with it causing crashes, but I've seen Sonar crashes leave it active. I've also seen both Sonar and Live not release the audio driver either if they crash. I've also seen games and Photoshop crash and leave the video driver locked to the application's resolution or even a frozen screen and/or the audio driver emitting a constant (loud) noise and Windows unable to return to the usual state of affairs without a reboot.

I guess the motto is that if something crashes on a Windows system then at least log off and back on again and if that doesn't return things to normal then it's time for that old faithfull - reboot Windows.

I believe that is a very lucid synopsis of the situation!
 
At least we no longer live in the bad old days before the Windows NT kernel, where an app crash usually brought the whole Windows system down!  It's mostly up to the drivers now to provide the blue screen entertainment these days.  Progress ...