Investigating Logic + VEP ideal setup

[Dewdman42]

I did a performance comparison this year of one track per instance compared to many tracks into one instance. I can’t seem to find it right now it if I can find it I will repost.

The other thing is that vepro is more efficient with one instance. Each instance is internally running a completely seperate vepro server. There is overhead for that. Plus each internal vepro server is running isolated from the others, so vepro doesn’t do many optimizations that it can normally do within a single large instance/server

 

[marclawsonmusic]

I am excited to hear how NoamL’s setup goes. It’s pretty much the opposite of what I have now so I’m sure there is something I will learn by watching him struggle through it (PS - thanks for the window into your process, NoamL)

 

[Dewdman42]

One final performance related comment about vepro. It has a preference parameter for number of threads per instance. The value of this preference should be vastly different if you are using one large instance vs one instrument per instance. When you use a single large vepro instance you configure that preference to a large value and let vepro manage your cores more. If you use single instrument per instance, then you set it very small to like 1-2 and basically you are letting OS X manage the core use instead of vepro. Everyone talks about how they think vepro manages the cores better but if you are using one inst per vepro instance, then it’s actually not doing anything at all to manage core utilization.

But what about in betweener scenarios? Like maybe 4-5 vepro instances with say a section on each instance? I actually prefer that workflow but what about performance?

Based on the above I feel it’s difficult to set vepro’s thread preference for this situation and not end up occasionally with under utilized cores.

i believe the results I found in comparison were that the difference in performance between single instance and one inst per instance was negligible though and it really comes down to workflow that works for you.

 

[Ashermusic]

Logic is not limited to one midi port. The AU3 vep plugin can handle up to 8.

It is true, however, that the articulation set editor does not appear to be port aware For channelizing by articulation id. Yet.

that is why I made my channelizer scripter which is freely available. That can channelize across up to 127 midi channels into a single vepro instance, one track per instrument like a score page.

i would hope in the future Apple will make the articulation set editor port aware for AU3

I don’t trust AU 3. I don’t need AU 3. And most importantly, if it isn’t broken, I don’t need to fix it.

I am done.

 

[DS_Joost]

I am building sort of a hybrid setup right now, because the Hollywood Orchestra sort of demands it. As in, I have two midi tracks per instrument (not all, but with most). Basically, I have one midi track with all the main articulations, like bread and butter ones, and one with specialized articulations. All of them feed into one audio track in Cubase per instrument but they can be separately pre-mixed inside VEPro. It works really well so far.

This means I sometimes have to consolidate, but not nearly as much as with the track per articulation method, and I can still access all articulations without running into the 16 midi channel limit, which is honestly not really up to par or even useful with modern scoring instruments. Sometimes it just isn't possible to reduce an instrument's playability to 16 channels.

This way, I have a best of both. I can play in on the fly 90% of my music and the other articulations I can add manually on another track if needed.

 

[resonate]

This looks interesting