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.
 

Hey Michael, so I guess the question is, what do you want to be able to accomplish that you can't now?
 
The intent of Auto Echo is make it easy to rehearse and record different MIDI/Instrument tracks just by placing focus on them. Conveniently, the last chosen MIDI track will keep echoing when you move focus to the corresponding audio/synth track to adjust levels, or maybe tweak an FX while you trigger the synth from the keyboard and listen to the result. The case where you disable Input echo by using the echo button in the folder control is the only way you can get SONAR to temporarily show no MIDI track echoing, but when you move focus to another track, Auto Echo is re-invoked, and echoing of the last touched MIDI track is restored.
 
In my view this, this is all working as designed, and I don't see how any of it is a problem. If you want be able to have no track auto-echoing, just go to Preferences > MIDI > Playback and Recording, and disable Always Echo Current MIDI Track. And if you want to force some track to "Omni", choose All Inputs - Omni; it's the same thing by a different name.
 
 
 
 

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.

I guess the bottom line for me is that if playback of existing MIDI clips is silent on any track, the input assignment should have no bearing on that, and is the last place I would look when troubleshooting. If you can come up with a reproducible scenario where it *is* relevant, you should run that by the bakers with a problem report including a copy of the offending project, although it will probably be difficult or impossible to reproduce without having exactly the same MIDI/audio hardware config.
 
The only thing I can think of that fits the kind of intermittent issue you're describing would be the MIDI Prepare Using Buffer being too low. Every other cause would usually require some explicit correction (disconnected synth, muted tracks/lanes/clips/notes, velocity too low, incorrect MIDI/Audio channel or output assignment, no patch loaded, notes out of range for the patch, soloed track out of view, etc., etc.). As we all learn over time there are more possible causes of "no sound" than you can shake a stick at, but the vast majority of them are persistent until resolved by some explicit corrective action.
 
 
 
 

+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.).