Alright my conclusion for feedback to Apple is:
- I think LPX should provide a way to play in parts without forcing artid assignments (while an articulation set is active), allow "-" events in. Right now it forces unswitched input events to be assigned to the first articulation in the list, regardless of what the actual id# is.
- Notes and events in the piano roll with undefined articulation id “-“ are having the keyswitch for the first articulation in the list sent out. Events without articulation assignment should not be sending out keyswitches, that is the OP’s main problem.
- I think LPX also needs to chase CC's, PB, aftertouch, when channelizing events via the articulation set.
- I think LPX needs to support sending multiple keyswitches per articulation.
And actually the more I think about it, if a user has played in a keyswitch ahead of some CC events, and if there are keyswitches associated with that articulation, then you absolutely
DO want the keyswitches to happen for non-note events, because the CC's might be relevant.
Now back to the original question, upon reading it a little closer, it might be different entirely then the direction we have been going with this. I think the real problem the OP is having is related to a conflict over CC1:
Now I can see in The Event List, that the CC1 also have an Articulation ID's attached to it, meaning that the Preset will switch back to Articulation 1, the moment there is CC1 in the part.
I need to see the articulation set he is trying to use and understand better the way he has his channel setup, it doesn't entirely make sense what he's saying.
So basically the way LPX works, while recording in a part, or playing from a keyboard...incoming keyswitches will change what the "current" articulation id is. Any notes or events happening after that keyswitch will get tagged with that id. At the same time this is happening, or during playback of a region, then articulation id is read from every event. Every time the "current" articulation id changes from that, then a keyswitch will be sent to the instrument. If its the same id being repeated, then no keyswitches are sent to the instrument. Only when the next event has a different articulation id then the previous, then the "current" articulation id is changed to that one and the keyswitch is sent...regardless of the event type.
I don't see any reason why this should cause VSL to change patches other then there is some kind of conflict with the way CC1 is being used in both VSL and the articulation set, or something like that.