Vienna Symphonic Library Forum
Forum Statistics

194,412 users have contributed to 42,920 threads and 257,965 posts.

In the past 24 hours, we have 4 new thread(s), 10 new post(s) and 81 new user(s).

  • last edited
    last edited

    @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.


  • last edited
    last edited

    @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?


  • Kontakt is fundamentally a different product because it is by design a platform for third party developers to develop content. Vsl has never pursued that kind of approach and likely never will. They develop their own content on their own sample players. Scripting in general would be cool though! I hear you about the single dimension, and no I never tried it. Hope you can find the solutions you are looking for.

  • I have great interest in improved MIIDI capabilities for VST and AU preset automation and learning ability within VEPro!

  • 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’m new to this concept, but I just installed Element and tried it inside VE Pro (Windows). It seems to work, but it hits the CPU harder than PatchWork and takes longer to open.

    A bit overkill maybe (a full-fledged plugin host inside a plugin host) - I just want to be able to put a script before my VI.

    Is there some way to tweak and reduce the size and complexity of an Element session to reduce the CPU hit?

    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?

    Image


  • 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.


  • last edited
    last edited

    @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?


  • last edited
    last edited

    @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.


  • Yea that is true you could do that but really element should be taking very little cpu. If you can identify for sure that it is taking a hit on the cpu and you can for sure blame it on element then definitely post a comment on the kushview GitHub issue tracker. It should not be. I don’t think building it yourself will make it any faster.