What's new

FlexRouter: Flexible keyswitch router for Kontakt 5 - version 2.2.3 released

tack

Damned Dirty Ape
Version 2.2.3 is released on March 8, 2019. See this post.

Hi gang,

I've been hacking on Yet Another Keyswitch Router multiscript. It's become featureful enough that I thought it might be useful to others as I think it has some unique features. It does require Kontakt 5.

Quick links:
Some features include:
  • support for note, program change, or CC-based keyswitches
  • arbitrary translation between notes, CCs, and program changes
  • can route events to instruments on ports A-D (64 separate channels)
  • multiple note-based keyswitches can be activated simultaneously (useful for e.g. layering articulations)
  • one keyswitch note/CC/PC can trigger routing to multiple target channels
  • one instance of FlexRouter supports 16 rules
  • each rule supports up to 128 independently configured keyswitches
  • Optional anti-hanging for notes and sustain pedal when jumping between keyswitches
  • Optional CC chasing per rule
  • probably a few bugs :)
Oblig screenshot:

flexrouter-2.2.0.png

Get a flavor of FlexRouter with this What's New video for version 2.1 (older version):



Original Tutorial / Walkthrough video (showing version 1):

 
Last edited:
Sure but will the bugs eventually be fixed or this a Cubase Logic release..?

Just messing with you.
I'd definitely like to check it out.
I'm prepping for a heavily automated gig next year and already I see a need for multiple triggerings
from single controllers, etc.

Thanks
 
Cool! Could be close to what I was trying to script myself! Some questions:
The input CC changes the channel the midi data gets sent to? Or is it just translating a CC to note values (key switches)?
If it is routing to channels, have you figured out how to prevent hanging notes? When there is a played note still held and change the program, the held note doesn't receive a note off once letting the key go. This must be fixed script wise. I was kind of successful with that, but there were some problems! Don't remember exactly what, as it is some time ago.
Is it possible to have multiple input channels, that all can keys witch to all 64 Kontakt slots?
If you want to check out my take on it, here I posted it in Bob's thread:
https://vi-control.net/community/threads/velocity-keyswitch-multiscript.46466/
 
Thanks guys for your interest. I just wanted to make sure any additional effort wouldn't be for naught. I'll clean it up and toss it on GitHub once I decide on a license. It'll be open source and your merge requests will be welcome.


The input CC changes the channel the midi data gets sent to? Or is it just translating a CC to note values (key switches)?

Both. Keyswitches (whether notes or CC events -- so I'm somewhat overloading the word "key" here) received on the keyswitch channel for a given rule will cause all events thereafter received on the source channel for the triggered keyswitch (which can be different than the keyswitch channel) to be routed to the target channel for that keyswitch.

Apart from affecting the active routing, keyswitches themselves can either be blocked (patches never see them), passed through (patches on the target channel see the keyswitch as-is), or redirected to either a specific note (with configurable velocity) or a CC event.

If it is routing to channels, have you figured out how to prevent hanging notes? When there is a played note still held and change the program, the held note doesn't receive a note off once letting the key go. This must be fixed script wise.
Yep, no problem with hanging notes. Note-off events are sent to the channel(s) that received the note-on event, not the channel(s) that are currently active based on current keyswitches.

Is it possible to have multiple input channels, that all can keys witch to all 64 Kontakt slots?If you want to check out my take on it, here I posted it in Bob's thread: https://vi-control.net/community/threads/velocity-keyswitch-multiscript.46466/
Right now any keyswitch can already route to any of the 64 channels inside Kontakt, but it sounds like you're wanting to include program changes in the list of supported keyswitch events (currently notes or CC events)? So instead of e.g. note D-2 or CC32/2 triggering a keyswitch, you'd also like to be able to do that by say PC 2? If I understood this correctly it should be possible without changing too much of the MIDI event handling code.

Cheers!
 
Sounds great! Program changes would be the logical choice IMO, since this midi data is meaningless in the world of sample libraries, so why waste any CC number. Doesn't really matter, actually, as there are enough unused CCs available! ;)
What troubles me, is that it isn't possible to assign CC or program change to the Cubase expression maps! This would make so much sense! But i cannot be solved with a Kontakt script. Steinberg hast to get to that.
I am looking forwards to see your script!
 
I think i qualify as a hardcore beta tester since i am already key/CC-switching&stacking articulations in my template. :) CCswitching is made inside the kontakt instrument though so it would be very nice to use the MS!

I might have a couple of suggestions too so i really cant wait to try it!

Thanks a bunch
 
I might have a couple of suggestions too so i really cant wait to try it!
I've done most of the code cleanup I was hoping to do. The GUI code looks terrible, but what can you do -- with KSP I'm finding the bar is set very low in terms of code elegance. :)

So with any luck, I'll have something up tonight. I want to do a quick tutorial video to walk through some use-cases. Hopefully I'll get a chance to put that together tonight.
 
Thanks everyone for your interest and encouragement. I've finally scrounged some time to publish the code and put together a walkthrough video. See the top post of this thread for the links.

Cheers!
 
Last edited:
Thank you for all the time and effort you've put into this freely shared project. It is for Kontakt 5 only (as I have just discovered when trying to apply the script inside K4!). Looking forward to trying it out.
 
It is for Kontakt 5 only (as I have just discovered when trying to apply the script inside K4!).
Ah, I did completely fail to mention that anywhere. Thanks for pointing it out. I updated a few places and hopefully it's clearer it does require Kontakt 5.
 
