@George:
Hi, look at the first image I posted. The key switch notes there may look like a few very long notes, but in fact they are a few chains of hundreds of 16 notes, which will always play the intended articulation (this would make staff view messy that's also why I think it's best to use a separate track for key switches). In Studio One, there's a feature called Chase Long Notes, which plays long notes that start before the playback start time. I wish Sonar had it too so that I wouldn't have to draw lines of 16th notes. For how to conveniently draw a long line of short notes, ask Samuel because it's he who told me how. He might not remember it, though :)

@Samuel:
You don't need to add all keys in the drum map if you use the Pass Through map. But what's good about drum map is that you can hide (delete) ghost layers which you don't want to see in the PRV drum grid pane. Look at my first screenshot above. The view displays only the keyswitch layers, which eliminates the need to scroll the PRV when you work in both TV and PRV on one screen, for example.

@George
Thanks George. Yeah. This lack of adaptation to today’s needs in MIDI-editing is something that annoys me daily, working with especially key switches.. As you (and everyone) is saying; there are workarounds. I just think it’s sad that there is a need for workarounds to something that has been a standard for MIDI-instruments for so long. :)
 
___________
 
___________
 
Still, no one has yet mentioned anything of wanting to have something like this implemented (Except George that at least doesn’t like the workarounds). Everything has been about workarounds and the benefit of their own way of doing it. Have you really thought this through? You really can’t see the superior benefits of having everything available in one track (with the diatonic keyboard).
 
Another implementation of this (aside from the one in my first post) could be a simple addition to the Drum Map Manager. If we were able to configure a MIDI-chn. and out port for the diatonic view (that currently just becomes inactive when using DM) this would totally open up the use for key switches with the drum map functionality. Could look like something like the image below, in the Drum Map Manager window:
 

I agree in principle to the original post. A standard would nice. I use a few DAWs - from a MIDI control perspective the Steinberg approach is definitely the most mature (VST expression) - if there's a standard to adopt, this IMO would be it.
 
The workarounds mentioned above are good, in the absence of an OEM solution; but a single foldable track per instrument is preferable, logical and neat.  
 
My 2c.

KoisanX
I agree in principle to the original post. A standard would nice. I use a few DAWs - from a MIDI control perspective the Steinberg approach is definitely the most mature (VST expression) - if there's a standard to adopt, this IMO would be it.
 
The workarounds mentioned above are good, in the absence of an OEM solution; but a single foldable track per instrument is preferable, logical and neat.  
 
My 2c.

Hi KoisanX and welcome to the forums!
 
Wow! I had no idea that other DAWs were lightyears ahead of Sonar when it comes to this...! That's REALLY sad! =( .. I checked out some youtube clips about the VST expression-function implemented by the Germans... It looks amazing!! :O ..What happened with "Sonar being the best DAW for MIDI"!?!! I think I'm going to cry now....
 
Cakewalk REALLY have to look into this! It's embarrassing, to say the least, how far behind Cakewalk is when it comes to MIDI. =/
 
It feels like they've dropped the MIDI side of Sonar completely (thinking about everything I've read on these forums about the staff view too) and only have been focusing on the audio-side for a long time now... It's really about time now to even this out, I think.. 

This is a very good topic and I appreciate the O Poster for bringing it up. The existing methodology for handling keyswitches is clumsy and confusing. It is clumsy because it is nearly impossible to remember which keys are assigned to which switches and confusing because you always need to scroll back to see the last key switch that was activated.
 
I think that what we really need is a method whereby we could have the KEYS (as in a diatonic keyboard) have a area to show a clearly defined description of the keyswitch(es)  and that the keyswitch area or notes assigned to keyswitches be a different color to designate this. Also and this is very important, the keyswitch note value should always advance to the last true note played or extend to the current now time position. That way we would always know what the last switch used is. The software is supposed to lookback anyhow so that shouldn't be too hard.
 
The problematic thing is that sample library producers tend to use whatever note range or ranges that  that are not being used by the current sample set. It could be last octave or maybe even a few upper notes or anywhere in between. I see that that can be a issue for a developer trying to work out a standardized system. Maybe a specific sort of control code to designate "THIS IS A KEYSWITCH". But if a system could be developed, maybe all library developers could take advantage of it and incorporate it within their libraries.
 
As someone that uses orchestral libraries all the time, I see this a very good topic and a problem that has be totally overlooked by DAW developers.

Loptec
..Not to mention that the keys your strike on your physical MIDI-controller don’t lit up when using DM or anything other than the diatonic keys in PRV. This is something I also find very strange.

 
Totally agree.
 

Loptec
You really can’t see the superior benefits of having everything available in one track (with the diatonic keyboard)..

 
I forgot to mention one thing. The reason why I decided to use a separate track for keyswitches wasn't actually because I wanted to use a drum map to display the keyswitch names. It was because I accidentally deleted keyswitch events once or twice when I just wanted to delete musical data to re-record the take (obviously, I delete the clip itself without realizing it contained keyswitch events). I always work on several projects at the same time and I forget which clips contain keyswitch events, so this mistake can happen again and I really don't like that. So, in my case, it's a superior benefit (it's interesting to see how our views differ).

Loptec
Wow! I had no idea that other DAWs were lightyears ahead of Sonar when it comes to this

 
If I understand correctly he said he uses a few DAWs and Cubase's approach is the most mature but he didn't necessarily say other DAWs are light years ahead of Sonar in terms of this feature (but I'm curious to know which other DAWs have the ability to show keyswitch names on a diatonic keyboard). What I can say for sure is Studio One can't do it and Sonar is light years ahead of S1 in terms of MIDI overall.
 

I hate to say this, but I don't think CW will change the current approach. They have more things to do (they need to fix various bugs in X2). So, in reality, I think you'll have to use a workaround. But still, it's worth submitting the request via the official FR page (I'm sure bakers are reading this thread, though). 
 

