search

jtackaberry / flexrouter

Flexible keyswitch router for Kontakt (multiscript)
MIT License
25 stars 2 forks source link

No CC chase across keyswitches #2

Closed stevefal closed 8 years ago

stevefal commented 8 years ago

Ideally, the last value of CC's changed within one keyswitch are repeated when switching to the next. This provides continuity of control between articulations. Not providing this requires the player to manually "bump" the CC controller at hand in order to generate a (nearly) matching value for the next keyswitch in order to provide a more fluid transition.

I'm not sure what an optimal algorithm for this would look like. For example, across how many keyswtiches, and for how many CC's would the chase values be synchronized? This may be obvious but I haven't thought it through enough to know what gotchas may exist.

jtackaberry commented 8 years ago

Yes, this could be tricky. I'm not sure I want to get into the business of providing a UI to define exactly which CCs should be chased. I wonder if it would be insane to chase all observed CCs since the previous keyswitch(es) was activated, and then make it a per-keyswitch configurable as to whether or not the target channel for the newly triggered keyswitch(es) should receive chased CC events?

stevefal commented 8 years ago

I'm not sure it's insane to chase all observed CCs by default. But a "ignore all CCs from previous keyswitch" would not be useful to me because I would always want all keyswitches to honor CC64 and CC1, at least. I can't really think of any keyswitches I would not want chased, or at least that I couldn't live with being chased. Maybe each keyswitch could have a handful of value edit controls for chased keyswitches to ignore. On the other hand, maybe that's unnecessary complexity. Try initially without?

jtackaberry commented 8 years ago

My thinking in making it optional per keyswitch was for the cases where you mix libraries between keyswitches and those libraries interpret CCs differently. But maybe I can satisfy 90% of the use-cases simply by making CC chasing optional at the rule level.

Implementation will be a bit tricky due to the fact that CC states needs to be tracked per rule. Definitely not as clear as the sustain pedal up issue.

jtackaberry commented 8 years ago

This turned out to be even trickier than I thought, because of the separation of keyswitch channel and source channel (for all other events).

Without going into the details, I think I've got something workable. The configuration for CC chasing is defined at the rule level, and so it applies when a keyswitch is triggered for that rule.

flexrouter20

You can try a preview if you'd like: https://urandom.ca/flexrouter/beta . A bit more polish needed but that will be the gist of the next release.

I've decided to call this 2.0 because unfortunately it's not backward compatible with 1.0. You'll need to recreate your rules. I usually take backward compatibility seriously but it was probably the difference between doing this work and not doing it, so I figured a backward incompatible release was better than no release at all. :)

This also fixes the hanging sustain problem from #1 by providing a global config item. (I thought of at least one use-case where that behaviour would be undesirable so I decided to make it configurable.)

jtackaberry commented 8 years ago

Fixed in 2.0.0.