191,865 users have contributed to 42,813 threads and 257,468 posts.
In the past 24 hours, we have 8 new thread(s), 54 new post(s) and 236 new user(s).
@V_ad_im said:
It means, that now it's possible to connect vepro standalone to sequencer directly, as vst3 instrument, without iac-driver(OSX)?
This is not possible. Server and standalone applications are separate because of synchronization issues. If you are using standalone, the only way to get MIDI into it, is by using a system MIDI driver.
The VEP5 audio plugin is instantiated in any channel, and connects to an instrument plugin. The instrument plugin is then responsible for sending and receiving the audio data to/from the slave.
The audio plugin does not offer MIDI input. VEPro for now also does not offer sidechain for fx hosting.
@TabSel said:
understandable. But, I so hoped for integration of the standalone app in the plugin in a way to have ONE session across all, marked as standalone session, with the server then starting the standalone app and sending the vepro project data from the daw, and vice versa. I use two pcs with a 52ch soundcard and am searching for a solution to have ONE project in my main DAW, setting up the slave machine with its hardware as well, instead of launching apps on each pc and loading two different projects into these, for one "logical" project... bummer.
If you want to use a standalone version with audio hardware output, you are forced to keep your communication in MIDI, saving and restoring VIFrame/Metaframe files.
@V_ad_im said:
It means, that now it's possible to connect vepro standalone to sequencer directly, as vst3 instrument, without iac-driver(OSX)?
This is not possible. Server and standalone applications are separate because of synchronization issues. If you are using standalone, the only way to get MIDI into it, is by using a system MIDI driver.
[url=http://www.servimg.com/image_preview.php?i=5&u=16988770][img]http://i48.servimg.com/u/f48/16/98/87/70/th/idea10.jpg[/img][/url] Hmm... What kind of synchronization issues? If it possible to send midi through network to VEPRO Server, it must be also possible to send midi through network to standalone, as I think... For UNIFORM, UNIFIED routing from host to any version of Vepro, standalone or server. Because it take many time, to change midi outs of 200-300 tracks from server to standalone and vise versa!@V_ad_im said:
Hmm... What kind of synchronization issues? If it possible to send midi through network to VEPRO Server, it must be also possible to send midi through network to standalone, as I think... For UNIFORM, UNIFIED routing from host to any version of Vepro, standalone or server. Because it take many time, to change midi outs of 200-300 tracks from server to standalone and vise versa!
As I wrote in an earlier post, it has to do with synchronization issues. In a standalone server, VEPro is synchronized to the soundcard clock. In server mode, it is synchronized to the master computer's sequencer. These live in separate worlds. If you want MIDI into your standalone VEPro over network, you have to use a netowork MIDI driver such as MidiOverLan or ipMidi.
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..@MS said:
These live in separate worlds.
@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.