pianodano
Also and this is very important, the keyswitch note value should always advance to the last true note played or extend to the current now time position. That way we would always know what the last switch used is.

You'll no longer suffer from this if you use the approach I posted earlier. 
But yes, I wish Sonar had the Chase Long Notes feature (so that we can hear every part even when we start the playback in the middle of a bar).

Jlien X

Loptec
You really can’t see the superior benefits of having everything available in one track (with the diatonic keyboard)..

 
I forgot to mention one thing. The reason why I decided to use a separate track for keyswitches wasn't actually because I wanted to use a drum map to display the keyswitch names. It was because I accidentally deleted keyswitch events once or twice when I just wanted to delete musical data to re-record the take (obviously, I delete the clip itself without realizing it contained keyswitch events). I always work on several projects at the same time and I forget which clips contain keyswitch events, so this mistake can happen again and I really don't like that. So, in my case, it's a superior benefit (it's interesting to see how our views differ).

 
I find the key switches too connected with the rest of the performance to want to save them if I need to re-record a take. If I’m not happy with the performance in a MIDI-clip I always open it up in PRV and most often edit the clip (with the mouse) to get it right. If there is a need to re-record the whole thing I see no need to save the key-switches anyway, since the performance will differ anyway.
 

Jlien X

Loptec
Wow! I had no idea that other DAWs were lightyears ahead of Sonar when it comes to this

 
If I understand correctly he said he uses a few DAWs and Cubase's approach is the most mature but he didn't necessarily say other DAWs are light years ahead of Sonar in terms of this feature (but I'm curious to know which other DAWs have the ability to show keyswitch names on a diatonic keyboard). What I can say for sure is Studio One can't do it and Sonar is light years ahead of S1 in terms of MIDI overall.
 

 
 
You’re right. He didn’t say other DAWs are lightyears ahead. That was my statement and is my strong view of this, that was formed just by some quite browsing around youtube. It’s as he says though that Steinberg’s approach is the most mature and only by checking out their solution makes it very clear how far (“lightyears” IMHO) behind Cakewalk is regarding this.
______________________
 

pianodano
This is a very good topic and I appreciate the O Poster for bringing it up. The existing methodology for handling keyswitches is clumsy and confusing. It is clumsy because it is nearly impossible to remember which keys are assigned to which switches and confusing because you always need to scroll back to see the last key switch that was activated.
 
I think that what we really need is a method whereby we could have the KEYS (as in a diatonic keyboard) have a area to show a clearly defined description of the keyswitch(es)  and that the keyswitch area or notes assigned to keyswitches be a different color to designate this. Also and this is very important, the keyswitch note value should always advance to the last true note played or extend to the current now time position. That way we would always know what the last switch used is. The software is supposed to lookback anyhow so that shouldn't be too hard.
 
The problematic thing is that sample library producers tend to use whatever note range or ranges that  that are not being used by the current sample set. It could be last octave or maybe even a few upper notes or anywhere in between. I see that that can be a issue for a developer trying to work out a standardized system. Maybe a specific sort of control code to designate "THIS IS A KEYSWITCH". But if a system could be developed, maybe all library developers could take advantage of it and incorporate it within their libraries.
 
As someone that uses orchestral libraries all the time, I see this a very good topic and a problem that has be totally overlooked by DAW developers.

 
I agree with everything you say :)
 

Jlien X
I hate to say this, but I don't think CW will change the current approach. They have more things to do (they need to fix various bugs in X2). So, in reality, I think you'll have to use a workaround. But still, it's worth submitting the request via the official FR page (I'm sure bakers are reading this thread, though). 

 
I actually think they'll have to change their approach to this if they want to compete with other DAWs. Software instruments are getting better and better and (with some MIDI-skills) it's impossible to hear the difference today between a software instrument and the real deal.
 
More and more people are using software instruments instead of hiring real orchestras, choirs or what ever even if they have the budget, just because the software sound so real.
 
Sure.. Cakewalk's got to fix the bugs as well, but I don't think this subject is something they can ignore if they want to survive in the long run..

Loptec

Jlien X

Loptec
You really can’t see the superior benefits of having everything available in one track (with the diatonic keyboard)..

 
I forgot to mention one thing. The reason why I decided to use a separate track for keyswitches wasn't actually because I wanted to use a drum map to display the keyswitch names. It was because I accidentally deleted keyswitch events once or twice when I just wanted to delete musical data to re-record the take (obviously, I delete the clip itself without realizing it contained keyswitch events). I always work on several projects at the same time and I forget which clips contain keyswitch events, so this mistake can happen again and I really don't like that. So, in my case, it's a superior benefit (it's interesting to see how our views differ).

 
I find the key switches too connected with the rest of the performance to want to save them if I need to re-record a take. If I’m not happy with the performance in a MIDI-clip I always open it up in PRV and most often edit the clip (with the mouse) to get it right. If there is a need to re-record the whole thing I see no need to save the key-switches anyway, since the performance will differ anyway.

 
When I'm in the songwriting stage, note events of almost all MIDI clips are 100% quantized for convenience. After I'm happy with the chords and melodies, I randomize (humanize) all note events on all non-keyboard instrument tracks (e.g. drums, brass, strings). As for keyboard instrument tracks (organ, piano, etc.), I want to play and record the take myself without quantizing because I practice keyboard 
So, I need to delete just musical data.