An Idea for the old One instance verses many instances debate? What do you think?

[toodamnhip]

I have been testing, and reading past threads frrom members about using One Instance with many VIs on it, vs Many instances with one VI in each.

I have found in my own tests as well as those verified by others, that there is little difference CPU-wise, maybe a 1% improvement with a singe instance verse many instances. This may be due to the small plug in footprint of many instances vs a single, and some communication bandwidht needed for many vs one. 

My idea is this:

What IS really important is the Vienna plug buffer settings one might need. I think it may make sense to organize Instances based off whether you will need to play with buffers set to NONE or not? If I make a huge, single instance template and at 128, try to move the plug in buffer to "none", my system craps out. Because there are FIFTY instruments that have now been move to a buffer of 0. Too much!

So the only way to have separate control over buffers for one inst, is to have that instrument on its own instance.

So pianos? Yes! , give them their own Instance because it sucks to feel a spongy piano. You will want the plug in buffer on NONE when you track, and if that piano is buried in an instance with 50 things on it, MY CPU cant handle going down to a "none" buffer. So I NEED a seperate instance that can run at a zero buffer for piano.

Drums? Yes, zero latency is needed.

Strings? No unless its a bullet fast marcatto 

So I;m gonna try put slow attack items on one Instance, and fast attack items will be divided into new instancxes to allow for a separate settong of "none"

What do you all think of this? The only downside I see is it makes making templates less standardized as things are no longer separated by instrument, but instead, by potenial track latency requirements.

What do you guys think? 

PS.

I really think it sucks to not hear more from Vienna on this. They could be so much more helpful if they would just publish some real world examples of pros and cons for various approaches. Same goes for how to set up a dedicated server address between machines. Thereis is just too much to research to get to the bottom of all of this and Viennna could do MUCH better with real world examples. Great product, instructional support a very mixed bag, could be much better 

[Synetos]

I bounce back and forth with the concept of one vs many instances., as well

The problem: Lot's of variables make it hard for a standard recommendation.

One big one...OS. Macs like lots of small instances. PC's perform better with less instances.

If one is doing full orchestral stuff all playing concurrently vs Pop songs where you can work on drums, then pads, etc. In that case, you could disable whatever you are not using.

I think it really boils down to a blending of what works for your workflow, your gear, and preferences.

Hence, VSL just says least amount of instances will be best. What number that equals is all over the map.

Personally, I like working with one instance from the point of the DAW, but I cant stand that mess from the perspective of VEP.

[Dewdman42]

The vepro buffer size per instance only applies while the track is live. So there is not really any benefit to separating them out to seperate instances for that reason.

Also, there is no truth at all that macs like more instances and PC's like less.  In the past some people had trouble getting LogicPro to work with a single instance, but there is absolutely no truth that many instances performs better in terms of CPU...and these days with AU3 you can use a single instance on LogicPro much easier then before.  But there are still some other workflow considerations that have nothing to do with CPU, for deciding to use many instances, one instance per instrument track...in LogicPro specifically.  Pros and Cons either way.

Regarding performance....

The way VePro is designed, each instance is a seperate server under the covers..which means each instance consumes some overhead and resources.  That alone means single is better then many.  But more importantly is the thread allocation.  VePro has a configuration for how many threads PER INSTANCE.  If you use one and only one instance, then its pretty easy to calculate how many threads to allocate for your system, based on the number of cores...and VePro will then make every effort within that instance to allocate work to as many threads as your cores will support optimally.  Simple guess, you have 12 cores, so so set threads to 20, that leaves a few threads around for your DAW and OSX and 2 threads per core is a good guess.  But its not always that simple, but still....generally in this case you're allocating as mnay threads to VePro as you can, and VePro will manage which tasks go to which threads and optimize the core usage very well.

Conversely, let's say you take the classic LogicPro approach of one instance per instrument track.  That means you have potentially maybe 30 or 50 or 100 VePro instances.  In that case you would set hte thread allocation PER INSTANCE to 1 most likely, maybe 2.  You would still get good core utilization in this case because at any one instance you're likely that at least as many tracks as you have cores are playing at once...thus making full use of all cores...   This approach might impose a little bit more overhead because each instance is essentially its own server, which requires some overhead, but its a small amount.  The bigger concern in my mind is the workflow concerns, in this mode you don't have one mixer, one MIR stage, etc.  So I feel this gives up a huge part of the VePro advantage, particularly if you aren't using a VePro slave.

