194,151 users have contributed to 42,912 threads and 257,926 posts.
In the past 24 hours, we have 1 new thread(s), 13 new post(s) and 79 new user(s).
Yeah, that's kinda what I figured. Well, thanks to VSL for at least making the option available since I doubt Apple is going to redesign the AU specs with multiple MIDI ports in the forseeable future.
I'm going to try it with MOL and see how much difference there is at the 0 setting in VEP.
Did a little testing tonight with outside vs. inside midi latency with some interesting results:
I have been using Bidule to house a large library of sounds in several instances of Kontakt on a slave computer and then bussing via lightpipe to my main computer using DP. My buffer setting on both the slave and main computers is 128.
When I loaded up the Kontakt template into VEPro and tested the latency using a setting of 2 buffers on the VEP interface, my recording of a percussion sample was in virtually the same spot as when I recorded it using my old setup in Bidule.
I recorded at 1 buffer and 0 buffers and each time the recording was a 150 samples or so less latent. I also recorded using the VEP MIDI and of course that one was dead on.
I am relieved that even using VEP at the highest latency setting, I will see similar performance to my current setup. And by moving to 1 or 0 buffers on the VEP interface, I can actually see much better latency than my old setup even when using external MIDI.
Nice job VSL team!!
(now if we could get a MAS version for us DP users so we can have multiple MIDI ports within the plugin I think I would wet myself) [;)]
That's excellent news!
Since you can set up many different IAC or DP output ports, you can use multiple midi ports within a single instance of the AU VEPro plugin. Not as slick as the VST implementation with all those internal midi ports available, but a nice improvement.
No, the "plugin MIDI" is much faster (totally precise to be specific), but there wasn't any extra latency using external MIDI (MOL) compared to the setup I had before using a sound card and MIDI.
Basically, even at it's highest latency setting, VEP is at least as fast as my old setup.
That's kind of surprising. I did a similar test here and had noticeable latency with DP 5.13 and VE Pro (on the same machine). I set up a click sound in a kontakt 3 instance hosted in VE Pro and assigned it to Omni input. In DP I made a quarter note track for the click and played it back with the internal click activated. When the track played through VE Pro's plugin midi, the timing was dead on (at 0 buffers). Using OS X IAC, the latency was noticeable. Using DP's internal Inter-application midi, the latency was about the same as IAC. When you raise the buffer on VE Pro's instrument channel, everything starts drifting further behind. It's pretty easy to compensate for this in DP using the midi offset plugin on your track. I found that 2600 samples earlier would line everything up perfectly (using inter-app midi or IAC). I could try MOL also, but it's pretty much tied up with my giga machine. btw - my DP buffer is set at 512. This setting has a lot to do with your ve pro results no matter what midi method you use.@magnumpraw said:
No, the "plugin MIDI" is much faster (totally precise to be specific), but there wasn't any extra latency using external MIDI (MOL) compared to the setup I had before using a sound card and MIDI.
Basically, even at it's highest latency setting, VEP is at least as fast as my old setup.
I think you guys may be misunderstanding what I'm saying. I'm talking about sounds hosted on a separate slave computer. If you are testing with sounds housed on the same computer as your DAW, of course they are going to be faster than VEP (unless you set VEP to 0 buffers). This is becase you are only dealing with 1 audio buffer--the one outputting to your sound card.
When using an external computer and bussing the audio back to a DAW computer via physical audio connections (ie:lightpipe) you have 3 buffers that slow things down.
1. the output buffer on the slave
2. the input buffer on the DAW comp
3. the output buffer on the DAW comp
This makes decent sense that when I set VEP to 2 buffers, I'm getting the same latency as I was before because I'm in effect adding buffers 1 and 2 (buffer 3 will always be present).
Cheers
@Tripi said:
I found that 2600 samples earlier would line everything up perfectly (using inter-app midi or IAC).
So does this mean that when you bounce to disk or do a real-time record pass at the end of your project---that the resulting audio will line up perfectly with the midi?
I'm just trying to understand the implications of VEPro latency, besides the obvious bothersome monitoring delay if latency is high.I did my own testing in DP7 using your method and found variable latency from note to note using VEPro internal midi plugin. Sometimes spot on, sometimes 100-200 samples early or late at zero buffer in server setting, and obviously delayed further at 1 and 2 buffer settings.
Thanks for any further insight!
@charlesparente said:
I did my own testing in DP7 using your method and found variable latency from note to note using VEPro internal midi plugin. Sometimes spot on, sometimes 100-200 samples early or late at zero buffer in server setting, and obviously delayed further at 1 and 2 buffer settings.
Using the VEPro plugin connected to VEPro Server, MIDI timing is completely sample accurate. Using any MIDI bus or network solution, such as IAC or MIDI-Over-LAN, you can never have any sample accuracy. It will depend on many things. VEPro tries to schedule incoming MIDI events as good as it can, delaying them according to when they are received, to line up at the appropriate point in the audio buffer.
Maybe I'm missing something, but if I open an instance of K3 in DP6 and one in the VE PRO server with identical patches and the latency delay compensation activated in DP, there is definitely a difference in timing. The VE PRO instance is noticeably behind the DP instance not only on input but also on playback. The difference gets larger as the buffer is adjusted for VE PRO. MOTU said that as long as the internal instance is working with DP than it can't have anything to do with the internal settings in DP. Is there another reason why this wouldn't be working?
@Tripi said:
I found that 2600 samples earlier would line everything up perfectly (using inter-app midi or IAC).
So does this mean that when you bounce to disk or do a real-time record pass at the end of your project---that the resulting audio will line up perfectly with the midi?
I'm just trying to understand the implications of VEPro latency, besides the obvious bothersome monitoring delay if latency is high.I did my own testing in DP7 using your method and found variable latency from note to note using VEPro internal midi plugin. Sometimes spot on, sometimes 100-200 samples early or late at zero buffer in server setting, and obviously delayed further at 1 and 2 buffer settings.
Thanks for any further insight!
Yes, this will keep everything in line. It's like telling DP to start playing the midi on the track 2600 samples early so that it compensates for the return latency. The TIME SHIFT midi plugin hardly takes any cpu power to run, so I just duplicate it on every midi track (going to VE Pro). Keep in mind that 200 samples is about .004 seconds (at 48k sample rate). 1 frame of film is about .04 seconds (at 24 fps), so 100-200 samples off is probably not going to affect hitting a moment in a film score.