Hi there. I use VEP for just about every instrument in my pallette. I have it running on three seperate machines (2pc's and one mac) and one thing that would be amazing is if there were a mixer page in each metaframe that you could route audio to before sending your audio out to your sequencer. I have about five or six VI frames in each metaframe, and I am hosting almost all of my plug ins and FX in each VI. It works very well, but when it comes time to tweak or change a verb send or a plug in setting, it is a pain tracking everything down between 15 VI's spread across 3 machines. It would be so amazing if a feature that was in the works was a "Metaframe Mixer". Where you could have one mixer that loads with your metaframe, in which every VI's audio output can be routed before routing it out of the Net outputs. Sort of like Plogue (but better, obviously). This way, your could do the majority of plug in and verb modifications in one window, rather than having to track down every sound on every computer.
In other words: If you have a metaframe on a computer that consists of 5 VI frames. Perc, WW, Brass, Strings, and Ethnic. You could have your string (let's say Long Strings, and Short Strings) outputs sending to the mixer - Hi and lo perc sending to the mixer, etc. Then on your mixer you have every VI's verb send, EQ, compression. Then the outputs of the mixer are being sent out of your Net 1-2, 3-4 etc. I don't think the new version does this, although I guess there is an option to send audio into vep? I am just looking at the features now. If this is not addressed in v5, this feature would be SO huge. Especially since many people are still hosting plug-ins in their sequences and in Pro tools. Let's get this happening, if it's is not already in the works. Any thoughts? Suggestions?
-
FEATURE REQUEST - VEP Mixer
-
It's still a great original post though!
How about a "gateway" Application on the main DAW machine. I am not a programmer so I am guessing here, but it would seem possible to run a VSL type mixer on the main DAW, that is receiving all the audio from all the various slaves on the network. This "VSL Mixer Ap" would then slave to the sequencer running on the DAW, perhaps as a locally connected server.
In effect, this "VSL Mixer Ap" would hijack all the ethernet streams being received by the DAW machine, and create a submix. It would host pugins etc etc. Perhaps this "VSL Mixer AP" could be running on one of the slaves?
The point is, professional users like myself and the original poster, are spending much too much time "hunting around our slaves" to work out what is what. At the same time, maintaining templates so that a whole bunch of sequencer projects can be loaded quickly. The ability to have a "mixer" up and running all the time would be amazing.
In fact, it crosses my mind to try this approach dusing another copy of Nuendo or something on a machine, and spit the submix to my DAW via ADAT or something. Worth trying out at least to see if the work flow makes sense. I know I am tired of hunting.....
-
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... NickI have explained several times on the forums before, why this is not possible. Each instance in a metaframe lives in its own "synchronization world", so routing or mixing between instances is not possible.
-
That would be great, too. But you would still have to pick through multiple VI's if you wanted to adjust a plug-in. Not great.@DaveE said:
The "mixer" could be nothing more than a remote control app that turns down the fader inside its connected instance. =)
-
@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... NickNick, 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... NickNick, 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.
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.
-
@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.
-
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.