Hello All -

I'm having this very issue.  I thought I'd localized it to using a local instance of VEPro in Cubase, but this has turned out not to be the case.  It does go away when I disable ASIOGuard on the plugin.  I think their dual buffer scheme is responsible, as it seems to be that switching between guarded and unguarded during play is what makes this happen.

When you are looking for a device to contain all of these drives, take care to read the specs. There are enclosures that will handle multiple drives but have limited data throughput for individual drives, which is what I believe you were trying to set up. Many multi-drive enclosures will give you ~1300MB/sec reads with a RAID but more like 200 with platter drives and 350 with SSD’s. And it’s not an issue with thunderbolt bandwidth at all.

This enclosure will do ~1500 MB/sec in JBOD mode. https://eshop.macsales.c.../TB3QMJB000/?fullDetails

I haven’t had much luck using USB drives for heavy streaming of libraries, and definitely not conventional platters. Though I did some years ago when I was touring and had to use FireWire drives, but it was basic VSL VI’s and not the de rigeur multichannel monsters we know and love today.

Honestly - if money allows, to me the coolest thing so far has been using nvme drives in an expansion chassis (as my 2013 MP has no slots) on PCIe cards. Just not a question of speed anymore at all.

Hi Paul - 

What's the deal with turning ASIO Guard off?  If Cubase compensates for that correctly should it be an issue?  Is the same directive in place for Studio One which has its own dual-buffer system?

Thanks-

Richard

Hi Steve -

I'm asking if anyone has compared using VEPro in server mode as the streaming IO with using it in standalone mode with, say, Network MIDI or MOL and using Dante as the IO.

Anybody?

Hello folks -

Doing some research into new interfaces. Lots of my favorite candidates now use Ethernet to connect to the host - Focusrite Red stuff via Dante, Avid Carbon via AVB - and I’m wondering if VEPro can coexist with Dante on a PoE switch network. (Carbon doesn’t work with a switch, so barring use of a Thunderbolt-to-Ethernet cable, it gets its own port.)

I realize that the Mac I use has two Ethernet ports, and that I could also use the Thunderbolt connection or the Avid HDX connection on the Focusrite, but I’m trying to figure out what’s possible. At the moment I’m enjoying the utility of having the second Ethernet port handling the wired internet network. I suppose the Ethernet adapter for TB could handle that as well.

I’ve heard some folks say that there is a latency improvement when using Dante with a Rednet card and network MIDI to control VEPro in standalone mode. Wondering if anyone here has experienced this. I know that you lose faster than real-time bouncing and recall, but most times these things are possible to live without.

One reason the Focusrite stuff is on the table is that it can function as a ProTools IO but also as a native DAW IO - in my case predominantly Cubase - and I wouldn’t be paying for DSP in the Carbon that I couldn’t use unless I was running ProTools. The UA is a little less, and maybe doesn’t sound as good, but lots of DSP is available - though their plugin ecosystem is fairly expensive, and many of their plugs are not suited for a real-time sequencing environment.

So I’m chewing on these points and wondering if others here have tried any of these things.

In a related area - can I run Catalina on my main Mac and Mojave on my satellite Mac? Any VEPro 7 issues there?

I’ll respect your wishes by not mentioning the name - though I think that the courts of the world would be clogged if someone got sued every time - or even one percent of the time - for complaining on the Internet - and also I’ll refer you to this thread where what you wish for was being talked about - I have long been a proponent of VEPro doing a lot more than it does now for MIDI processing. Here’s hoping we all get what we want.

The thread

Regarding price - I think if it this way: if a tool or sound library makes things faster for me, it will pay for itself rapidly. I work all the time (a very fortunate thing) and the music business has declined in rates generally (an unfortunate thing), so whatever makes it possible for me to do more with my time is desirable. I hazard a guess as to what my hourly rate would be based on how much I need to work to hit a monthly mark, project how many hours it would save me per month to use the product, and if it makes sense and if the product’s price is comparable to others (if any), that decides it.

