I don't particularly think VSL instruments are any more cumbersome then others, in fact quite the opposite, they are quite flexible.  There is nothing stopping you, for example, from putting all of your articulations in Synchron Player under one super tall column (dimension), and only need a single keyswitch for each articulation.  You can reassign keyswitches and CC's to various aspects of sample playback better then just about any other sample player I can think of.  

Yes, the factory defaults happen to be setup in a way with 4-5 dimensions, which means you need to send perhaps 4-5 keyswitches using those arrangements, but you can rearrange your own presets however you want and can avoid multiple keyswitches..  ViPro also you can arrange presets using only a single row of X-based keyswitches if you want.

Yes, I would also prefer to not have to recreate entirely new dimension trees, in Synchron player, I'd rather be able to use the existing factory presets as is.

But the bigger problem has to do with DAW's themselves.  Many DAW's have nothing at all provided to facilitate articulation switching on the fly.  Lots of sample libraries handle things slightly differently, so any kind of articulation management system needs to be flexible.  Only 3 DAW's really provide any kind of solution, none perfect.  LogicPro has Articulation Sets, cubase has expression maps, and StudioOne5 now has a very rudimentary keyswitch lane which can send only a single keyswitch at a time.

There is also a third party extension for Reaper which can add some capability.

In the case of LogicPro and Cubase, they are still deficient, I have listed above in my earlier post some of the specific things that they did not address and still cause composers to jump through way too many hoops and challenges, usually kind of complicated also.  On top of that many are trying to incorporate Lemur and other touch pad interfaces into their workflow, which further complicates the matter of how to choose articulations on the fly as they are playing in parts, etc.

I personally see a huge opportunity here for VSL to provide a generic solution that will expand the articulation management of ANY daw when used in conjunction with VePro.  Presently, VePro usually adds an additional level of complexity that usually makes articulation management even MORE difficult then without it.

@Dewdman42 said:

I don't particularly think VSL instruments are any more cumbersome then others, in fact quite the opposite, they are quite flexible.  There is nothing stopping you, for example, from putting all of your articulations in Synchron Player under one super tall column (dimension), and only need a single keyswitch for each articulation.  You can reassign keyswitches and CC's to various aspects of sample playback better then just about any other sample player I can think of.  

Yes, the factory defaults happen to be setup in a way with 4-5 dimensions, which means you need to send perhaps 4-5 keyswitches using those arrangements, but you can rearrange your own presets however you want and can avoid multiple keyswitches..  ViPro also you can arrange presets using only a single row of X-based keyswitches if you want.

You are making a theoretical argument but have you actually tried these things? Synchron player does not offer scrollbars on dimensions and shrinks everything down to an unreadable and unusable size as a single dimension grows.

And VI Pro only offers 12 slots per X/Y dimension, even if the controller is a CC. Sure you could make dozens of single-cell matrices and drive VI Pro via program change but that is clearly antithetical to the design. VSL's intended design takes more control messages than any other. A single-dimensional control method can be offered orthogonally - e.g. Spitfire's UACC system (although the universality of that was an overreach). XSamples libs have a 2-D keyswitch system but also offer access to all 88 patches via a single CC, right out of the box. Don't get me wrong, I appreciate VSL's flexibility otherwise and I think a lot of the challenges come from their increased depth of sampling, which I also value.

As far as the initial ask (MIDI scripting in VEP). Sure, we can talk about the shortcomings of DAWs etc and make arguments for this (we agree) but there is already an example of this feature on the market and it is available with the vast majority of VSL's competitors - the Kontakt ecosystem.

Kontakt player, like VEP, can host multiple VI instances, albeit only Kontakt ones. And right at the top of every multi there are slots for KSP scripts. People value this capability and it gets used. If you have a lib that only uses keyswitches and you want to use CCs, you can fix it. If you want to route across multiple instances you can do it, channelize, conditionally filter etc. Thus every Kontakt instrument supports MIDI input scripting but no VSL instrument does and no VSL product can add it.

So I'll change the argument - Kontakt multis offer both MIDI script slots and a built-in scripting language for them, why doesn't VEP?

This not working is a big frustration for me. I’ve tried, over and over, as new versions have been released, to use Blue Cat PatchWork and PlugNScript inside VE Pro without success. Crashes and restarts...

The integration with Studio One’s Sound Variations seems great, but I’m on Pro Tools, and I don’t want to juggle two DAWs just to be able to use articulation switches.

As mentioned before in this thread, a simple thing like being able to map a single Program Change message into multiple keyswitches would be so awesome!

The main problem is Patchworks.  PlugNScript should work.  I would recommend you get the cheap or free Kushview Element...which absolutely DOES work inside VePro..then you can host PNS inside that along with your instruments.

Kushview Element and Unify are the only two plugin sub-hosters I have been able to get to work reliably inside VePro.  They are based on JUCE, for whatever the reason, that seems ok inside Vero.  

All the other well known sub hosters like Patchworks, DDMF, PlogueBidule...  have problems...don't know why.

Thank you, Dewdman42!

I do not think Element is particularly hard on the CPU.  I have never compared it to Patchworks, but it would be interesting to see the actual results in comparison.

Did you buy Element or build it yourself?  If you built it yourself, are you sure you aren't using the debug version?

I can't think of anything about your configuration that would potentially use less CPU, but if you're getting some unusual CPU activity it might be worth posting a ticket on Kushview's GitHub tracker to see what would come out of that.

[quote=Håkan Glänte;307198]

My initial thought was to use a separate Element session per instrument, as in the attached pic, but maybe I could put multiple chains/instruments inside a single Element session?

[/quote]

yes you could potentially put multiple instruments inside one Element session, though I don't think that is particularly a good idea, because then you wouldn't be mixing the instruments in VePro's excellent mixer.  That certainly would not work for me since I use MirPro.

@Dewdman42 said:

I do not think Element is particularly hard on the CPU.  I have never compared it to Patchworks, but it would be interesting to see the actual results in comparison.

Did you buy Element or build it yourself?  If you built it yourself, are you sure you aren't using the debug version?

According to the CPU meter it taxes the CPU more. Haven’t tried a real-world scenario with full blown arrangement.

I bought it, don’t know how to build it myself. But maybe that could be a way to create a lighter version?

@Dewdman42 said:

yes you could potentially put multiple instruments inside one Element session, though I don't think that is particularly a good idea, because then you wouldn't be mixing the instruments in VePro's excellent mixer.  That certainly would not work for me since I use MirPro.

I tested multiple instruments inside one Element session using buses to route the separate outputs back to the VE Pro mixer, so it’s doable and let’s you use the mixer/MIR Pro. I don’t know if it saves some processing power, though.