As a matter of fact, the programmed trills on the VIP sequencer, to me, are one of the highlights of the library. I personally prefer the approach to prerecorded trills. Just check the default matrixes provided by VSL and you can copy and paste them to your various individual instruments for consistency.

 Thanks much for the very prompt addressing of the issue Martin and Paul!

Tried it yesterday and it seems to be working fine. Thanks again.

Just updated VEP to today's release, am I the only one seeing a very high CPU load? I was finishing my DS Viola templates yesterday, and 12844 was working great.

 I think you're still not clear on how to set up a standard template. Some people, myself included, would use VEP5 to do that since it helps manage various things and also plug MIR into the end result, so let me speak in those terms (sorry if this adds another bit for you to consider, that is VEP).

On one single instance of VEP as your host, add 8 VIP instances, and add each one of the individual DS violins to each VIP. So VIP1 will play DS Vl1, VIP2 will play DS Vl2, etc. So you have 8 individual players for you to write for as you wish, each routed to a separate MIDI channel. Now, on your DAW or notation software you replicate the setup, and have 8 separate staff parts. Unison play? You write once and copy+paste to all parts. You want Div2, write the two different lines on Vl 1 and 5, copy/paste 1 to 2,3,4 and 2 to 6,7,8. And so forth if you wanted other divisi configurations. So that takes care of your first 8 violins. Hope that's clear.

This is not extremely CPU or disk intensive, but it does take much more computer power than most other libraries, as in the end, DS is comprised of a set of individual instruments, just as if you had 8 instances of the Solo Violin playing simultaneously. But I don't want to digress much.

Now for your second group of 8 violins, you have a few options. First, what has been mentioned about detuning and transposing another group of individual violins just as above. Second, could be for you to utilize the desks or 4-player presets included in DS by VSL. You could set up the 4 desks and the 2 4-player groups and use different humanization parameters, and use different EQ settings, to make them sound slightly different to the individual violins above. Then on your DAW, you'll include separate staff lines for each desk/choir, separate MIDI channels, and write there whenever you need to.

In the end, the most you'll have is one VEP port, with 16 MIDI channels / 16 VIP instances (or less if you use the pre-mixed desks), for all your complete 16-players violin section. Then do the same for the Cellos, etc.

This is what I do, and I didn't win the lottery... yet.

Hope this helps.

 The problem is that you're opening the VST2 instance of VEPx64. Try the one marked "///" on the Cubase plugin list. You will know when you've opened the right one the moment you see as many MIDI ports available in Cubase as you have set-up on the VEP preferences.

 Glad you figured it out!

The alternative then would be using Vel-XFading (or expression). I think a good deal of people use it as their preferred way to shape dynamic lines. Beat Kaufman has a very informative article on how Vel-Xfade 'works' in VSL's implementation- in a nutshell, seems to be a combination of dynamic layer xfading and volume increase (or decrease). The recorded layer xfading doesn't typically give you a natural transition in solo instruments, so what I've adopted to do as a practice in most situations is simply use expression for dynamics, unless it is for a very broad dynamic change and a non-solo library (with multiple instruments, the transition effect gets more subtly blended in).

Several ways to do this:

- on your DAW, create a controller lane assigned to Vel-XFade (by default CC2 on VIP, or expression CC11) and draw in the Vel-XFade curve by hand (what I do 97% of the time).

- sometimes you can reassign CC on your MIDI controller, so maybe you can reassign the modwheel to CC2, or alternatively reassign CC1 to Vel-XFade on VIP.

- (sorry this is specific to Cubase) program a MIDI transformer to receive CC1 from your controller and send it as CC2 to VIP.

- use another external controller to manipulate these CC's (in my case, 3% of the time). E.g. Novation ZERO SL mkII, Korg Nano's, Steinberger's CMC's, some keyboards with controller faders, JazzMutant Lemur's, etc....

You've got to try and see how Vel-XFading (or expression) fairs soundwise vs. the use of a dynamic articulation. I prefer the flexibility of the former.

 Mike,

Not sure you can do this the way you're envisioning. This is a very particular instance where both patches have A/B articulations 'built-in' and you need to play the opposite on each slot.

I take you'd like the crescendos specifically to occur at the end of a legato phrase. I'd typically not use a dynamic patch for that, but use expression (or Vel XFade). But if that is what you'd like, have you considered switching from your plain legato patch to a perf_rep+dynamic "patch" for that last note? Just as if you were triggering the A/B with a keyswitch, you'd switch to this decrescendo matrix cell for the last note. You'd still have the legato feeling provided by the perf_rep articulation, automatically ending in the decrescendo articulation.