Hello folks -

It’s coming time to build a new PC for remote VEPro duties. So I’m wondering what things I can do to address large buffer sizes in the remote machines I use. My main machine is a 2013 Mac Pro 12- Core with 128 GB of RAM and ProTools HDX with an HD|IO and the satellite is currently a 2010 Mac Pro 3.7Ghz 12-Core with 64 GB RAM. The remote machine is handling many things, most notably the SampleModeling brass which are pretty demanding CPU-wise, but also the OT Metropolis Arks and several percussion libraries (it’s also where I’ve “quarantined” the EW Play player). The main machine is doing various libraries including my VSL winds and strings, and also AudioModeling winds and SampleModeling strings, Superior Drummer 3, Damage 2 and a host of other Kontakt instruments, as well as Altiverb and a few other verbs for tail. I use a local VEPro to host the instruments, and the Reverb’s are all in Pro Tools. I sketch with most instruments turned off but a piano, and I can do this at a low buffer size, but when it’s all up and in use, I have to - have to - use a 1024 buffer to avoid the usual pops etc. (I’m working at 48/24.) In particular, the brass instances on the remote machine (an instance per section, and a Kontakt instance per chair) require 3 buffers in the instance to play back without artifacts. Everything in the satellite Mac is streaming off of nvme drives in a Sonnet 4x4 PCIe card, and throughput and latency are excellent. WiFi is off. Gigabit Ethernet connections through a Netgear switch. Cat6 cabling. Short runs. My instances of VEPro are on instrument tracks. I also use aux inputs for multi-out returns from VEPro.

So I can manage the delay after the fact very reliably - compensation has been fine; but obviously it’s no pleasure to play through. What I would like is a minimum of latency for real-time performance. Where can I look to start improving this? If I did less on the main computer and more on a very fast remote computer or computers, or if I did it all locally on a much faster computer? I realize that the newest tech in there is seven years old (though I bought the 2013 Mac in 2015 new). I’m just trying to figure out where the logjams are so a) I don’t configure my machines poorly and b) so I don’t spend a ton just to discover that I’ve gained 5ms of latency performance.

Also, I’m doing some transitioning for certain kinds of work into Cubase. I still use VEPro on the remote Mac but have found that for my workflow needs, using Cubase to directly host plugins works a little better.

So, VSL geniuses, what’s the path to awesome here? What aspects of a system govern buffer sizes the most - CPU speed, drive latency and throughput, other? How do I get a system to allow me to play a remote DSP-hungry instrument without having an eighth-note delay?

Thanks!

When the app you are referring to came out, there was nothing that did what it did.  Still isn't anything that does that.  I would certainly love to see VEPro do this, and in doing so become the object-oriented library-dominator it should be.  (See my recent post in the Ensemble software section.)

That said, I'm curious as to what you are basing your statements of inflated price on.  I mean, I know how much it is - I bought it.  It's not a feature of a mammoth app like Cubase or something - it's a specific app by a small developer that does a certain thing that some people find useful.  (I wish it were more like TransMIDIfier in terms of transforming the data as it's split, and I think they are working on that.) I don't resent them, or have a bad taste in my mouth or any of that.  It's a very iffy thing to decide what someone else deserves for what they do, especially when nothing else does it, and there's not much point in being bitter about it, if that's what you are doing.  Price doesn't require a warning - it is what it is.  Any consumer can decide if the feature set is worth it to them, and it's not the developer's fault if the expense isn't justified.  It was for me.  When I use it it's great.

Also, to put a finer point on it -

I’d like to see a divisi ensemble maker mode, where one could either:

assign targets defined by their size (which would then combine or split based on divisi rules), that could be told what the largest ensemble you want is and the largest one you have - say, if you had a solo viola and a four-viola ensemble, it could auto-create another instance of the four-violas to make 8, with randomization applied. It could be aware of what VSL libraries you have, for example, and make those automatically.

Or, one could build ensembles using solo instruments. Obviously this would work best with modeled instruments, but would be great for extending their functionality.

