Strange Split behavior

The Desired End Goal is to split the keyboard between two different VSTs in the same rack, each to its own note range.

I’m trying to split my keyboard into two different VSTs that are in the same rack. Currently running 4150, but I saw the same behavior under the last 3.x release.

I tried both VSTs outside of Cantabile and they work as I expect.

I’m splitting my keyboard input at E2> and <D#2. ABOVE the split things work as I expect.

But BELOW the split the VST continues to make sound, but transposed UP two octaves, even though the notes are supposed to be filtered.

I’ve tried this with several different VSTs and I see identical behavior.

I get the same result whether I’m filtering the routes within the rack, or if I add an extra input and filter Outside the rack.

What switch am I missing?

Hi Charles,

Can you post your song and rack you are using for this? It may help us figure out what’s up.

Thanks, :slight_smile:

Dave

Naturally I’m swamped and won’t get to this until Sunday or Monday.
:roll_eyes:

1 Like

No problem, it will get done … :wink:

The song

Working for the Weekend.cantabileSong (23.4 KB)

The offending rack:

Hi Charles,

I took a look and I think the problem is that your splits are fine in the song level filters but the transpose down one octave on the upper split is overlapping back into the lower zone you set up because the rack is the same destination for both routes.

Here is what I mean. You set the lower zone to top out at note number 51 and then transposed up one octave so the rack MIDI input sees a MIDI note of 63 as a midi input. Then you set up the upper zone route from note 52 and up and transposed it down one octave. This means the lowest note of 52 actually sends MIDI note 40 and triggers the instrument in the lower zone because it thinks those are its notes and in its zone. Then you set up another split in the routes in the rack.

The transposes and the 2 splits caused overlaps in other words. I think to fix it you could remove the filters at song level and create the splits and transpositions only once inside the rack using the 2 routes to the plugins as shown here. If you needed to further transpose at this point you could because you removed the conflicting split points on the song and rack levels.

I hope this helps.:slight_smile:

Dave

I’d actually suggest the opposite: do all the splitting at song level and not have any zone splitting going on inside racks. Instead, when having different parallel sounds within one rack, differentiate by MIDI channel - instrument 1 on channel 1, instrument 2 on channel 2. Use MIDI channel filters on the routes to the instruments within the rack to achieve this. Then, at song level, do a hard channel mapping in the routes to the rack to easily know which instrument you’re addressing. Once you’re correctly sending notes to the individual instruments, add range filters and transpose to taste, and you’re done!

My reasoning for this: split and layer ranges will frequently change between songs, so keeping this aspect outside the racks will make the racks more universally usable without having to create multiple split variants within the rack.

The only exception to this would be an integrated split or layer sound within the rack that always stays that way for sound design reasons - where it doesn’t make sense to split otherwise (e.g. a blend of two sounds). But from the description of the original post, this is about two independent sounds, transposed independently, so I’d go with keeping all zoning and transposing at song level.

But as always, there’s multiple ways to get things done in Cantabile :wink:

Cheers,

Torsten

Yeah, Torsten, your model of what I’m doing is more accurate.

MOST of the time for my nontrivial songs I’ll setup 2 or 3 zones and assign each one sound. This one case it’s a bit weird, obviously.

I’m stil not sure why the Poly 6 is responding the way it is, but I can poke around with it in the next couple of days and see if your way works better.

Okay I was able to fix this by deleting the song and rebuilding it per Torsten’s suggestion.

I’ve also tried to replicate the fault with the poly6 in a fresh rack but wasn’t able to replicate without the royal mess I’m using live :grinning: