Rob[atSound-Rehab]

abacab

AdamGrossmanLG
Why do you use LoopBe to begin with?

Because it's useful to have a virtual MIDI cable.

I'm using loopMIDI with zero issues (live and studio). very reliable. not sure if it does all you need it to do but may be worth to check ...
 
https://www.tobias-erichsen.de/software/loopmidi.html
 

Thanks, but I have zero issues with LoopBe, (crash is not caused by LoopBe, by the way) and it works reliably. Not bashing this product, or Sonar.  But I do wonder if Sonar could be better at releasing all resources when it crashes.  Or maybe it does, and this is a Windows thing.  Who knows ...
 
Not looking for a fix, since this is easily resolved (reboot), and I actually have very few Sonar crashes. I just thought I should share this info about LoopBe remaining active following a Sonar crash, and the quirks regarding Windows sleep function. This could be very annoying if you want your PC to sleep.
 
If you Google for "why won't my Windows sleep", you will get over 36 million results.  Detecting the cause can be very difficult, as there are many possible reasons, so this is just one small drop in the pond (solved) ...

abacab
 
The driver starts every time I launch Sonar, as it is configured in Prefs > MIDI > Devices > 01. Internal MIDI.

I'm no O/S architecture genius, but my understanding has always been that drivers are loaded by the O/S at startup, ready for use by any app that needs them. And that would include drivers for virtual/emulated hardware. In the case of MIDI drivers, SONAR should only call the driver when it reads/writes the port, and that should only happen if the port is used in the project. Having "An audio stream is currently in use." as part of the status description suggests the port is actually in use, as opposed to just having the driver loaded by the O/S. And that makes me wonder if the crash is actually related to LoopBE.
 
I had LoopBE1 installed for a long time on my old Win7 machine and never had any issues recovering from a SONAR crash. But I also never let that PC sleep because it had unrelated issues when waking up. I don't think I've reinstalled it since moving to a new machine with Win10.

brundlefly

abacab
 
The driver starts every time I launch Sonar, as it is configured in Prefs > MIDI > Devices > 01. Internal MIDI.

I'm no O/S architecture genius, but my understanding has always been that drivers are loaded by the O/S at startup, ready for use by any app that needs them. And that would include drivers for virtual/emulated hardware. In the case of MIDI drivers, SONAR should only call the driver when it reads/writes the port, and that should only happen if the port is used in the project. Having "An audio stream is currently in use." as part of the status description suggests the port is actually in use, as opposed to just having the driver loaded by the O/S. And that makes me wonder if the crash is actually related to LoopBE.
 
I had LoopBE1 installed for a long time on my old Win7 machine and never had any issues recovering from a SONAR crash. But I also never let that PC sleep because it had unrelated issues when waking up. I don't think I've reinstalled it since moving to a new machine with Win10.

I agree that all Windows drivers are always present at boot time.  What I am saying here is that Sonar grabs this LoopBE driver every time Sonar is started, just like every other MIDI device configured in Sonar MIDI prefs.  This happens regardless of a LoopBE port being assigned to a track in a project. The in use status appears even at the Sonar start page with no project loaded.  If I start Sonar and look at "powercfg -requests" I will see "An audio stream is currently in use". This is normal.  If I exit Sonar normally, this status goes away.
 
The crash is DEFINITELY NOT related to LoopBe.  I was testing a SONiVOX plugin crash for another forum member in another thread.  That crash is reproducible every time I access a certain feature with my mouse in an AUDIO FX.  I can confirm that the LoopBE "An audio stream is currently in use." status is an artifact remaining after the Sonar crash and exit.
 
The LoopBe port is present in Sonar, but not is use.  The only MIDI in used with the tested VST was my keyboard controller. The VST itself was used in the FX bin of an audio track.
 
Maybe my Windows O/S architectural terminology is incorrect, but what I am trying to describe is real, and reproducible.   This is just info to be aware of in the event of a Sonar crash.  The resources used by Sonar may not be fully released.  That's all it is.  It could be Sonar, or LoopBE, or Windows, but it's probably not worth pursuing a fix.

abacab

brundlefly

abacab
 
The driver starts every time I launch Sonar, as it is configured in Prefs > MIDI > Devices > 01. Internal MIDI.