It could also engage layers as desired.

My goal is to be able to create a sketch on a piano track, then send some of it to a track that would output something useful as multi instruments. To write a four-voice thing, send it to “horns” and have it played back by four horns, and possibly using sustain pedal to indicate to VEPro that a line needed to be a4.

I also think this should happen because I’m not sure where they are going with this software but other than built-in early reflections placement software, I don’t know what will justify the next big version.

I agree. Because it would make one’s template (which naturally would include some setups using this tech) sequencer platform agnostic.

I can’t help but wonder if this is an issue with MIDI coding and timing that would not work outside of real-time - that if one were doing a non-real-time bounce that somehow that makes it too hard for them to do.

Yes, and I have many scripts that kind of do those things, but not flexibly enough and not outside that instance of Kontakt - so not that flexible. Rather than make a limited transformer that lives in the Synchron or VI player, why not put it where it does the most good?

Hi folks -

So what I would love to see in VEPro is the ability to take a MIDI input and apply modifications or rules to it before sending it to any instrument loaded.  To be able to load up sounds in VEPro and then be able to do things like  

CC-based articulation switching, even across libraries.

conditional layering (e.g. adding chamber staccatos to other libraries above a certain velocity) with key ranges.

constrained randomization of parameters including timing. pitch and cc values.

divisi logic that could handle voice-splitting and also switch articulations as section sizes changed - scalable from solo to chamber to standard to appasionatas, for example.  That could be set so that one had normal access to one's instrument targets, but also could have an input for chordal/polyphonic playing that would address these same targets via the divisi logic - with an option to capture the resulting splits as MIDI data to be drag/dropped into the daw.

library-agnostic combinations with modifiers to either unify the response of different libraries or cause one in a combination to respond on a curve - say, if I were using Synchron Strings Pro but wanted to make the orchestra even larger by layering it with some other library, but only as the CC dynamics approached 110 and thus scaling up the other library's dynamics at that point.

being able to easily combine sounds from different percussion libraries on the same incoming channel while still maintaining the sounds' separate mix settings.  So a master orch perf patch with elements from all over, balanced and reverb-matched, addressed with a single MIDI channel.

Yes, I know many of these things can be done within a sequencer - especially one like Cubase.  And I have Divisimate and TransMIDIfier.  But I'd like to have as simple of a master sequence as possible, with as few tracks as possible.  And I figure it could be the job of the plugin host to do useful things to whatever the user sends it.  And I feel like it could be very elegant to do it that way.  I love VEPro, and I want more from it.

Hello folks -

I’m considering AMD for the first time. Looking at building a machine that is made to run a lot of hungry VI plugins - modeled instruments primarily - as well as the traditional VSL and Kontakt instruments. If you have a 20+core AMD, can you contrast it to other setups you have or have had?

Also, though theoretical answers are what make the internet go ‘round, please answer only if you have one of these - I’m looking for first-hand experience with a cpu handling a large template for ten hours a day. I know what the theory is - I’d like to hear about it in practice. And we don’t need to bring price into it.

Thanks -

Richard

Even if using the same number of channels?  In other words, if the pipeline is faster, will it always use more CPU per channel returned, analogous to (though different from) using a higher sample rate?

Hi folks -

I’ve been replacing network cable in my house lately, and though that’s a separate network from my VEPro network (obviously), I’m wondering about something.

Cat 5e and Cat 6 will both do Gigabit Ethernet over shorter distances, but Cat5e is rated as having a smaller data bandwidth - so less data, even though it will conform to the basic spec of 1000BaseT. I’m wondering if anyone at VSL or in the user base has established (with evidence) whether or not the increased bandwidth of Cat 6 (or even Cat 6A) translates to any ability to lower the buffer multiplier, or if the logjam for that relies more on the power of the CPU’s of the computers in the network. I have a feeling that latency isn’t so much dependent on cable data bandwidth but That bandwidth allows for more channels of audio traveling back and forth.

