Martin, I understand it perfectly.
BUT: wouldn't it be possible to at least "integrate" the standalone app launch/kill and MetaFrame load/save into the client/server infrrastructure in a way that you instantiate the plugin in a daw project, and in the plugin interface you'd be able to launch one standalone app on each slave pc and have the MetaFrame loaded into it from the DAW project or serialized from the standalone app to the DAW?
In order to have the standalone apps launch state and their MetaFrames included in ONE host project, instead of managing multiple apps and their project files on multiple pcs for ONE logical project.
-
@V_ad_im said:
I am understanding it. Let it be! But, may be it is possible to make "network recieve mode" in standalone Vepro, for recieving signals from vepro server interface without 3rd party midi drivers? May be, for this purpose need special, "midiout-only" version of server interface? For what all it needs: In standalone mode latency is more lower, than in server(especially, if connection through network). It need in one project (with many tracks) switch to standalone, for playing and record notes, and switch back to server, for mixing and bouncing. For now, using a network midi driver is not problem - all works fine. Problem is wearisome rerouting: it must to change track midiout from iac driver 5 (for example) to Vepro server instrument 7, from iac driver 8 to Vepro 12, and vise versa, for each track! But it may be by only one click for all track at once, big time economy..From your post, I can clearly see that you don't understand it. Server and Master live in two different synchronization worlds. In server mode, VEPro only processes blocks sent from the master, at any point in time where master decides to send it blocks, which could be of varying size (especially in case of Logic).
-
@thedr said:
Thanks for your response. Would be great if we could eventually have midi controlled effects and a sidechain input. Regardless what we are getting sounds amazing! So are you saying that the FX plugin connects to the VEP instrument plugin on the Server hosting the effects?The "audio input" plugin connects to the VEP "Server interface" plugin. The Server interface plugin (just like today) is the one talking to the slave. The workflow for getting audio to a VEPro server is thus:
1. Insert VEP Server interface (instrument) plugin. Connect it to server.
2. Insert VEP Audio Input plugin on chosen track. Connect it to VEP Server interface plugin instance.
3. Insert audio input channel in VEP Server. Choose network input channel.
-
@TabSel said:
Martin, I understand it perfectly. BUT: wouldn't it be possible to at least "integrate" the standalone app launch/kill and MetaFrame load/save into the client/server infrrastructure in a way that you instantiate the plugin in a daw project, and in the plugin interface you'd be able to launch one standalone app on each slave pc and have the MetaFrame loaded into it from the DAW project or serialized from the standalone app to the DAW? In order to have the standalone apps launch state and their MetaFrames included in ONE host project, instead of managing multiple apps and their project files on multiple pcs for ONE logical project.This would be possible, but nothing we have planned.
-
TabSel, your idea is very good and usefull! It is near about what I want too.. but.. As I see, standalone mode is not favorite mode for developers, not for serious using, and not supported :(This would be possible, but nothing we have planned.
-
@V_ad_im said:
Martin, I speak about midi! midi routing. Midi signals, that going from host track to vepro. Not about audio from vepro. Midi drivers and Vepro chain from server interface to server are different worlds, and switching 100 tracks between these worlds take big lot of time. Is it possible, phisically, for standalone vepro, to recieve midi from server interface from host?As I have written a few times now, synchronization/timing is the issue. A realtime midi driver does not act the same way as a VST/AU plugin. Just trying to randomly ship block-based midi events from a server interface plugin to a standalone VEP would result in (very) unpredictable timing.
-
bummer. Well, take it as Feature Request, then. Would make Multi-CPU-Environments even more workflowy. As you already shed some light on how "Audio Input to Server" will work, would please shed some light on how "automation of plugs running in the server via the plugin client" will work? Will all Server plug automation parameters be available through the client plug? Or do you have to setup the server plugs and specifiy which automation parameters are forwarded to the client? Maybe another Feature Request: What about a VE Pro specialized VNC client/server solution: The client provides a tree list of plugs used in the server. Clicking on a plug opens a VNC connection, opens the plug on the VEPro server, the VNC server serves this plugs window only, the VNC client opens a VNC client window to show the VNCed plugin window on the DAW, forwarding mouse/keyboard actions to the DAW and the VEPro server... Something like that. Or like ReaMote (Reaper) works: you need to have the plug installed on the master AND the slave. Opening the remote processed plug on the master opens that plugs GUI without processing the plug, forwarding automation parameter changes to the plug on the slave... Oh, and I found one "design flaw" while testing v4: I use Novations Automap. It creates a "plugin (Automap).dll" for a "plugin.dll", "wraps this plug" and intercepts GUIEditor open/close calls to remap physical MIDI controllers to plugs automation paramaters, whenever this plugs GUI is opened/closed. VEPro v4 works perfectly with Automap wrapped plugs. However, the VEPro server only calls GUIEditor open ONCE, and leaves the GUIEditor open, even though the window isn't visible, when changing to another track for example. Changing back to the track with plugin does NOT call "GUIEditor open", and Automap doesn't have a chance to remap physical controllers. So working with Automap is quite cumbersome, as you can't just "make a plugs GUI visible" to automatically phyiscally control it, you have to navigate to this plug within the automap software manually instead. I reported this back in time, but never got feedback. Has this been changed with v5? I guess, I should just wait for the demo, right? But then, with you educational discount offer, it would be a financial advantage to know it beforehand 😉 Thanks for your time! 😊 Markus@MS said:
This would be possible, but nothing we have planned.
-
1. Audio input to server is done by inserting a VEPro Audio Input plugin as an effect on any track of your sequencer. This plugin connects to the instrument plugin, which in its turn ships midi and audio data to the server instance.
2. For automation of plugins and instruments in VEPro, you will have to select the parameters to automate in an assignment window. The chosen parameters will be available for automation from the plugin in your host sequencer.
3. We don't have any plans for a VEPro specific VNC solution.
4. In VEPro5, we have added an extra open call for the gui in VEPro5, if the plugin name contains "(Automap)".
Thanks,
-
-
I think it may be tomorrow, as the sale ends today at midnight. Just a guess though...
-
-
I have problem to assign more than 1 Audio input. I thought I could use an VE Pro server instance as a Reverb FX host and 1 Audio Input is fine but as soon as I assign the second audio input the "reverbs" distorts. Tried all buffers. Both on local host Mac Pro 6 core and network PC Q6600 HP.
Running Pro Tools HD10 with 256 samples buffer.
Sorry I will post this on the "Audio input thread instead".
-
Hi-will VEP5 be able to utilize VST instruments and effects on Mac, or is it once again AU only?