However what if you are in between those two scenarios.  Not a single instance and not 100.  What if you decide to use, let's say 3 instances .  Then how many threads should you configure VePro to use for each instance?  Should you configure them to 1/3 as many threads as if you were using a single instance?  One might think so, but that only results in optimal multi-threading performance if and when all three instances are being used equally at all times..thus spreading the load across all cores.  If you have moments during playback when 1 or 2 of the 3 instances happens to be kind of idle, then during those moments, the one remaining, and busy instance will have been under-configured and probably under-utilizing cores during that time with not enough threads active.

So IMHO, the current multi-thread scheme of VePro works very well for a single instance, very well for many instances, but is not ideal for a few multiple instances, because of the way that thread preference is set PER INSTANCE.

All that being said, I think you should make your choice based on workflow rather then CPU because I think most of the time it probably doesn't make that much difference on the CPU.

Getting back to the comment about the buffer size.  That setting is only on live tracks.  Non-live tracks are automatically bumped up to a very large buffer size whether you like it or not.  But that's a good thing.  So the end result is that whatever particular track you are recording, you can set the buffer wize to none or x1 or x2 or whatever you think you'll need for the part you are recording while you're recording it.  All the other tracks playing back will be using a much much larger buffer anyway.  There is nothing gained by seperating different instruments to different instances.

[toodamnhip]

I have not arrived at the same conclusions as you. Let me ellaborate:

**If I set the buffers to NOT "live" instances, it vvery much DOES mattter. If I set unrecord enabled instances to none, I will run out of power. I I set the "live" record eneabled instance to 4, it will lag terribly. Therefore my results show that the individual instances DO need to be set intelligently. This makes my ppoint agin-for quicker throughput, lower latency, it is important to be able to put an instance at a setting of "none". It DOES matter. And. again, if I do not set the other insatnces that are not being recorded into to a high buffer, I lose lots of juice.

**I have found threads to work besrtr at 1. In the event I have 50 pianos on a test instance, setting the thread to 24 on my remote PC applies. But I have been very saurprised to see that usually, trying to ADD threads above one, REDUCES performance. This is counter untuitive I know But I have changed these setting sttaring at CPU use and this is what Ive found. Occasionally if a given instance gets large, increasing to 3 threads has helped. 

**It would be nice if Vienna would make threads per instance more definiable. I would like to be able to assign 5 threads on one instance, 1 on another etc, as needed. Vienna could technicallt have some sort of inner memory which would ensure a user didnt go above maximum threads. But custon thread counts per instance is sorely needed due to hopw damn touchy this shit is. It really IS touchy and depends on many variables, on that I agree with you.

** I agree that the thread settings fall short when using a middle amount of innstannces. See my reccomendation above.

**Since posting this, I have tested again and foudn that at least when it comes to pianos, mutliple instances are better, ES{ECIALLY when considering how I work.. I usually end up bussing each instance back into my DAW for EQs and mxing. And I thoroughly proved last night that the system eats WAY more memory with one insance feeding mutliple VIs in a single VSL insatnce whe bussing the audio BACK into a DAW. If any user plans on dedicated returns back into their DAW, it is was more efficvient to just dedicated multiple VSL plugs and, multiple insatcnnes allows for a much better organization of the libaray.. It allows pre made Orch/Piano/Drum/sound FX as instances to be loaded for any song one is on.

[Synetos]

@Dewdman42 said:

Also, there is no truth at all that macs like more instances and PC's like less.  

I meant to say Logic. It's just assumed for me that I run Logic on Mac and Cubase on PC. Since I own both, I get to disagree. YMMV

[Dewdman42]

@toodamnhip, you actually do bring up one interesting point.  The whole instance will be in live mode, live mode from the DAW is not engaged per midi channel, its per instrument channel in the DAW..which means the whole instance will either be in live mode or not.

so I do see your point that different instruments, in live mode, may need bigger buffer then others, or visa versa for feel while recording.

But I think perhaps a more workable solution around that would be to use one isolated VEpro instance for whatever track you are currently recording.  Load the appropriate instrument channel onto that one isolated instance, record your track using the smallest buffer setting you can get away with.  Have all other non-live tracks playing through a different instance.  Those OTHER tracks will all be using a very high buffer size automatically because they aren't live.  But the one live track into the one instance..will be using whatever buffer size you configure in VePro. 

Once the the track is recorded, copy the channel settings over to the playback instance and send the midi to there instead of the so called "live" instance.  

I think that would allow you to custom taylor the buffer setting for whichever track you happen to be recording and also this would make it so that ALL tracks you are not recording will be using the largest possible buffer size while playing back.  And they could easily be in a single instance, per the earlier conversation.