Bonus points for anyone using a 10Gb Ethernet network (added on as an upgrade, because otherwise there would be no basis for comparison) who can speak to any difference there.

Thanks.

Sounds like a change of habit is in order. I use VEPro 7 and PT every day. I have template Server projects that I start with, with them decoupled in PT. When I finish a cue, I save a new Server Project with the cue name added. The other option is to work decoupled but save coupled - just click on the three-dot button in the PT plugin to go back and forth. That’s a better long-term solution in some ways because if you need to return to a session but have changed your template drastically since, it’s stored with your PT session file. A caveat - separate VEPro saving means saving means that once we have moved to VEPro8 and beyond, it might be easier to convert old stuff when it’s discretely saved in their format as opposed to embedded within a PT file.

Hello folks -

MIR is on sale, which draws me to thoughts of another attempt at buying and using it.  One thing that's difficult about sussing the viability of any solution for one's workflow is being able to ascertain what kind of performance one might expect from it on one's particular system.  There are a lot of posts with statements like "using a modern computer, these settings will most often produce an acceptable result."  I understand that kind of answer - I do!  But it doesn't help too much, really.  So many variables there, including what's acceptable.  We all work differently to a degree - some more real-time than others, for example.  I use a lot of SWAM and SampleModeling instruments, and with my VSL libraries I do a lot of breath-controlled performance, so responsiveness is key.  Being under deadlines, I usually don't want to have to play something dry and then place it in the space after - once the part is in I need to move on, and in any event not hearing things as they will be is a cognitive as well as a working slow-down.

  So in the interest of a narrow but perhaps repeatable spec, I'm asking if anyone else is working with a system like this:  2013 12-Core Mac Pro, 128 GB RAM, Pro Tools (HDX) as sequencer, HD|IO as interface.  Nothing similar to that - that exactly.  A template in VEPro using many different libraries and instruments, not just VSL but Kontakt, SWAM etc. - lots and lots of stuff.  Maybe 40 sources to put into MIR.  And also let's assume that you use HDX plugins for realtime processing as much as possible (as the native round trip on an HDX system causes latency).  What I'm interested in is the following:  If your template requires a 512 or a 1024 buffer in PT, what kind of buffering are you needing to do in VEPro and MIR to get stutter-free playback on a full-orchestra piece, and what latency in live performance does it incur?  Have you found a relationship between raising the VEPRo buffer and being able to lower the MIR one?  and do you get better performance by using MIR in PT or in VEPro?

I'm thinking that it would be very useful in general if people who used other systems or other platforms also had a place to list configuration and performance specs on this site - is there one? - but I'm really just hoping to hear from people who use the same system I do.

Thanks!

Updated to 7.0.973 on main Mac Pro and satellite Mac Pro. Both on Mojave 10.14.6, with latest security update. Now when I launch the server plugin in Pro Tools, The plugin displays the local host twice (same address, same instances) but doesn't show the server on the other machine.  

Screen sharing works, so it isn't a cable.  Sharing enabled on both Macs. Firewall set to allow VePro, VEPro server.   

Thoughts?  I use the satellite in my template every day so this is kind of a thing.

Thanks!

 

EDIT: When I updated software my IP address changed for some reason.  reset, fixed.

As mentioned in a thread below.

Bumping this.  

2013 Mac Pro, 2.7 GHz 12-core, Mojave.  Latest VEPro.  Sequencing with PT or Cubase or Logic.  Also a 5,1 Mac Pro with 2 3.6 GHz 6-core, Mojave with VEPro.  

Now that my template is larger I've been obliged to think about processor allocation.  To be honest, before I didn't think about it much - it was set on both of them at 6 or 7 per instance.  I did most things within one or two instances, and sometimes I'd add things and realize I'd "allocated" more cores than I had, but everything still worked fine.

 Now things are laid out differently - typically a library, like Berlin Strings, or CSS, or the AudioModeling winds, in an instance.  This was initially done so that my library could be modular and I could only use what I wanted at the moment - but now I kind of need all of it.  Now, in the case of the SampleModeling Brass, for example, I have them split out as horns in an instance, trumpets in an instance and so on, because I've needed to be sure they have enough dedicated DSP to work reliably.  Same was true for AudioModeling Strings when I was using them built into an ensemble - things seemed to go better when I dedicated sections to instances.  

