I believe I have wrote about this before, here and elsewhere. I have 2 monster machines--- master/slave, both 6 core i7-4960x turboed to 4.0Ghz, 64 GB of RAM, SATA 3 SSDs. I've been working with this library for a while now, and I have to concurr with the OP. There's just no way to run a full ensemble of DS without voice dropouts. I've tried every conceivable setting and every conceivable file distribution. Sometimes I can get away with turning off Vel XF, but this is an unacceptable kludge of a workaround. If someone out there is doing it successfully I would love to hear how. 

 

My wish is that VSL would re-save the enembles as single patches, because streaming 8 patches at once to get a single note is just killing the performance of this otherwise great library. Lord knows how people with lesser machines are making out with it. I realize that the power of DS is its ability to vary each solo instrument, but realistically most of the time I'm using either the full ensemble or divisi a2. Just having these two options would be fantastic. 

 

Thanks for your great products!!!

 

MOH

It's quite frustrating that DS cannot be fully utilized even with a powerful machine.

I wonder how DS demo's are created; I wish someone to share how they incorporate DS in their orchestral composition.

Well, you could always render the midi to audio. For me, this is something that I never want to do until it's time to bounce or archive the project.

P.S. It's not uncommon for sample developers to offer "light cpu" patches. All of my other VSL libs run fantastically well and I couldn't be happier. But in the case of DS with its high voice counts, I think it's warranted.

Best
MOH

This is strange. Running some 20 or so VI instances with DS patches in them really shouldn't be an issue for a 6 core/32 GB RAM machine. I work on one computer only (no master/slave) with 6 x 3,4 GHz and have never ever had such a problem, even with VE PRO/MIR PRO setups with 40-60 VI PRO instances in them.  

Could you specify a full number of VI instances and loaded patches you use for such a session? (+ number of audio processing plug-ins and how many of these are reverbs) 

5 instances of VIPro in VEPro with MIR Pro = 2 x DS violins, Violas, Celli, Basses.

Everybody playing together in legato with Velocity XF turned on. Depending on the passage of music, sometimes I can get away with it. But as soon as I start having lots of motion in the voices I get red lines, especially if there is a fast run somewhere.

The problem isn't CPU spikes but voice stealing (red lines on voice count). DS strings preload size at 8192. 

Thanks Goran

Sorry I should mention too that there is usually other stuff going on as well (ww, brass, perc). But that's not the point, really, because I can do whatever I want with orchestral strings + chamber strings + appassionata + solo all playing together. It's DS incredibly high voice count that is in question.

 

If I'm doing the math correctly:

8 x violins x 4 velocity layers = 32 voices for one note x 2 sections = 64 voices for violins

6 violas x 6 celli x 4 basses x 4 velocity layers = 576 voices for violas/celli/basses

Total for 5 notes: 640 voices

So if two voices overlap for even a second (which happens all the time) that will double that number to 1280 voices.

I also run 5 instances of VI Pro (2 x DS Vln, Vla, Vlc and Bass), plus other VSL instruments (I have DS on a separate SSD).

I just swtich from using Velocity X-Fade to keyboard velocity and CC11 for dynamic, the voice count decrease dramatically from approx. 260 to at most 70+.

Disabling the Velocity X-Fade kind of solve the voice dropping issue; still got some minor voice drop while playing complex legato passage among all string sections.

I have buffer set to 1024, defult preload is 8192.

I've just opened my old Wagner Lohengrin project to see what CPU usage values I get when I play the whole project - it almost never goes over 50 %, and it never goes over 60 % (and it's 52 VI instances  in MIR's Berlin Teldex venue + over 30 audio plug-in instances).

I have 12 DS violins + 4 solo violins + 2 orchestral violins instances for violins 1+2.

I now remembered I did have voice dropouts in this project, but only when I played it through for the first time after opening it. After that first playback, no further voice dropping whatsoever.

My latency setting for MIR is 16384.

You guys have multi-threading enabled in VE's preferences? 

@goran_tsch said:

