Allow User to select "Omni" for MIDI track manually

EDIT: I did a second pass on what I did earlier and documented behavior that needs addressing. Bold-faced text is added.
 
I do not power of my MIDI controller religiously and noticed behavior that could be better. MIDI Interface is Roland A-300 PRO.
 
Situation: I recorded a part with Dim Pro using a MIDI controller.

1. On a subsequent opening (controller off), I got no sound and input was set to "none." I turned on the controller, and SONAR recognized it and realigned the input to when recorded. Great! Then out of curiosity, I switched the controller off and sent SONAR into "not responding mode" (my first confirmed SONAR kill).
2. Second time, I didn't want to use the controller... so I set input to Dim Pro 1 Omni. Simple.
3. Third time I want to use the controller again so diligently power it up and input is still "Dim Pro 1," so SONAR doesn't remember assignments other than if had shifted to "none."
4. Second pass on this: Input was saved to "Dim Pro 1." I opened the project with the A-300 off then turned it on. SONAR never acknowledged it coming online.
5. Left the A-300 on, closed/reopened SONAR, reassigned input to A-300, then shut off A-300. SONAR recognized the drop and asked to re-assign. Input then read "Omni" but the dropdown reads "None"?? This is not consistent with the first pass.
6. Saved, closed, shut off A-300. Reopened and Input reads "None" but plays. I click the dropdown (select nothing) and it changes to "Onmi" again on its own? (see pic below).
7. "Omni" is not consistent firing track data (input echo can be on or off), and when I ALT-Tab to take notes, the first track I click in SONAR (regardless of what it is) turns "Auto-echo" on for this track. (Incidentally, AD2 is also loaded, and Auto-echo never engaged once during this for that synth.
8. The crash is repeatable... basically clicking the Input selection dropdown (and leaving it open) while powering off the A-300, and wait till SONAR recognizes it going offline (10-15 seconds). The instant the pop-up warning appears, this locks Windows "as is" but allows for CTRL-ALT-Del to be used. For this iteration I had the transport running, and SONAR kept playing the track, just nothing responds to input. (see pic below).

 
 
 
Feature Request:

1. I like that SONAR sensed and reassigned the MIDI input correctly when the project came online with no controller, and the controller was then turned on!
2. SONAR did have an "Onmi" on subsequent tries, but is not a selectable option. Does this refer to "track data"? Omni should be a user selectable option for this situation. "None" in the above situation should still fire MIDI existing in the track as "#1 priority." This allows for the controller to "be remembered" and still work if not desired. Assigning INPUT to Dim Pro 1 is irrelevant, since this IS Dim Pro 1's track, and it outputs correctly.
3. Allow for a user to disconnect an input device without SONAR going into "not responding" mode. This is specific to having the input drop down open when the pop up occurs.
4. Why is auto-echo enabling when Dim Pro is not the active track? Each time I ALT-Tab to take notes, the first track I click in SONAR auto-echos Dim Pro (but never did such to AD2).

 
 

I've been wanting 'None' = 'Nothing' instead of 'Everything' since PA9 ...
 
Are you saying 'None' should continue to be the same as 'Omni'?

MIDI Track Input = None has always worked if you don't have Always Echo Current MIDI Track enabled. The problem is that this setting insists on having an input source to echo, and it defaults to All Inputs - Omni, but only displays the word "Omni". I entered a problem report a long time ago about this inconsistency.
 
As for not getting playback when Input = None. I've never seen that, and can't reproduce it now.
 
Is the Not Responding on disconnecting a USB-based MIDI In reproducible? I've not run into that, either, but I don't have any USB-connected keyboards and it's never occurred to me to try turning off my MOTU MIDI Express XT interface while SONAR is running with a project open.    I'll try it later, but I suspect that might be USB-MIDI port driver-specific.
 
 

I think if you turn off Always Echo Current MIDI track, you'll find that the behavior is a lot more consistent and predictable when MIDI ports come and go with a project open. But I think your "Not Responding" issue is related to the specific USB-MIDI driver your keyboard is using.
 
I double-checked all of this, and found no issues. I can turn my MIDI interface on and off at will regardless of the project state, and all that happens is hardware synths go silent because they're not receiving MIDI. If I do it during playback, the sound goes away and comes back without issue along with the ports. Softsynth MIDI, Audio and Simple Instrument tracks are completely unaffected by hardware ports coming and going.
 
And port assignments do not change except when opening a project with the interface turned off. Then Inputs will show "None". But if you close the project without saving, turn the interface on, and re-open the project, the original assignments are restored.
 
Problems arise when you have Always Echo enabled and there are soft synth outputs available to set as Input for MIDI tracks when the hardware ports go away. And if you save a project with the wrong ports assigned, naturally, it will come up that way the next time you open it.
 
Actually, the None/Omni thing is working better than it used to. With Always Echo enabled, the input of a track will switch from None to Omni when it has focus, and switch back to None when the focus moves to another MIDI track. Moving focus to an audio/synth track leaves the last focused MIDI track at Omni, which is also a good thing, I think.
 
Hope that helps explain some things.
 
 
 
 
 

Okay, so it seems a big part of why I don't see a problem on shutting off my interface is that, for whatever reason, the driver is not being unloaded no matter how long I leave the interface powered down. So SONAR doesn't see it go missing, and never prompts to re-assign. I totally forgot that prompt even existed because I haven't seen it for so long.
 
If anything, I would say that this part of the puzzle should be entered as a bug; anything that locks up SONAR should, even if it's due to "user abuse". 
 
As for the None/Omni thing, "Omni" should just be interpreted as meaning "None is selected, but Auto-Echo is enabled, so I'm going to echo every channel on every port". Functionally, Omni is equivalent to All Inputs - Omni, but SONAR is distinguishing between whether it's the result of Auto-Echo or manually forcing Echo On (or deliberately selecting All Inputs - Omni).
 
If you force Echo On, the input will change to All Inputs Omni, and stay that way. Although I previously thought of this as an inconsistency, I can see that it's useful to distinguish between the two modes. In the one case, the input is going to change back to None when focus moves to another MIDI track, and on the other case it won't. Maybe it should be called "Auto-Omni".
 
I tried Alt-tabbing to Wordpad and back with auto-echo enabled, and didn't find anything amiss. Whatever MIDI track had Auto-Echo enabled when I tabbed away was still Auto-Echoing when I tabbed back, and the MIDI track for AD2 behaved no differently from other MIDI track.
 
 
 
 

I just submitted problem reports against the above post.
 
CWBRN-32074 - Auto Echo only functions properly when selecting a new MIDI track.
 
CWBRN-32075 - SONAR program hang when a controller change is recognized while a menu is open.
 

Hi Dave, from my workflow perspective, I will often work in sections so will hop between tracks and insert MIDI phases in sort of an ad hoc fashion. I leave my controller set to channel 1, so while doing this the auto echo isn't an issue because I am working on that track. What I have noticed at times and never researched in depth is when I sit down to do audio recording. In some instances, I have seen MIDI tracks with data in them "go silent," seemingly on their own. This seems to occur most often with Dimension Pro, but not sure if that is an accurate statement.
 
I think from the "big picture" perspective is more that MIDI data in a MIDI track should be the #1 priority to what goes to the output of that track (which is always left accurate). In essence, very similar to working with audio in that the Mute/Solo button are the primary "off/on" controls.
 
Perhaps my workflow needs adjustment, as the hopping around and leaving the controller off may be exacerbating it all.

+1 That is much more clear to what my point is. MIDI still gets me many times, but the bottom line is that with MIDI data inside a track, that data should go to the output "by default" (barring Mutes or Solos in other tracks).
 
I am just getting into working with Platinum, but am opening older projects as I get going. I will keep a closer eye on this as I delve into other projects that are more robust. IIRC, it seems that most cases I have noticed this with had their MIDI data initially entered via controller rather than any other means (SS, loops, PRV, etc.).