Hi,

We evaluate each request internally and put them on our wish-list.
This list is quite long with many interesting suggestions, submitted by our team and/or by our community.
So we have to prioritize on which feature we can work next.

Thanks for your patience.

Best, Ben

If we can be philosophical and hypothetical for a moment about what would make a nice addition in this particular area....  i also wish we had this capability, but mainly its only due to articulation management challenges while working with different sample libraries, including VSL, together with DAW's that simply have not enough articulation management features built in, or in some cases none.

Another route VSL could go would be to identify the specific reasons people are asking for a midi plugin slot and instead just build that functionality into VePro somehow, especially as pertains to articulation management. 

Some DAW's barely provide enough capability and even Cubase and LogicPro are deficient in this way.  Maybe VePro could just close the gap on articulation management itself, without introducing an open ended midi plugin slot?  So what are the issues?

1. Being able to map a single keyswitch of any type(CC, Note, etc)  into multiple keyswitches of different types.
   
   
2. Channelize notes based on an incoming keyswitch.  While channelizing notes, make sure to channelize all automation along with it.  In VePro this might mean directing channelized events to a different instrument channel also.
   
   
3. Latency correction, some instruments have different amounts of sample attack latency per-articulation, which makes it challenging to quantize performances on the grid.  Need a way to specify on a per-articulation basis how much negative track delay to use.  This can be accomplished by using a CC value to specify which articulation is active and then applying a certain amount of negative track delay.  You have to add more latency in order to have lookahead and be able to add negative track delay, but it's possible.
   
   
4. Using named automation to drive which keyswitches should be applied, and/or channelizing the note events based on the current "articulation" as specified by automation.
   
   
5. Able to listen to a separate midi channel for the articulation definitions to come, compared to the channel with the notes, so that in some cases, DAW's without any articulation management can use a separate track to hold articulation-definition events such as keyswitches that they want to keep out of the score and pianoroll of the source trac.
   
   
6. etc.  

Really, there are half a dozen or so key issues that many people are facing and really VSL could create an extremely large and effective reason/justification for using VePro at all if they filled in the cracks of articulation management and did so in a way that even DAW's without any articulation management capabilities whatsoever would be greatly enhanced in this area by using VePro.

I do think adding a midi plugin slot would be at least a hundred times easier then everything I mentioned above, then just let someone else develop a midi plugin to do everything I mentioned above.  Or users can use script plugins, etc...and get it done.  But really, this is an area where VSL has an opportunity to deliver a solution for a problem that nobody has really addressed adequately in my view:  articulation management.

Just my two cents...

@Dewdman42 said:

Another route VSL could go would be to identify the specific reasons people are asking for a midi plugin slot and instead just build that functionality into VePro somehow, especially as pertains to articulation management.

That's a fine idea. We don't need our answer, we need the problem solved.

Here's the problem - and I'm limiting it to just being a consumer of ($14,000+ worth of) VSL sample library products:

Whether it's VI Pro or Synchron player, VSL requires more keyswitches/commands to be sent per articulation/patch change than any other product. In VI Pro it was matrix/X/Y, and sometimes A/B switch (4). With Synchron player, the sky's the limit.

VSL has a reputation for being hard to use and this is exactly why. Solving this problem in a DAW or notation program is a lot of work, and every articulation system is different. So not many people do it, and not nearly as many people use VSL as could.

What do I want instead of 4-6 commands per articulation? I want to send a single PC/CC. There are rarely more than 128 patches in an instance, and I'd be happy to live with that limit. Within the instance I want to be able to say PC/CC 42 = this patch, PC/CC 27 = that patch. That's it. I'm not playing this live, I don't want my hands on 5 controllers, I don't want extra keyswitch notes on my tracks, I don't want to have to record keyswitch/CC dumps or anything else. Nothing about solving this need get in the way of also supporting multidimensional live control.

This is what I use MIDI scripting for - turning a single PC/CC into the pile of commands that VSL requires. Obviously this could be solved in the VI/Synchron players, or VEP.

The other thing I always use MIDI scripting for with VSL is making it so CC2 can be interpreted as velocity when VelXF is OFF. That is, I want to use the CC2 value for the dynamic without the crossfading. This also could be supported as a mode right in the players.

In any case, the biggest point is that this desire/need is driven by VSL's sample products themselves. It's not an abstract "wouldn't it be cool" thing. I really don't want to have to use BlueCat Plug'nScript or Logic's Scripter etc. But VSL sampling products are just too cumbersome to use without, IMO.

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.