Hope you grasp the core of what I'm suggesting, but let me know if this is unclear.

 I actually feel the approach to use the SEQ to imitate Trills is so much more flexible and useful than static prerecorded trills. My suggestion is to spend a bit of time looking into one of the DS trill matrixes and try to understand how it was made as a combination of a rep-interval and the SEQ. Key is to understand how the SEQ works, even at a high level. Their flexibility (tempo-synch'ed, customizable variations, interval independency) is way superior to any static performance. Kudos to VSL for this.

 Yeah, well, that is not a serious excuse, or is it? I totally agree with William. I raised that point back in Guy's thread, that people come, say "I don't like it, it is a no go for me", and go. It's funny they spend time to come and post their 'negative' impression, but would not take the opportunity to allow for a more constructive conversation that would leave us all with the valuable opportunity to understand the why's and possibly improve upon. A real shame.

 Yes, you have complete set of individual chairs (6 cellos, 8 violins), 6 solo instruments. You get as well some predefined combinations in sets of desks, which are pre-mixed groups of the individual chairs, for convenience.

How do they compare to the Solo Strings? Some observations: First and foremost, they, DS, don't have quite the long assortment of articulations the Solo libraries have. Second, the tone of the instruments is also noticeably different, and it varies also noticeably (in most cases) from one player to the other. Third, VSL has been very careful to be 100% consistent in the available articulations thus far, same for violins as for cellos, and I presume that will be the case for the violas at least, and don't see why not for the basses. Why is this important? Big time saver for those who fully customize our matrixes.

And to this last point, I personally view this as the real major differentiator between DS and any other library out there to-this-date. The real beauty of DS is in digging into "playing" each and every chair independently. Herb said it in his comments about DS when it was being launched. You can finally get, courtesy of VIP's humanization capabilities, a different execution every time you play (as you would in a real performance). And get a more 'humanized' performance that otherwise you cannot achieve with any other ensemble patch library out there. I think many people praised last year the sound of CS2 for that matter; I found the performance in the samples fairly imperfect, which is part of the magic, but sometimes on the brink of unacceptable due to imperfect tunning and there being nothing you can do to tame it. Well, DS now allows for such variations and variable degree of imperfection, just as in a real performance, but you have 100% of control, so to speak. And this is not only tuning, but also timing, as William pointed out. A real game changer, IMO.

Muziksculp provided some of his qualitative description of what he dislikes about the sound which somehow I guess tries to describe his perception. I think it'd be useful to ask the last two posters for what aspects of the sound they find "sounding bad". In all fairness and with all due respect, you'd be better off elevating the conversational level around such comment as otherwise some people, yours truly included, would tend to dismiss your comments rather easily for finding them trivially unfounded.

My impression is that your issue is related to not using the VST3 version of VEP.

So the 16 MIDI channels (per 'port') is a limitation of MIDI nobody can do anything about. But you can use multiple ports, and VEP is capable of handling (according to manual: 32 MIDI ports, on page 45 VSL, needs to be updated) 48 MIDI ports with 16 MIDI channels each, thus a 768 MIDI channels in total within a single VEP instance.

In Cubase, when you set-up you VST instrument, make sure you look for the VEP VST3 version in your 64-bit plugin folder. You should see two different VEP versions, one labeled "x64", which happens to be the VST2 version. Pick the other one (yes, counterintuitive, (http://community.vsl.co.at/forums/t/34658.aspx). Now you should be able to access up to the 48 ports x 16 MIDI ch each. Hope this helps.

I had actually mentioned all this in my very first post in this thread, which referenced to the very same process I'd just gone through...

http://community.vsl.co.at/forums/p/34384/217227.aspx#217227

I get the impression that is indeed a x64, just not clearly tagged. But as Daryl just mentioned, what really matters is that the VEP server you're using is the x64 version, and the VEP mframes hosted on it are x64. The plug-in on Cubase I view as more of a connector to pass MIDI and Audio data back and forth, probably not needing to handle any true 64bit operation. This all in rough terms. Hope it makes sense.

I'm double-guessing myself again. If it were VST3 it should have been marked up with the three slanted vertical lines, which that is not. It'd still try it to make sure though.

If you open the Steinberg tree on that VST Instrument window, do you see any instrument marked as VST3 (so with the " /// ")?

First: I stand corrected. My mistake. You're indeed pointing to a second VEP instance, not a second port.

Second: That second post is exactly what I was writing you about. You see that very first VEP on the list? It seems to be non-x64. Well, it most likely is. And the infamous VST3 version you need. Try it and let know.

Can we recap? At this point, what is your issue?

From that screeshot, the instrument you have selected on track 28 is routed to MIDI channel 10 on the second VEP port. That seems to be set-up correctly. You must be indeed using the VEP x64 VST3.

One of the best decisions you've probably made in your life. At least it's been one of mine.

Since we're at it...

1) Very first thing: Open the VE server. Add your viframe.

2) Open Cubase, load your project.

3) Open the VST Instruments window (option in one of the menus). Insert a VE plug-in instance. (if you have no idea what I'm talking about >>> Cubase manual). Close the VST Instrument window.

4) Track list, insert (create) a new MIDI track (or use the one Cubase probably asked you to create by default when you added VE).

