I've actually been hoping for this exact feature in VE Pro - unlike MoL, VE Pro's midi is sample accurate.  Perhaps because I'm working on a Mac Pro master with Mac Pro slaves, I have found the midi timing of MoL to be inconsistent, especially around sudden tempo changes.  VE Pro's midi is incredibly tight - however, like Jose, I have found the high latencies and drop outs of audio over lan to be too frustrating, and now use VE Pro standalone with multiple Symphony cards (via S-Bus).

Two wishes:  if VE Pro (plugin) could access my Apogee hardware outputs, I could then use VE Pro's sample accurate plugin MIDI - or if VE Pro standalone could be triggered by VE Pro plugin MIDI, we'd have the best of both worlds.

Erich

@Another User said:

Two wishes:  if VE Pro (plugin) could access my Apogee hardware outputs, I could then use VE Pro's sample accurate plugin MIDI - or if VE Pro standalone could be triggered by VE Pro plugin MIDI, we'd have the best of both worlds.

Erich

AFAIK there is no possibility of using audio out from a plugin, except back to the host due to the specification. However, I could be wrong, so unless VSL chimes in, you could always ask Apple, as they design the AU specification. Regarding plugin MIDI I have no information, accurate or not.  [;)]

DG

welcome bcslaam,

well this wish sounds reasonable and somehow simple, whereas it is not by design.

let us have a look at the involved components:

MIDI, which is sent in a serial protocol (one message after the other) and while modern solutions like USB, mLAN, MoL or VE PRO are much faster than the old MIDI cables with opto-couplers adding huge latencies there is in fact no *same time* signal like from a worldclock but always an *approximate same time*

MIDI clock messages do provide a reference to keep multiple devices in sync, but it is not connected to a world-clock, not 100% accurate and does not provide a *back-channel* to let the sender know if the receiver falls out of step.

VE PRO provides such a clocking between master and slave due to its two-way-communication (taking the various latencies into consideration), but de-coupling the send from the receive transport would break even this *clocking*

also to my knowledge there is no way to have the send using VST or AU but routing the resulting audio output directly from the plugin to a physical audio device without going again through the sending host application.

christian

Thanks for reply Christian I do realize there needs to be a loop back so the clock/latency can be compensated for, as I mentioned in my first post.

But what if the necessary timestamps are returned down the LAN to achieve this, minus the main part of the audio data. And then send the audio stream to the local soundcard of the client.

Or another perhaps easier solution would be let the audio return down the lan as normal host/slave and the appropriate sync maintained, but to also send a copy of the audio stream to the local soundcard of the slave client. We could then just mute or turn down the VST/lan return in the master server and use the soundcard audio of the client.

I do prefer the first option if it were possible though. Cheers Ben

BTW how do we get our paragraphs happening, I like to break my posts up into paragraphs but they just get put back into one big ugly clump thats hard to read.

[edit] all sorted thanks christian

combined safari & richtext editor issue ... changed the settings for content editor to enhanced in your profile now ...

christian

@cm said:

combined safari & richtext editor issue ... changed the settings for content editor to enhanced in your profile now ...

christian

hth, christian

@joseherring said:

Hello,

I was wondering if there are any plans to do this.  I want to use the midi over lan feature in VEPro but I want to lightpipe the audio back to the DAW.  Audio over Lan is driving me crazy.  Too unstable.  Too much latency for any serious work.  But, instead of buying Midi over Lan I'd like to use VEPro as both a midi over lan app and a standalone vst host.

Thanks,

Jose

 I haven't had any dropout problems and find the latency fine. There have been a few posts from people with "dropout' issues anf I find this a little troubling. How are you folks using VE Pro, i.e. how many simultaneous voices, what vstis etc.?

I basically use several instances of Kontakt (3.5) on a 64 bit Ve Pro instance (decoupled) for large piano and orchestral libraries and a second 32 bit instance for Superior 2 and varios synths (not decoupled).

Using the 32bit with 5 instances of Kontakt 3.5.  Run a test for me if you would.  I tested the system over serval days by just using a single patch of an 8 bar sustained looped over and over.  Every 3 to 10 minutes I'd get a noticable dropout.  In actuall practice it would drop out every 15 to 20 minutes.  I just can't take it.  I know for many that this would probably be fine, but I just can't handle it.  Makes me doubt every mix I do thinking that I've recorded a pop or dropout, ect.....

Just to clarify. I thought this thread didn't relate to midi over lan as a discete function. It relates to still being able to control the remote client via the VST over lan method (server/client) but being able to bring the audio through the clients local sound card.

The main aim of the game is sample accurate timing whilst avoiding the problems associated with returning the audio down the lan.

The thread title should read something like Using local sound card whilst in client mode.

In my opinion if midi over lan is covered by MOL or ipMidi programs then a working composer can go out and buy it if they need it. I own MOL for this purpose. Whilst it would be a convienient and economical feature to have midi over lan in VE Pro as well it's not breaking new ground or addressing sample accurate timing, which no product has done in this way.

Midi nor any future hybrid by its very serial nature will never achieve this. There has to be a time stamped loop so that latency can be dynamically compensated for. Only then can sample accurate timing and perfect tempo sync be achieved in the client.

An excellent idea to be sure.  I hadn't really thought it through.  I just got Ipmidi and am using VEPro in standalone mode.  But, retaining the features of client mode whilst (I love that word) using Adat or Madi to bring the audio back would really be the best of both worlds.  Though I'm sure you'd lose some of the conviences of client mode in the processes.

Jose

@bcslaam said:

The main aim of the game is sample accurate timing whilst avoiding the problems associated with returning the audio down the lan.

question: how would the timing be accurate if the method of sending (MIDI) and receiving (audio) information is not only different but also decoupled (by design)? there is nothing like an ADAT wordclock for MIDI or a MIDI (beat) clock for ADAT.

somewhere in the chain (at least on the *track output* of the sequencer) MIDI is involved not beeing able to send 2 informations at the exactly same time - possibly VE PRO does this *serialization* better as MoL, i don't know.

but maybe just i still don't get the point - VE PRO sending both over LAN actually would allow latency compensation on the host, but also using ADAT for audio return would require some latency compensation due to buffer settings.

christian

Currently in server/client mode, as far as I know, midi isn't used. Its some kind of vst/au data stream that is timestamped. What I'm proposing is we still utilise that stream so that sample accuracy is maintained but with one of two modifications if possible:

1. Only the neccesary header data thats timestamped is returned to master server. Omitting the dense audio data from the LAN but sending it to the client soundcard. Thus maintaining the latency feedback loop to the master. This timing data will have to incorporate the extra buffers required to send the stream thru the client sound card.

2. Leaving the entire data flow as is, ie audio data is returned down LAN - in server/client mode but...addtionally, copying the audio data stream to the local client soundcard whilst incorporating the neccessary adjustments in the return back to the server to compensate for client soudcard latency. Then you can just mute or turn down the host return.