Wow fantastic work, tack! I too think this has some unique and cool features ;)

The touch osc template + chromatic keyswitching looks really neat. I think i am going to upgrade to spitfire soon enoguh so i´d definitely have a look into this if i go this way.

As for my current setup, i dont think i am going to use it as much as i initially thought. In my case the main problem relies on the fact that, from what i have understood in the video -dont have time to test it now-, you cant stack or route midi simultaneously to different channels/ports with just a single keyswithc input, but you have to press 2 keyswitches simultaneously.

I think a goog source of inspiration and feaures if you want this script to excel at layering it would be the MS from OT released on the first Berlin WWs: Articulations manager. In this script you have 2 different articulations to adress midi simultaneously by each keyswitch, and you can control how to stack them: velocity (with efective, adjustable range) or CC ( CC can act as a switch between the 2 articulations or like a crossfade).

Thanks again, keep on rocking!
 
In this script you have 2 different articulations to adress midi simultaneously by each keyswitch, and you can control how to stack them: velocity (with efective, adjustable range) or CC ( CC can act as a switch between the 2 articulations or like a crossfade).
I've been thinking a bit about how this might work in terms of UX, especially when layering more than 2 articulations (which is possible with FlexRouter).

The first thing is that it needs to be optional. Sometimes you actually want both articulations fully mixed. My first thought is that one could configure a separate keyswitch whose sole purpose is to activate crossfading and be mixed in with the articulation keyswitches. (Remember "keyswitch" is an overloaded term here, it means both a note or a CC event.) The configurable for the keyswitch would define which CC should be used to control the crossfading when activated. Since (AFAIK) a multiscript can't control the volume of individual patches, crossfading would need to be implemented by injecting CC7 events to the patches as they're being faded. When a new keyswitch is activated, the volumes of the patches would be restored to the levels they were originally at before any crossfading was done.

So suppose you have C0 triggering regular longs on channel 1, D0 triggering con sord longs on channel 2, and E0 is a "crossfade keyswitch" configured to use CC85. When you hit C0+D0, you get longs mixed with con sord at their regular volumes. When you combine those with E0, it would set the volume levels of channel 1 and channel 2 based on the last-observed level of CC85, and then as you change CC85 the mix adjusts proportionately, so that value 0 is fully channel 1, value 64 is both channels 1 and 2 at half volume, and value 127 is fully channel 2.

Layering more than 2 articulations is I suppose a dubious corner case, but I suppose the obvious behaviour is that the CC range is divided up into 2 parts, the first half 0-63 crossfades between the first two keyswitches, and the second half 64-127 crossfades between the last two keyswitches.

Thoughts?
 
Hi all,

I've released version 2 of FlexRouter which has a number of new features to make your keyswitching lives easier. (And mine. :))

Get it here. (Or see the project page on Github.)
https://urandom.ca/flexrouter/latest

flexrouter-2.0.0.png

Changes since version 1:
  • Keyswitch channels can now be omni (listen on all channels)
  • Target channels can be null. Triggering a keyswitch with a null target causes all subsequent events to route into a blackhole. (#5)
  • Added a rule-level default for source channels (which can be overridden per keyswitch).
  • Added optional anti-hanging for sustain pedal. (Notes already avoided hanging across keyswitches.) (#1)
  • Added optional CC chasing per rule. (#2)
  • Midi Program Change events can now be used for keyswitches and redirections
    • (I'm now using Program Changes in my DAW to trigger UACC events on all my Spitfire libraries as in the above screenshot.)
  • Keyswitch triggers can now be manually entered. (MIDI Learn is still possible but is no longer required.)
  • Rules can now have multiple instances of the same keyswitch. This allows a single note (or CC, or program change) to route to multiple patches.
  • Added a new button to clone a rule.

Unfortunately version 2 is not backward compatible with version 1. You will need to recreate your rules. Sorry. :(

Cheers!
 
Hi again!

On the heels of purchasing a couple libraries (Cinematic Studio Strings and Embertone Clarinet) which posed some new keyswitching challenges in my template, I added a few features to FlexRouter and have released FlexRouter 2.1

Get it here. (Or see the project page on Github.)

This time I decided to do a walkthrough video showcasing the new features:



Changes since version 2.0:
  • Keyswitches now support multiple redirections: one keyswitch event can trigger multiple outgoing events.
  • Added a per-keyswitch feature to keep redirected notes pressed until the next keyswitch is triggered. Useful for patches that modify behaviour only as long as a note is held.
  • Added velocity range support to note-based keyswitches. Now the same note-based keyswitch can route to different patches based on velocity.
  • Added help info to all UI controls.
I'd like to give a tip of the hat to @FrozenPlain for his excellent enhancements and continued development of SublimeKSP!

Cheers!
 
Last edited:
Oh, one thing I forgot to mention: version 2.1 is backward compatible with 2.0, so to upgrade, just paste the new script into your existing instance. All your existing configuration will be preserved.
 
Great script. Seems to me a problem with compiled version, still shows as 2.0.0. I wish someone would make this as a Logic Midi FX script!
 
Seems to me a problem with compiled version, still shows as 2.0.0.
Weird. When you visit the link to the script, what do you see as the set_script_title() argument a few lines down? Does it say 2.1 or 2.0?

I wonder if your browser is showing you an old cached version. Try ctrl-shift-R?

If it looks good there, are you clicking Apply after you replace the contents of the Edit field?
 
Top Bottom