How do you handle keyswitches?

I have a lot of sample libraries that use keyswitching (notes not assigned to a sound, used to change from one articulation to another).  I usually put the keyswitches on their own track so I can easily see where they are.  I wish X1 had some type of a "look back" feature for keyswitches the way it does for controllers so that when I start playback somewhere I don't have to worry about the correct keyswitch being active.
 
Anybody got any good work-arounds for handling this?

Hi, McGoo - It's an interesting idea.  I've seen it come up before, but I've never seen anyone get beyond the basic problem with the idea - which is trying to figure out how a program could interpret keyswitches as something distinct from notes, since keyswitches are in the normal ranges for low instruments. 

I guess it would have to be something that's programmed on a per-instrument basis.  Keyswitches are in the octaves lower than the lowest note in a given instrument's range - but as I'm saying, other instruments can have playable notes in that same range, so, on a instrument-by-instrument basis, there could theoretically be a way of programing Sonar to understand "These aren't notes, and need to be interpreted as data which you can search back to when play back is stopped."---

How I handle keyswitches is extremely straight forward.  Since they're at least an octave lower than the range of the instrument I'm working with, working in the PRV, I can see them down there below the range of the instrument - so I never have any confusion over them. 

Randy B.

Keyswitches aren't always low notes though.  East West puts them low and high depending on the instrument.  A double bass for example will have them high (above its playable range).  Many instruments have them both above & below the playable range.
 
Yeah it would be cool if Sonar could tell an individual track to "look back" for notes below and/or above a certain range.
 
 
 
 

Yep ...

drummaps are pretty useful ...

One guy set up loads of drum maps for the different EWQL SO. 
One tip ... create an additional track to use just the drum map on  (2 benefits - you can still transpose the music and also the prv in track view willl show the articulations for you. 

A few days ago I posted some thought on this in UnderTow's Suggestion List he maintains http://forum.cakewalk.com/tm.aspx?m=2193406
I'll duplicate the salient points here:
 
First, The Drum Map Editor really needs an overhaul.  It is very Windows 3.1'ish   The current interface and the functionality is quite lacking.  Some people (like me) use(struggle with) it to create articulation maps for libraries like EWQLSO.
I also suggest a funciton that would facilitate working with multiple instrument articulations for orchestra and other libraries.  It would contain an expression map editor to map and remap the articulation controllers, such as key switches, controller changes or MIDI channel remapping. Also, it would have a companion articulation lane on the PRV and/or Staff view,  similar to how you can view velocity and other CC information in their own lane.
 
And, since I mentioned Staff View, that needs an overhaul too.  I'll elaborate a bit.
 
If  Staff view or PRV had a separate lane that simply identified the channel that a particular note played, that would be a great great help.  Although I can, present state, change the articulation of a instrument by selecting an individual note in the Staff or PRV views and change its channel (thus articulation), I have no visual clue (other than reviewing the event list- yech) what channel that note is playing on after editing.   This functionality would not replace the Articulation function stated above, but it would go a long way getting there.  I'm not expecting the automatic keyswitching functionality of Overture or Sibelius (that would be an absurd request) - but something better than what is there now.
 

Apologies for being a little slow, but I'm not really getting the benefit of using the Drum Map.  Would this be simply to remap all the keystrokes to one zone that Sonar could deal with?  If so, that would be too much programming for me, at least the way the Drum Map is currently designed.  Since so many different instruments have so many different types of articulations, I can't imagine there's a way to have a standard assignment set.  Then again, maybe I'm missing something that is obvious to everyone else.  Please enlighten me!  Thanks.

Katie_Katie
 
And, since I mentioned Staff View, that needs an overhaul too.  I'll elaborate a bit.

I wouldn't hold your breath on that one. Sorry to be negative, but it's just not going to happen in any significant way.

I think the power of cubase's expression maps, or whatever they're called, really take shape in the staff view. In the context of a PRV, is it much more than a convenient "syntactic sugar" for tagging/identifying/manipulating controller data (plus the keyswitch management, of course, which is critical)?

What I'm trying to say is... the ability to manage key ranges explicitly, and treat those effectively as controller data (at least as far as lookback is concerned), would be a major step forward without necessarily having to implement some complex mapping and management facility, that really is just a nice/convenient way of presenting PRV data.

They could simply make a version of Drum Maps... call them Key Maps... that define your keyswitch ranges, take part in the lookback function, and maybe have some other nice doodads like channel mappings or even CC mappings.

Keyswitches are such an integral part of so many libs that managing those alone would give you the 80% for your buck, IMO...

Anyboady got any good work-arounds for handling this?

 
Hi Greg,
 
Kontakt's custom scripting could be used to circumvent the problem - for anything loaded into Kontakt.
Not much help for anything else...  
 
I like Keith's idea for "Key Maps"... where Sonar looks back for the last note.