|
Post by kcatthedog on Oct 27, 2019 12:44:33 GMT -6
Sideshow, I thought it was down around .3 ms, did you experienced higher?
|
|
|
Post by Drew @ UA on Oct 27, 2019 17:06:41 GMT -6
Hell, I'm too impressed with Don's VO skills to notice the conversion!!
|
|
|
Post by Guitar on Oct 27, 2019 17:44:09 GMT -6
Hell, I'm too impressed with Don's VO skills to notice the conversion!! the Fig Picker bit really got me
|
|
|
Post by BenjaminAshlin on Oct 29, 2019 14:23:08 GMT -6
Sideshow, I thought it was down around .3 ms, did you experienced higher? RTL should be the same on all computers as its written into the driver. Apollo RTL is around: 64 ~ 5.5ms 128 ~ 8ms But this get higher if you are using IDC. Its good but RME can handle a bit more load at that 64 buffer.
|
|
|
Post by kcatthedog on Oct 29, 2019 14:33:30 GMT -6
Interesting, I thought I had seen it stated lower on ua forum?
Anyway, no offence, but a bit academic? One needs to decide if you want to track with Ua plugs, you need an apollo, it you want lowest rtl, it’s not apollo?
RME makes a great interface and drivers, no question!
|
|
|
Post by Drew @ UA on Oct 30, 2019 10:20:30 GMT -6
Why you'd want to be constrained to running your DAW at a 64 sample buffer baffles me.
The Console workflow allows mine to stay parked at 1024 and I can mix as I go, adding whatever plugins I want in the DAW as I continue to track. This feels like the SSL/Studer workflow that I came up on.
|
|
|
Post by Guitar on Oct 30, 2019 12:41:24 GMT -6
Why, for running native software instruments, of course. For example. probably the biggest reason to run a low buffer.
|
|
|
Post by soundintheround on Oct 30, 2019 12:47:47 GMT -6
I still have a Silver Face Apollo Quad I use! But it's hooked up permanently to some old reverb units that already sound like crap anyways! I use them for Aux sends mixing in the box.
Alesis Midi Verb 2 Yamaha SPX90II Aria Stereo Spring Reverb A Korg Kaos Pad 2
|
|
|
Post by BenjaminAshlin on Oct 30, 2019 15:39:42 GMT -6
Interesting, I thought I had seen it stated lower on ua forum? Anyway, no offence, but a bit academic? One needs to decide if you want to track with Ua plugs, you need an apollo, it you want lowest rtl, it’s not apollo? RME makes a great interface and drivers, no question! I actually loved tracking vocals and the like with the Apollo. I was very impressed going back and forth from Mac to windows in how consistent the drivers were. I am using more software instruments, 5 years ago this wasn't as much of a problem because i used less ITB instrument. I am pretty sensitive to latency especially with midi drums so 64 buffer is a must. Currently i use an internal RME card. These new interfaces look great though.
|
|
|
Post by Guitar on Oct 30, 2019 15:43:35 GMT -6
Yeaup. Perhaps my favorite thing about Apollo is the software seems bulletproof and if you use "approved" hardware you are almost guaranteed to succeed. That's a whole lot better than what some other manufacturers offer, or should I say fail to offer.
|
|
|
Post by kcatthedog on Oct 30, 2019 15:51:20 GMT -6
Have you tried sending your vi to console’s vi inputs, if so, what did you think ?
|
|
|
Post by popmann on Oct 30, 2019 16:15:07 GMT -6
It's a downright MIDI revival.
|
|
|
Post by Drew @ UA on Nov 7, 2019 10:11:33 GMT -6
Why, for running native software instruments, of course. For example. probably the biggest reason to run a low buffer. Yeah, I do all acoustic recording. But I would just use Virtual Channels back to our Console app.
|
|
|
Post by Guitar on Nov 7, 2019 10:35:50 GMT -6
Why, for running native software instruments, of course. For example. probably the biggest reason to run a low buffer. Yeah, I do all acoustic recording. But I would just use Virtual Channels back to our Console app. How does that work? How much round trip latency would you be hearing for example running a synthesizer plugin?
|
|
|
Post by ragan on Nov 7, 2019 11:55:27 GMT -6
Why, for running native software instruments, of course. For example. probably the biggest reason to run a low buffer. Yeah, I do all acoustic recording. But I would just use Virtual Channels back to our Console app. Isn’t that still subject to DAW buffer?
|
|
|
Post by kcatthedog on Nov 7, 2019 11:59:43 GMT -6
The vi in console add I think about 30-55 samples but you can track with ua plugs on your soft instruments.
|
|
|
Post by ragan on Nov 7, 2019 12:02:57 GMT -6
But if the signal is originating with a native VI in the DAW, routing it to Console app doesn’t do anything for latency, right?
|
|
|
Post by Drew @ UA on Nov 7, 2019 12:12:37 GMT -6
|
|
|
Post by Drew @ UA on Nov 7, 2019 12:15:08 GMT -6
It is still subject to the buffer, but they allow you to process them with less latency.
|
|
|
Post by ragan on Nov 7, 2019 12:21:08 GMT -6
It is still subject to the buffer, but they allow you to process them with less latency. How? By "process them" do you mean using UAD plugins with less latency than you'd incur if using UAD plugins in the DAW? I can't see how the actual response/playback of a native VI would be any less latent if routing to Console.
|
|
|
Post by Drew @ UA on Nov 7, 2019 12:38:33 GMT -6
It is still subject to the buffer, but they allow you to process them with less latency. How? By "process them" do you mean using UAD plugins with less latency than you'd incur if using UAD plugins in the DAW? I can't see how the actual response/playback of a native VI would be any less latent if routing to Console. Correct. it's not, it's just minimized.
|
|
|
Post by ragan on Nov 7, 2019 13:24:09 GMT -6
How? By "process them" do you mean using UAD plugins with less latency than you'd incur if using UAD plugins in the DAW? I can't see how the actual response/playback of a native VI would be any less latent if routing to Console. Correct. it's not, it's just minimized. Ok just wanted to be sure I understood you. So the only benefit in routing native VIs into Console is that if you want to have UAD plugins active on those VI channels, Console will process them with less latency than the DAW would. So the UAD plugin latency is "minimized", nothing else.
|
|
|
Post by sirthought on Nov 7, 2019 15:56:59 GMT -6
Ok just wanted to be sure I understood you. So the only benefit in routing native VIs into Console is that if you want to have UAD plugins active on those VI channels, Console will process them with less latency than the DAW would. So the UAD plugin latency is "minimized", nothing else. That's correct. I don't use a lot of V.I.s but in my limited attempts I didn't think you really felt much of anything. That was using Logic organs. The benefit is adding the UAD plugins to the virtual channel.
|
|
|
Post by ragan on Nov 7, 2019 21:31:53 GMT -6
Ok just wanted to be sure I understood you. So the only benefit in routing native VIs into Console is that if you want to have UAD plugins active on those VI channels, Console will process them with less latency than the DAW would. So the UAD plugin latency is "minimized", nothing else. That's correct. I don't use a lot of V.I.s but in my limited attempts I didn't think you really felt much of anything. That was using Logic organs. The benefit is adding the UAD plugins to the virtual channel. I’m not following what “didn’t really feel much of anything” means here. You mean with various buffer sizes? For me anything abound 256 is unusable. You here and feel a significant delay. Even 256 is pushing it.
|
|
|
Post by kcatthedog on Nov 8, 2019 5:23:03 GMT -6
Maybe ask Johnkenn to send a vi from daw to console and record in daw and confirm rtl , although it would be plug in chain dependent ?
|
|