I've just opened my old Wagner Lohengrin project to see what CPU usage values I get when I play the whole project - it almost never goes over 50 %, and it never goes over 60 % (and it's 52 VI instances in MIR's Berlin Teldex venue + over 30 audio plug-in instances). I have 12 DS violins + 4 solo violins + 2 orchestral violins instances for violins 1+2. I now remembered I did have voice dropouts in this project, but only when I played it through for the first time after opening it. After that first playback, no further voice dropping whatsoever. My latency setting for MIR is 16384. You guys have multi-threading enabled in VE's preferences?

I did not have vienna ensemble pro to host my vienna instrument. Is it beneficial to have VEP instead of loading VI as plug-in? Also, did you enable velocity x-fade while working with DS legato patches?

Hi Goran

But what about using also Dimension Violas, Dimension Cellos, and Dimension Basses? Just Dimension Violins is fine--- the problem is using Dimension Strings as a full ensemble: when 2 x Dimension Violins, Dimension Violas, Dimension Cellos, and Dimension Basses are all playing together.

I'm using VEPro.

My CPU level is fine, it's voice stealing/streaming that is the problem. 

Thanks

MOH

Curiously, I can run the whole DS thing (8 vl I, 8 vl II, 6 vla, 6 vlc, 4 cb) on my poor core i7 with 12 GB.  Indeed, the first play is full of drops, but the second is ok.

Here are my thoughts, for what they are worth : set the preload in VI to the maximum, increase the sound card buffer and maybe the latency of MIR.

One thing that helped, in Cubase 8.0.5, was to switch on the button in devices configuration -> vst audio -> activate Steinberg maximum power mode.  And of course, the new function "render in place" is quite easy to use and saves lots of resources, while quickly undoable for further editing.

Hope this helps.

Stephane.

@Stephane Collin said:

Curiously, I can run the whole DS thing (8 vl I, 8 vl II, 6 vla, 6 vlc, 4 cb) on my poor core i7 with 12 GB.  Indeed, the first play is full of drops, but the second is ok.

Here are my thoughts, for what they are worth : set the preload in VI to the maximum, increase the sound card buffer and maybe the latency of MIR.

One thing that helped, in Cubase 8.0.5, was to switch on the button in devices configuration -> vst audio -> activate Steinberg maximum power mode.  And of course, the new function "render in place" is quite easy to use and saves lots of resources, while quickly undoable for further editing.

Hope this helps.

Stephane.

Did you have Velocity X-Fade enable for legato articulation?
I experienced glitch and pop when Velocity X-Fade enabled for legato, no matter how many time I have played back.

Disable Velocity X-Fade seems solved my voice-drop problem.

Hi Stephane!

I've experienced the same thing, however, if I leave that section of music for a while, when I return to it I again experience drops. For me, this fix is quite unreliable because sometimes it will play OK but then begin to drop again on the 3rd, 4th, or 5th play. Furthermore, what if the whole piece struggles to play because of the density? It's too easy to get voice counts above 2500 with DS. Having to play through a piece multiple times is an incredibly frustraing experience, because "quick fixes" now turn into 10 minute slogs while I put my DAW in loop playback and leave the room for 10 minutes while it attempts to load everything. 

It's curious that doing anything in Cubase or MIR has any effect, because isn't the issue hitting the voice limit and not CPU spikes? I think the high latency values that you are describing are quite unwieldy for doing any sort of composing since there is just too much lag in order to play naturally. Maybe it's OK for mixing. 

My template could load in less than 2 minutes if it wasn't for Dimension Strings, but because I have to increase the DS preload buffer to >8192, loading is quite a painful experience. 

Since no one yet has chimed in to say that they can run full DS without any problems, again I'll reiterate my stance that DS absolutely needs some lighter patches-- please: no reduced velocity layers, just save the enembles as single patches. The solo players are already well balanced with each other, and each ensemble size (div2, div 3, etc.) already has its own slot in MIR. Not to mention that it would make customizing the patches in VIPro much easier, since instead of making changes to 8 slots we'd only have to make changes to one slot. Not to mention that VSL could benefit from being able to drop the system requirements on this great library. I can't see the drawback to doing this, except for the poor guys at VSL who actually have to do it :-P 

Thanks for the input.

MOH

i have a 2014-macpro 8core 32gig and can easily run my 10/8/6/6/4-template along with other orchestral instruments.