I'm no O/S architecture genius, but my understanding has always been that drivers are loaded by the O/S at startup, ready for use by any app that needs them. And that would include drivers for virtual/emulated hardware. In the case of MIDI drivers, SONAR should only call the driver when it reads/writes the port, and that should only happen if the port is used in the project. Having "An audio stream is currently in use." as part of the status description suggests the port is actually in use, as opposed to just having the driver loaded by the O/S. And that makes me wonder if the crash is actually related to LoopBE.
 
I had LoopBE1 installed for a long time on my old Win7 machine and never had any issues recovering from a SONAR crash. But I also never let that PC sleep because it had unrelated issues when waking up. I don't think I've reinstalled it since moving to a new machine with Win10.

I agree that all Windows drivers are always present at boot time.  What I am saying here is that Sonar grabs this LoopBE driver every time Sonar is started, just like every other MIDI device configured in Sonar MIDI prefs.  This happens regardless of a LoopBE port being assigned to a track in a project. The in use status appears even at the Sonar start page with no project loaded.  If I start Sonar and look at "powercfg -requests" I will see "An audio stream is currently in use". This is normal.  If I exit Sonar normally, this status goes away.
 
The crash is DEFINITELY NOT related to LoopBe.  I was testing a SONiVOX plugin crash for another forum member in another thread.  That crash is reproducible every time I access a certain feature with my mouse in an AUDIO FX.  I can confirm that the LoopBE "An audio stream is currently in use." status is an artifact remaining after the Sonar crash and exit.
 
The LoopBe port is present in Sonar, but not is use.  The only MIDI in used with the tested VST was my keyboard controller. The VST itself was used in the FX bin of an audio track.
 
Maybe my Windows O/S architectural terminology is incorrect, but what I am trying to describe is real, and reproducible.   This is just info to be aware of in the event of a Sonar crash.  The resources used by Sonar may not be fully released.  That's all it is.  It could be Sonar, or LoopBE, or Windows, but it's probably not worth pursuing a fix.

Yeah, I hear where you're coming from. I just couldn't see why SONAR would be touching a driver for a port that isn't used in a project. I would have thought that having a driver checked in MIDI devices is just to have SONAR make it avialable for selection in track I/O pick lists. I suppose it's possible that some state initialization occurs regardless of whether a port is used or not, but I would not have expected that.

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.
 

brundlefly
 
Yeah, I hear where you're coming from. I just couldn't see why SONAR would be touching a driver for a port that isn't used in a project. I would have thought that having a driver checked in MIDI devices is just to have SONAR make it avialable for selection in track I/O pick lists. I suppose it's possible that some state initialization occurs regardless of whether a port is used or not, but I would not have expected that.

Have you ever run Sonar with a MIDI driver that was not multi-client?  Try to start another application at the same time that needs to access that driver.

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.
 

I got LoopBe30 with Liquid Notes and that setup for use with Sonar.  It think it is pretty nifty.  I have also tried using it to patch a MIDI port between various applications, and it always seems stable and reliable.
 
I think LoopBe30 is working as designed, and is throwing a flag at Windows power management that basically says "hey there, don't go to sleep while I have an audio stream in use!".  Normally this only appears when the driver is being used by Sonar. This flag should be removed when Sonar exits. as it does when Sonar exits gracefully.
 
Just for grins, I tried this in Reaper.  In my PC, Reaper has LoopBe assigned in MIDI device prefs as "01. Internal MIDI Enabled+Control".  When I start Reaper, Windows does not get the active stream flag until I assign the MIDI input to an actual track in a project.
 
So, it would appear that Sonar reserves the driver exclusively when it starts, whereas Reaper waits until you actually use it.
 
I crashed Reaper intentionally and the LoopBe active stream status remained in Windows powercfg afterwards.  My thoughts are that this may be a Microsoft bug.  How is that possible? 

abacab

brundlefly
 
Yeah, I hear where you're coming from. I just couldn't see why SONAR would be touching a driver for a port that isn't used in a project. I would have thought that having a driver checked in MIDI devices is just to have SONAR make it avialable for selection in track I/O pick lists. I suppose it's possible that some state initialization occurs regardless of whether a port is used or not, but I would not have expected that.

Have you ever run Sonar with a MIDI driver that was not multi-client?  Try to start another application at the same time that needs to access that driver.

I don't know; my MOTU is multiclient. Is LoopBE not? I have used it in the past to send MIDI from one release of SONAR to another without a problem. And I have used it with Notion as well. But neither client would have been trying to use the same port at the same time. One would always be using the OUT, and one the IN.

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?

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