I'm not having trouble now per se - but If I add anything I likely will.  

So is there any current wisdom about processor allocation per instance?  Would I be truly better off with fewer instances but more outputs per instance? (One instance - my "rock band" one - has 24 output pairs, because it's Superior Drummer 3, Trillian, many Kontakt instruments and the Synchron Yamaha piano.)  

In short - I feel like I may be under-using my computing power in some ways and overusing in others.  Thoughts, anyone?

 

Thanks -

Richard

Mojave 10.14.5, latest VEPro (Catalina with the update, .922 I think), Peo Tools 19.6.0.370

When I open my rather large template in VEPro, it loads (takes ca. 5 minutes). It’s saved as decoupled and corresponds to the cue I’m working on. I Launch ProTools. Load the session I worked on all day yesterday without issue. As soon as ProTools gets through restoring everything and is building the overview file, VEPro quits.

Returns this in the crash report:

Crashed Thread: 757 at.co.vsl.viennaensemblepro.ProcessThread.2

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000000001a8
Exception Note: EXC_CORPSE_NOTIFY

(Skipping down to the thread in question)

Thread 757 Crashed:: at.co.vsl.viennaensemblepro.ProcessThread.2
0 com.parallax-audio.Vss2 0x000000011dca3b6b AUBase::DoRender(unsigned int&, AudioTimeStamp const&, unsigned int, unsigned int, AudioBufferList&) + 1899
1 com.parallax-audio.Vss2 0x000000011dc998fe AUMethodRender(void*, unsigned int*, AudioTimeStamp const*, unsigned int, unsigned int, AudioBufferList*) + 46
2 at.co.vsl.viennaensemblepro 0x0000000110036dcb AUPlugin::process(long long, float**, float**, int, float*) + 763
3 at.co.vsl.viennaensemblepro 0x000000010fca177c AudioChannel::processFxRack(long long, int, float**&, float**&, int, float*) + 764
4 at.co.vsl.viennaensemblepro 0x000000010fca2b3d AudioChannel::process(long long, float**, int, float*) + 3181
5 at.co.vsl.viennaensemblepro 0x000000010fd0457a VIAudioEngine::ProcessThread::run() + 1178
6 at.co.vsl.viennaensemblepro 0x000000010fd2495e void* std::__1::__thread_proxy<><><std::__1::__thread_struct,></std::__1::__thread_struct,><std::__1::__thread_struct> >, void (VIAudioEngine::ProcessThread::*)(), VIAudioEngine::ProcessThread*> >(void*) + 62
7 libsystem_pthread.dylib 0x00007fff7c5152eb _pthread_body + 126
8 libsystem_pthread.dylib 0x00007fff7c518249 _pthread_start + 66
9 libsystem_pthread.dylib 0x00007fff7c51440d thread_start + 13

Took out my beloved VirtualSoundstage 2 and it works again.

So my question is - this happened all of a sudden, so has anyone else had a plug-in just spontaneously start killing VEPro? Or might it be a fragment of data or pref that VEPro sets in a plug-in that gets corrupted?

I rather miss VSS2 now - all of my AudioModeling winds were going through it. I’d found that MIR was a little heavy on the system and added too much latency to be a good fit, though I liked how it sounded. I’ve replaced VSS2 with an early-reflection program from an algo reverb and the show goes on, but... not insanely great.

Thanks.


</std::__1::__thread_struct>

I’m on Mojave. Running VEPro with Pro Tools 2019.6. Ten instances, probably 100GB of RAM usage. Also running it on a remote MacPro 5,1, also running Mojave. 8 instances, around 58 GB. Is there any reason I shouldn’t install the newest version? It appears to solve some issues I have been encountering.