before the new macpro i had a slave macmini 2.3 i7 4core with 16 gig ram and could run the same template. i had some dropouts at fast runs on all sections (crackilng as the voice counter showed about 1250 voices). on both macs dimension strings are streamed from ssd.

Well that's a good news at least! :-)

But you did have drop outs on runs.

When I get a chance I will see exactly how much polyphony my system can handle. On the last project I did (orchestrated a musical) the score got very dense at times, and Dimension Strings was always the choke point.

Thanks for your input!

@mohurwitzmusic said:

If I'm doing the math correctly:

8 x violins x 4 velocity layers = 32 voices for one note x 2 sections = 64 voices for violins

6 violas x 6 celli x 4 basses x 4 velocity layers = 576 voices for violas/celli/basses

Total for 5 notes: 640 voices

So if two voices overlap for even a second (which happens all the time) that will double that number to 1280 voices.

 

Not exactly 😉 it is (6 violas + 6 celli + 4 basses) x 4 velocity layers =  64 voices for violas+celli+basses, which together with violins amounts to 128 voices for complete string orchestra. 

Perhaps you can try to experiment with increased values in the Audio Engine section of VI PRO's General Settings (I believe Stephane already suggested this). These are also described in the VI PRO manual. 

@goran_tsch said:

I've just opened my old Wagner Lohengrin project to see what CPU usage values I get when I play the whole project - it almost never goes over 50 %, and it never goes over 60 % (and it's 52 VI instances in MIR's Berlin Teldex venue + over 30 audio plug-in instances).
I have 12 DS violins + 4 solo violins + 2 orchestral violins instances for violins 1+2.
I now remembered I did have voice dropouts in this project, but only when I played it through for the first time after opening it. After that first playback, no further voice dropping whatsoever.
My latency setting for MIR is 16384.
You guys have multi-threading enabled in VE's preferences?

I did not have vienna ensemble pro to host my vienna instrument.

Is it beneficial to have VEP instead of loading VI as plug-in?

Also, did you enable velocity x-fade while working with DS legato patches?

Yes, VEP is very memory and CPU efficient (apart from all the other advantages it has).

I have both vel xfade (on all) and slot xfade (on some players) on DS patches in this project (with slot xfade you can double the voice count for an instance if the two patches have the same number of velocity layers).  

Oops! My bad. Back to high school math for me, eh?

Thanks. I will persevere and hopefully I can fix the problem.

As long as I know that someone else out there is running it without any voice limits that gives me hope, though it does seem that at some point almost everyone experiences a voice limit ceiling making certains types of writing precarious. 

FWIW I have indeed experimented with this setting.

Thanks again!

MOH

@goran_tsch said:

I've just opened my old Wagner Lohengrin project to see what CPU usage values I get when I play the whole project - it almost never goes over 50 %, and it never goes over 60 % (and it's 52 VI instances in MIR's Berlin Teldex venue + over 30 audio plug-in instances).
I have 12 DS violins + 4 solo violins + 2 orchestral violins instances for violins 1+2.
I now remembered I did have voice dropouts in this project, but only when I played it through for the first time after opening it. After that first playback, no further voice dropping whatsoever.
My latency setting for MIR is 16384.
You guys have multi-threading enabled in VE's preferences?

I did not have vienna ensemble pro to host my vienna instrument.

Is it beneficial to have VEP instead of loading VI as plug-in?

Also, did you enable velocity x-fade while working with DS legato patches?

Yes, VEP is very memory and CPU efficient (apart from all the other advantages it has).

I have both vel xfade (on all) and slot xfade (on some players) on DS patches in this project (with slot xfade you can double the voice count for an instance if the two patches have the same number of velocity layers).  

if I use Vienna Ensemble instead of the Pro version, will VE produce the same efficiency on both CPU and RAM as the Pro version? I'm running it on the single machine, no plan for building a slave.

@mohurwitzmusic said:

Thanks. I will persevere and hopefully I can fix the problem.

As long as I know that someone else out there is running it without any voice limits that gives me hope, though it does seem that at some point almost everyone experiences a voice limit ceiling making certains types of writing precarious. 

Best of luck with this. DS is a great and pretty unique tool, it would be a shame not to make the best of it when one has it. Perhaps you just need to find the best combination of preload and voicing settings in VI PRO, as the overall voice count for the setup you mentioned really isn't that high.