@delaplanemusic said:

I am not talking about sending audio from one instance to another within a metaframe. I am talking about every instance sending to a master mixer on it's way out of the metaframe, that also has the ability to host your plug ins. I don't believe for a second that this is an impossible task. In fact, it is SO simple it's stupid. VEP works independent of hardware, so at some point VEP hands the routing off to your PC or mac to stream the audio. And it is able to route to multiple outputs over lan, which means that there are your 32 or however many streams of digital audio, already seperated traveling through your PC as determined by the vienna software. In VEP standalone you have the ability to route audio through different hardware outputs, so why not create something that tricks VEP into seeing the mixer as a hardware device, and then have the mixer determine your net outputs? This would be something that would be relatively simple to do, and would improve the workflow of your customers ten fold! Martin, no disrespect because I love the software, but I doubt you use this software as much as the majority of the people on this forum. Just because it is working, does not mean it can't be improved. This would be massive for VEP users. Hook it up! Much love... Nick

Nick, I have explained this before. Each connected instance lives in its own "synchronization universe", and thus they cannot be interconnected or mixed without introducing latency. In fact, each instance of a VEPro Server might run with a different buffer size - one instance at 256, another at 1024 etc, all at the mercy of the host application. I don't know what makes you describe this as "something that would be relatively simple to do".

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.

@delaplanemusic said:

I am not talking about sending audio from one instance to another within a metaframe. I am talking about every instance sending to a master mixer on it's way out of the metaframe, that also has the ability to host your plug ins. I don't believe for a second that this is an impossible task. In fact, it is SO simple it's stupid. VEP works independent of hardware, so at some point VEP hands the routing off to your PC or mac to stream the audio. And it is able to route to multiple outputs over lan, which means that there are your 32 or however many streams of digital audio, already seperated traveling through your PC as determined by the vienna software. In VEP standalone you have the ability to route audio through different hardware outputs, so why not create something that tricks VEP into seeing the mixer as a hardware device, and then have the mixer determine your net outputs? This would be something that would be relatively simple to do, and would improve the workflow of your customers ten fold! Martin, no disrespect because I love the software, but I doubt you use this software as much as the majority of the people on this forum. Just because it is working, does not mean it can't be improved. This would be massive for VEP users. Hook it up! Much love... Nick

Nick, I have explained this before. Each connected instance lives in its own "synchronization universe", and thus they cannot be interconnected or mixed without introducing latency. In fact, each instance of a VEPro Server might run with a different buffer size - one instance at 256, another at 1024 etc, all at the mercy of the host application. I don't know what makes you describe this as "something that would be relatively simple to do".

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.

@delaplanemusic said:

Eh, I know you have commented several times...but I wouldn't call a "synchronization world" an explanation. But if that is truly your concern...how about this Instead of adding a mixer window to the metaframe, add a "view" option to the metaframe that allows you to view and edit all of the tracks in each loaded VI frame, in one mixer window. That way, you aren't adding any more latency, and you "synchronizxation world" is still safe and sound. Now, if you tell me that is not possible, or easy, then I am afraid you are smoking crack, my friend.

There are of course a variety of ways one could look at the issue. Our best recommendation is for people to use a single instance. This will give you better performance and a better overview of your setup.

Now, changing the infrastructure to involve several separate audio engines (which in essence is what each instance is), being displayed in a single window, but not being inter-mixable or inter-connectable, limited in routing with sends or the likes - with all project handling that comes with it, persistence, data saving, project recalls and so on - is far from simple. It would also be very confusing for the user.

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.

@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.

@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.

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?

DG

@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.

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. [;)]

DG 

It is not possible to rename the component on Mac, since the AU plugin enumeration works in a different way. You will have to wait for an update that enables this. I will probably add a setting in VEPro preferences, that will allow to view/insert VEPro plugins inside of VEPro.