I have been finding that some FX, like Ozone, really push my system, and had wondered whether there was a 64bit version of a utility like FX-Teleport.
I did check out VEPro before, but found nothing mentioning about taking audio inputs.
However, I just checked the VEPro page for something else, and found:
Audio input plug-in – Route audio signals from your DAW into Vienna Ensemble PRO, e.g., to turn it into a virtual FX rack on your slave computer.
though it is limited to:
VST3, AAX and RTAS connector plug-ins – Supports up to 48 MIDI ports and 768 audio ports per instance.
but I don’t know if that means VST2.x FX are not allowed, or just that the VEPro plugins themselves are VST3.
As a VEP license allows three server instances, that allows three racks, unless there is a way to route FX to different VEP output channels, which would allow a lot more.
Makes for an expensive FX rack, but it is cheaper than upgrading an already souped up machine, and using a space older spec box instead.
Not sure what your question really is here but since I have VEPro up and running let me give you my impression.
I have used VEPro for three reasons: Running older plugins, running plugins that are PC only on my MAC and 32/64 bit problems.
I have a MAC as my main machine and a PC with XP OS as slave. On the slave I can then have older plugins and plugins that are PC only running in Cubase on my MAC. These are both instruments and FX. Connection is through an ethernet cable and a VEPro instance on both machines. Older VST is no problem, but… VEPro does NOT handle every plugin. I am especially sad that it cannot handle Broomstick.
The 32/64 bit problem: jBridge does not handle all 32 bit plugs well. VEPro does a better job here. It used to be the other way around, running Cubase 5 in 32 bit mode and VEPro in 64. But since Cubase 8 is 64 (5 is not on a MAC with Mountain Lion) I use VEPro to run some 32 bit plugs.
Both slave and VEPro inside the main machine is a bit cumbersome and you need to really concentrate on the saves and links as these are saved separately in VEPro and on each slave.
Would I recommend it … well it is quite expensive and I do not think I would recommend it for Ozone which I also have and run it on the main machine. To graphically access the slave you either need a separate display or a switchable one, connected to the slave computer. You either need a separate keyboard/mouse or a switch system. In a mastering session where you need to operate several “handles”, I think you would find the slave/master system a showstopper.
Horses for courses, really. Cost-benefit analysis required, and the opportunity cost may tip in its favour compared to current alternatives.
If someone were to bring out a 64bit FX-Teleport equivalent for a single remote VST stack, it would be likely to be much cheaper than VEP, but it isn’t here, … yet!
Since we are all Windows, Remote Desktop does it all, as it is pretty quick to bring up the remote desktop for ad-hoc adjustments, and close when done. Certainly better than separate sets of input devices or hardware switches.
Hi, Patanjali. I’ve been researching this for a while.
VEP Pro will not work for FX, even with its Audio Insert, due to a known issue with how it returns the audio back from the slave.
You will end up with the FX out of sync.
It works fine with Virtual Instruments (that don’t use the VEP Audio Insert), of course.
It can work acceptably with simple FX use-cases that can work asynchronously, like basic reverb.
The issue is that the host DAW can’t do its PDC on the channel, because the VEP Audio Insert does not return on the channel, it returns somewhere else. That is to say, the PDC the DAW does do, ends up being wrong in most cases.
Very simple setups, without cascading busses and with other inserts in the project that are either zero latency or where the latency masks the issue, may not initially show the issue.
But for any kind of a serious project, the issue will eventually present itself.
There is no workaround.
VSL has admitted to the limitation and had revealed that they are working on a special “Remote FX Rack” product to address the need. No date was given (and this was about a year ago).
Here’s my saga. Way too TL;DR, but it does eventually have an official response from VSL finally ending the long debate I had with someone claiming it would work (but just not understanding why it wouldn’t).
It’s tricky. You have to use its ASIO component (ReaRoute) to expose virtual audio cables, use Cubase’s External FX insert, run Reaper on the same machine and then use its Reamote to another machine running the Reamote slave.
It works. but is not optimized and you’ll only get about 4 channels over a non aggregated gigabit Ethernet. Depending on what you’re doing it may be enough.
It also has latency / sync issues that are a huge PITA, but can kinda be worked around by inserting a bunch of Voxengo sound delay plugins and fiddling with the values. It’s a nightmare though and changes each time you relaunch everything.
Then there’s Audiante Via.
But it’s not out quite yet, but will be later this year. It will create a virual audio interface between networked computers. In theory, you could then use the External FX insert. Or use VST System Link (built into Cubase) to sync with another instance of Cubase on the slave. Use Dropbox to sync the project files.
That’s what I’m waiting for.
The other solution is to use VST System Link with a MADI interface or the new MOTU AVB networking interfaces (which are about half the cost), but it’s still not cheap.
Here are some audio interfaces to drool over that would work. This is the real solution if money were not object, as it’s less fiddly.
The RME RayDAT may be the way I end up going. It’s bullet proof. Not cheap, but cheaper than its closest hardware alternative.
I already have two Focusrite Saffire Pro 40’s that can be joined in dual mode and therefore have 16 optical channels. So I’d only have to get the RayDAT on another machine to matrix 8 stereo pairs between them.
Yes, PDC is impossible to do properly unless the I/O is strictly ONE return for EACH send, and not many to a bus.
However, it may work for us, as we run REVerence and Ozone’s Maximizer on the output bus, beyond any parallel FXs that would be affected by improper PDC calculations.
I suggested to Audinate in January 2014:
to which the Audinate CTO replied:
When they preannounced Via five months later, I brashly sent the message:
to which I got the reply:
Interesting timeline, especially given that it is still in beta.
I wonder if the delay is due to trying to get clocking working right when legacy interfaces have hardware clock I/O that needs synchronising and Via is only software? Personally, I think they will need a Dante Ethernet to clock output box.
Oh, right. You’d be fine with that serial use-case with VEP then (as you well know).
I’m doing a similar thing with a realtime mastering chain offloaded on another computer. I use ADAT optical to matrix the two together along with Cubase’s External FX insert thing. Works flawlessly. For such a small channel count, it’s worth considering a hardware solution, if you have the spare optical ports.
Holy smokes!
I hope they at least made/make you a beta tester. I applied months ago, but have not heard back.
But in all seriousness, with as much intellectual property as they have in audio networking, doing VIA is low hanging fruit. These guys live and breath it all day long. Some of the founders probably talked about it 20 years ago over beers and are just now able to realize it.
As someone with an ambitious side project myself (started over 10 years ago), I know the feeling.
Yeah, could be. The problem probably goes away if doing offloading use-cases only, and at a buffer high enough to guarantee a fixed latency, but that’s probably only a small use-case they need to cater to.
Ha. It’s like the old days of SMPTE striping. I used to beta test for Midiman (before it was M-Audio) and remember when their Syncman Pro had the ability to “freerun” over tape dropouts. There is probably a lot of stuff like that going on with Via, too.
Aiden did invite me in the next sentence after that second reply I cited, and I did try to apply, but for some reason, the web site wouldn’t work properly.
I have been up to my neck in my own PHP project for the last year and have just completely disassembled our studio, so I am not really wanting to, nor really set up to, undertake any beta testing on anyone else’s behalf, and am willing to wait until products hit production.
Very low hanging fruit, but just because someone has expertise, does not mean they think of such things.
Look how long Palm and Windows Mobile had been out, basically doing multi-tasking and live data displays like Android, but only popular with the tech-literate, until Apple came along and simplified the interface to a sea of icons that the masses could get their heads around.
All those tech companies before could have easily done that, but they didn’t. Sometimes, it is just that those who are too buried in heavy tech stuff can’t see the simple things.
As for a timeline, with Audinate’s experience with ASIO clients and their own Dante libraries, it would have only taken one of their experienced developers a month or so to develop a working proof-of-concept for Via as a back-burner project, after which another month or two of testing of a couple of primary scenarios to see if it could fly. And that is being generous with the durations.
I have been a tech writer for 20 years, documenting software and doing templates for software development, and previous to that 10 years of high-density printed circuit board design, so I am quite familiar with engineering processes and development sequencing and timeframes in the real world, as people actually do them.
Via, as a concept, is fairly small timescale development, but it only takes an unforseen technical snag to derail even the simplest of ideas!
At risk of diving deeper into a friendly debate (software engineer of over 20 years myself here)… I think the “simple multitouch mobile” example only bolsters the point I was making, which is that often the “obvious” is simply out of reach.
Apple was first to make it happen, and had been working on it for years in secret, but just about all the tech companies had been showing sexy “concept models” of minimal, flat iOS-like devices for decades.
I’m of the opinion that “the idea,” while traditionally so fashionable to champion as being all-important, is beginning to take back seat to raw execution prowess.
I don’t think Star Trek deserves much credit for the iPad, simply because they had the idea before Apple.
As for the timing, I think your hypothetical timeline would be correct if it were a multidisciplinary team working together on the prototype, or a rock star, full-stack engineer that did everything from ASIO to networking (it’s possible).
Like you said, it could be a snag(s). Perhaps even more likely is that since it’s not a revenue stream yet, resources may have been pulled to put out, inevitable, various fires.
As you well know, it’s not uncommon for experimental products to operate this way for a long time. Like a pet project or mini startup on the side within the company, while still maintaining core duties.
Anyway, you should see if you can get a fee copy out of it.
I’ll update you here if I get my remote FX pc operational. It’s all set, plugin licenses included, and just needs the remote FX solution.
I just need 8 stereo channels in and out for a sort of real-time “external summing / stem mastering” concept.
(I just realized this reply will probably relegate this post to “the lounge.” If so, sorry about that.)
