Vienna Symphonic Library Forum
Forum Statistics

199,072 users have contributed to 43,152 threads and 258,888 posts.

In the past 24 hours, we have 3 new thread(s), 14 new post(s) and 67 new user(s).

  1. Home
  2. Software
  3. Vienna Instruments Pro
  4. FEATURE REQUEST - VEP Mixer
  • M
    M
    last edited
    last edited

    @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.
  • D
    D
    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.
  • M
    M

    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.
  • D
    D
    last edited
    last edited
    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.

    @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.
  • M
    M
    last edited
    last edited

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

    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.
  • D
    D

    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
  • M
    M
    last edited
    last edited

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

    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 
  • M
    M
    last edited
    last edited

    .

    @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
  • D
    D
    last edited
    last edited

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

    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.

    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
  • D
    D
    ???
  • M
    M

    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.