Articulation keyswitch not recognized when starting play in middle of note. Solved.

[Steve Harder]

I had a problem in VSL Synchron player BBO libraries.  Starting playback in the middle of a note does not cause the keyswitch to be recognized by Synchron player.

I set up a simple test track where 3 consecutive notes each had an easy to identify articulation set.  Play thru all 3 and all is well.  Play thru 1, stop, set cursor at middle of 3 and play, and you would hear the note 1 articulation on note 3.

I tried every iteration of "play at" and "chase mode".  I checked Preferences | Project | MIDI, and made sure both "MIDI Event Chase on Play" and "Include Note Events." are selected.

Then I noticed "velocity" was 0, I tried changing it to 100, and problem was solved!  

Further testing showed that VSL Synchron wasn't fussy about "play at" and "chase mode".  I left mine at the map editor default for new midi event of Duration and CC's.

The easy way to change the velocity globally in an articulation map is open the map in a text editor (map is an xml file).  Make a backup first.

Change every occurrence of ["b3":0,] to ["b3":100,].   The [ ] are my delimiters and should not be included in the find/replace text.

So keep velocity in mind if you are having issues with articulation keyswitches not chasing properly when starting play in middle of notes.  FWIW.
 

[bitflipper]

I just tested this with Kontakt, and it didn't care if the keyswitch's velocity was 0 or not. I'm guessing the issue is specific to VSL and possibly some other synths as well. I recall that with some older hardware synths, a velocity of zero was interpreted as a muted note or a note-off message.

Maybe this should be reported to VSL as a possible bug, or maybe it's intentional to give you a way to non-destructively bypass keyswitches.

[Steve Harder]

9 minutes ago, bitflipper said:

I just tested this with Kontakt, and it didn't care if the keyswitch's velocity was 0 or not

VSL's quality control is pretty good, so I'm going to say this is a feature not a bug.  The workaround is certainly easy.  I'm sure we will continue to collect "folklore" about the idiosyncrasies of various sample libraries and how they handle keyswitching.

[bitflipper]

This is why I advocate for deeply learning whatever tools you have rather than jumping on every shiny new product that comes along. That goes for the most mundane effects as well as complex synths and sample libraries, not just to uncover their quirks but also for the joy of discovering capabilities you didn't know were in there. 

This has made me wonder why no developer has ever utilized keyswitch velocity to bundle in additional information. For example, a keyswitch that triggers a note bend articulation could use its velocity to indicate the bend depth or rate. AFAIK, nobody has ever done that. 

[msmcleod]

FWIW... The MIDI standard specifies that any Note On message with a velocity of 0 should be treated as a Note Off.

The main reason for this is a thing called "running status".  

Normally, a note MIDI message consists of three bytes:

• Byte 1: Note On Command/MIDI Channel
• Byte 2: Key number
• Byte 3: Velocity

All command messages have a value > 127, so any receiving equipment can tell the difference between a command and a parameter ( because parameter values are always less than 128 ).

Once you've sent the first note on message, as long as all subsequent notes are on the same channel you can skip sending the command and just send the key & velocity.  Having velocity 0 being the same as Note Off means you can effectively send both Note On and Note Off messages in this way.

So if you're just playing notes on the same channel, this reduces the data being sent by 1/3rd.  This is particularly useful for controller keyboards sending notes out on a single channel over a standard MIDI cable at 31.25Kbits, or older equipment with small buffers receiving the data.