The reason I am running multiple instances is so that I can create new metaframes for different projects (depending on what a project calls for) without having to rebuild all of my plugs, sends, and instruments (a feature used to promote VEP software sales, btw). Also, if you are using 32 bit, you can't physically load everything in one instance due to the RAM limit. I have never seen anyone load all of their material into one instance, 64 bit or not.
Answer this one question for me then, please. If I can take my VEP instances and route them out of my RME card (and RME mixer), rather than the net audio outputs, how is that any different? Are you telling me that you can control the routing of VEP to 3rd party software, but not to your own??? Sounds like a bunch of wank to me.
-
1. Please watch your language.
2. Running several instances in one 32bit server will not overcome the memory limit of 32-bit addressing.
3. You cannot route anything from a VEP server to a soundcard.
4. VEP server is at the mercy of the host software, which can process instances at arbitrary order and blocksizes. With a bit of thought you can understand the implications.
-
The point I am making (and I have already said the several times previously and you didn't respond)is that, at some point your VEP metaframe turns over it's signal to your PC in order to route it through the network card and on to your sequencer. Why is it not possible to create something, a standalone mixer, or any kind of interface that allows you to route and process the audio once it HAS LEFT YOUR METAFRAME. In other words, once it has ventured outside of it's Utopian "Synchronization world" that it lives in within the confines of it's cozy little metaframe.
That would be awesome...so if you can do that on my sequencer, why couldn't you do it on my slave machine and have a mixer app with VEP plug ins receiving the audio, then sending it out of the network? It would be much cleaner and enable the user to keep the processing spread out across multiple machines.@MS said:
1. What we *might* allow in a future update, is to host VEPro plugins inside VEPro. Then you could connect to your slaves from VEPro, having VEPro be the receiver of the network streams, mixing it up, while connecting to your master sequencer on your local machine.
-
That would be awesome...so if you can do that on my sequencer, why couldn't you do it on my slave machine and have a mixer app with VEP plug ins receiving the audio, then sending it out of the network? It would be much cleaner and enable the user to keep the processing spread out across multiple machines.@MS said:
1. What we *might* allow in a future update, is to host VEPro plugins inside VEPro. Then you could connect to your slaves from VEPro, having VEPro be the receiver of the network streams, mixing it up, while connecting to your master sequencer on your local machine.
The problem is, there is no point where "VEP turns over the signal to the PC". See the entire chain of host channel-VEP plugin-instance as living in its own parallel universe. They can be called from different threads, in different order, with different buffer sizes. The one place where this "parallel universe" is unwrapped, is in the host (Cubase,Logic etc) mixer. Just how do you expect me to route and mix two unsynchronized streams of audio, with different buffer sizes and arbitrary processing order? You told me it is easy. Could you tell me what leads you to that conclusion?
The solution with allowing hosting of VEP plugins within VEP is a bit convoluted, I must say (I'd hate to explain it in a manual [:)]), but if it floats your or anyone else's boat, we could allow it.
-
@DG said:
Martin, if I'm understanding this correctly, you would have to make VEP the host, rather than the sequencer, in order to synchronise all audio streams, and then this VEP host would have to report its own latency, after synchronisation, to the sequencer?
Correctly understood.
The chain would be:
HOST > Master VEP Instance > VEP instance 1
> VEP Instance 2
We currently filter out VEP plugins from the VEP 3rd party instruments, but you can already try this (PC only) by copying the "Vienna Ensemble Pro.dll" to something like "VEP.dll". This will allow it to be inserted into a VEP instance.
It does get rather convoluted though 😊 One VEP step is more than enough for most people to handle, judgning from support cases. Introducing and promoting an additional layer of abstraction is only going to make it more complex.... Perhaps I can add a preference for "filter out VEP plugin from 3rd party instrument list", which will allow experimental users to create VEP chains of infinite length.
-
.
@DG said:
Having already been down this route with FXT and Chainer, I am not getting involved in this, so I would gently suggest that any Preference has to be altered for people wanting this feature, and those of us happy with the status quo should have to do nothing.
Exactly my thoughts
-
That would be awesome...so if you can do that on my sequencer, why couldn't you do it on my slave machine and have a mixer app with VEP plug ins receiving the audio, then sending it out of the network? It would be much cleaner and enable the user to keep the processing spread out across multiple machines.@MS said:
1. What we *might* allow in a future update, is to host VEPro plugins inside VEPro. Then you could connect to your slaves from VEPro, having VEPro be the receiver of the network streams, mixing it up, while connecting to your master sequencer on your local machine.
The problem is, there is no point where "VEP turns over the signal to the PC". See the entire chain of host channel-VEP plugin-instance as living in its own parallel universe. They can be called from different threads, in different order, with different buffer sizes. The one place where this "parallel universe" is unwrapped, is in the host (Cubase,Logic etc) mixer. Just how do you expect me to route and mix two unsynchronized streams of audio, with different buffer sizes and arbitrary processing order? You told me it is easy. Could you tell me what leads you to that conclusion?
The solution with allowing hosting of VEP plugins within VEP is a bit convoluted, I must say (I'd hate to explain it in a manual
I can't speak for everyone else, but I would certainly give it a shot. I would imagine latency and processing would increase on the host, hopefully not by much. You said you can already try this by changing the .dll name to VEP? Am I understanding this correctly? Is there any way to do something simliar on a mac? Thanks
), but if it floats your or anyone else's boat, we could allow it.