5) On the Track Inspector, first section within the MIDI track contains all the basic set-up config. Assign the MIDI port there (just click around if you don't know how until you see the VE ports pop up), and MIDI channel. Voila.

 You are mixing different things. MIDI and Audio.

Your MIDI channels output can be routed to any bus or available audio output in your system.

MIDI ports have nothing to do with the NET1/NET2 etc. you're mentioning. Those are audio outputs.

Without meaning to sound rude: your best bet is to check the manual. Pg. 13.

 Pg. 13 reads:

"Each Vienna Ensemble instance offers up to 32 MIDI ports with 16 MIDI channels each (= 512 MIDI channels)".....

 Not sure. I use VEP. But I'm sure the product manual will clarify that.

 I just consolidated my template that way (sounds like a lending company commercial)... http://community.vsl.co.at/forums/p/34384/217227.aspx#217227

The VST3 version will allow you to define the number of MIDI ports you may need. Each port enabling you to access 16 MIDI channels. E.g. a setting of 8 MIDI ports will give you (8x16) 128 channels you can access in Cubase.

 After corresponding with VSL they confirmed the VEP plug-in listed as VST3 on Cubase is x64 although its name is not labeled as such. I've been consolidating several VEP instances under just one with multiple MIDI ports, and everything works great and flawlessly, without any extra/odd latency.

Daryl- well no special reason other than that being a method suggested in the manual to access addtl' ports. I'd use the VST3 version if I knew what the right VEP5 instance is. I dont see a x64 listed as VST3.

 I'm actually trying Event Input for the first time. Decided to try streamlining my main template, going from running several parallel VEP instances to two or maybe three at the most. I'm on Cubase 7.

Very first Event Input I create, and assign to a not too complex VEP instance running about 10 Kontakt libraries, and it drops/skips notes, some get stuck, etc. Everything worked perfectly as independent VEP instances running on the VEP x64 server and Cubase. I'm puzzled, and glad I found other people reporting the same, and not on Cubase. So must be something on the VEP side, no? For the record, I don't have any latency compensation enabled on Cubase.

 Martin,

Let's take your example of a prebuffer size of 2048. So what you're saying is that because the prebuffer per-sample allocation is 8KB (256 samples), the most important characteristic is random read speed. I'd like to understand the rationale behind that. Let's go step by step if you don't mind,

Could you clarify what 'typically' happens when I press three keys on the piano and trigger three 'voices' on a single instance of VIP. My impression is that VIP plays back the 3 x 8KB buffered sample starts while simultaneously proceeds to load and continue streaming the rest of these three samples from disk, is this correct? If it is, what would a typical note sample size be? Let's say a regular legato note?

No disrespect intended, but you've got to understand how a SSD drive writes and reads data to be able to argue this. Let me be very brief and simplistic, as this is getting way off topic.

SSD's should not be defragmented, there is no need to. On the contrary, the nature of the operation of a mechanical drive writes data in a fragmented way, thus benefits from defragmenting. That covers part of your comment.

On the other part, a sampler player such as VIP does not handle these samples as individual notes being randomly loaded from disk. I understand you think your "random" playing may translate into random disk reads, but that is not the case. Keep in mind there is a pre-buffer that is allocated and managed dynamically... too long to explain, but I'm sure this is not the first time I've seen a similar conversation on the topic in similar forums.

Last point, while your symphonic composition may be playing back say 80 simultaneous notes with 2 or 3 layers each (a stretch) at a given point in time, that would be, in your mind, that 240 "random" samples read from disk. First, they are not being streamed instantaneously from disk, there is a prebuffer likely handling a good part of that load; and secondly, if they had to be read instantaneously, my point was that you would have "simultaneous" 240 I/O calls to disk, and the determinant factor for performance would be the sequential read speed, not the random read speed, as each of these samples would most likely be chunks of 200KB, 1MB, 2MB, whatever, that are read on the SSD as sequential "pages" of 4KB each. So take a single 200KB sample. That'd be 50 sequential (likely, ideally) reads, not random reads. The sample is very unlikely going to be highly fragmented. In summary, you are comparing 240 "random" locations on disk, vs. a total of over 10,000 sequential page reads. Hope this really illustrates the concept for you, in an orderly fashion. It was always that way.

Nobody is arguing the superior performance of a SSD.