AmpliTube Version 3.7.1 Now Available! Optimized: 30% to 40% less CPU & RAM

[Dr.Gunjah]

I wonder if Guitar Rig also adds latency but just doesn't report it. Any way to truly verify this?

I don't know what all of this is but GR, Schuffam and AT 3.7 report NOTHING in reaper. They work fine

If I add an instance of any IK single, I get reporting and I can hear the difference.

In Reaper... You are hearing it because of the rounding up, not because of a mere 7 samples of properly-reported latency. Have you reached out to Reaper support? All other hosts appear to be handling this minute amount of latency properly reported without a hitch. Obviously we've looked at this and Brian already answered correctly on our part but I'm surprised nobody has stated they've even asked Reaper support/devs about this.
Also, if you are adding Singles during tracking I can understand Reaper's round-up affecting things but in a mix environment with higher buffer settings being typically the norm, wouldn't your host handle reported latency correctly even with the rounding up and everything be perfectly aligned? In Cubase and Studio One it sure does, from experience.

within Reaper it is perfectly aligned too, when the plugins report latency correctly.
I think the latency in the T-Racks Singles isn't much of a problem because you usually use it while mixing and not while tracking.
Though amplitube is a potential "live fx" and such shouldn't introduce any latency at all...

[A.M. Gold]

Why would I reach out to reaper support?

Because in the world of software, it's always someone else's fault, that's why.

That said, though, this rounding up thing is pretty extreme in Reaper. If no other hosts do this, why does Reaper do it?

[A.M. Gold]

Though since we all know this won't happen ( ) ... does anyone have expierence with disabling pdc for single plugins in Reaper ?(via right click on output-> pdc (x samples) -> disable)
I guess we (Reaper guys) might get the old behaviour by using this (?!)

Nope, doesn't work. Disabling it causes the plug-in to register as 0 samples reported but the total delay still goes up by 256.

[wavephonic]

the authorization isn't sticking, I have to re-show it the file everytime I load it, in any daw on xp. anyone else

[hibidy]

Why would I reach out to reaper support?

Because in the world of software, it's always someone else's fault, that's why.

That said, though, this rounding up thing is pretty extreme in Reaper. If no other hosts do this, why does Reaper do it?

Who cares, 3.7 worked right

In know obik uses reaper (well, at least he used to) so frankly I expect at least one person to have tested and checked this. Unless of course the purpose is to work with the horribly un-optimized studio 1/2, then I guess that makes it ok

[kbaccki]

I think the latency in the T-Racks Singles isn't much of a problem because you usually use it while mixing and not while tracking.
Though amplitube is a potential "live fx" and such shouldn't introduce any latency at all...

Monitoring an amp sim while tracking is a perfectly reasonable expectation. Seriously, does anyone actually monitor their guitar DI while recording?

The 256 samples latency in itself is just on the edge of usable for many (most?)... I know I wouldn't mind it much, even with my... ahem.. impeccable timing. Problem is your effective latency for live monitoring through a DAW is much higher higher than the PDC latency.

If you happen to be running a respectable 64 sample hardware buffer (and I'm sure 64 is still considered "bleeding edge" for the majority), then that's ~1.5ms one way @ 44.1kHz... your round trip is just under 3ms. For some hardware, like firewire devices you have smallish hardware safety buffers... E.g., AFAIK the latest Fireface 800 has it's own 32 sample safety buffer on both I and O (I believe)... so add 1.5ms to the roundtrip latency.

Now... that 256 sample latency at 44.1kHz is ~5.8ms... this is a one-time addition to overall latency for the purpose of PDC, right? Add to that the roundtrip latency -- this is ASIO or whatever buffer latency + hardware safety buffers (if any) -- and you're looking at 5.8 + 3 + 1.5 ~ 10ms from the time you pluck the string to the time you hear the output... now we're talking sizable delay!

Shame about Reaper's buffer strategy... but I can understand what they're doing there. They have pretty sophisticated buffering, and the fixed buffer sizes for synching up latent plugs probably makes their complex architecture a bit easier to deal with. Going a bit further into speculation.. if you know ahead of time exactly how big your latency buffers are, you can optimize accordingly. They probably figure: if you're willing to track w/ latency-inducing plugs (in general, a no-no for tracking), then the fixed 5.8ms is something you can deal with.

The question I have goes back to what others have asked... why does AT need any latency buffer at all? Typically required for lookahead and heavy CPU processes... 7 samples is maybe for an onboard limiter module?

[A.M. Gold]

Well if it's actually appropriate in terms of alignment for it to be reporting 7 samples, then I guess it's better that it does. Just sucks that Reaper has to shoot it all the way up one block. Bypassing the 7 sample reporting doesn't seem to change the fact that Reaper adds the extra block of delay, otherwise it could be bypassed while tracking and then added back when mixing/rendering.

[kbaccki]

The bypass not actually bypassing sounds like buggish behavior... certainly worth following up w/ them. Otherwise, I agree, a reasonable workaround for tracking.

But I have to admit, that 7 sample buffer is bugging me now... what's happening in those 7 samples?!?

[A.M. Gold]

I haven't tried to use a 3rd party tool to check delay (or maybe do it through the s/c interface?). When you bypass the plug-in instance reporting it shows 0 samples reported/256 added. It's possible the latter is actually wrong and Reaper isn't adding any delay when it's bypassed.

[dimitar]

I always thought there is something with the picking attack with some amp plugins. Maybe the hidden latency is the problem. Amplitube shouldn't introduce any latency at all! But using impulses for the cabinet-speaker emulation is hard to make zero latency convolution loader, or at least it was not that easy.

[hibidy]

Am I really the only one who understands this........

Who cares, 3.7 worked right

Not to mention every single version PRIOR to that

[A.M. Gold]

Am I really the only one who understands this........

Who cares, 3.7 worked right

Not to mention every single version PRIOR to that

The bottom line is they changed something and they don't much care about us because we are only the users of one DAW. We are now supposed to "reach out" to get Cockos to redesign Reaper's entire approach to dealing with latency for all plug-ins.

[paterpeter]

Maybe IK could add a switch to AT to optionally return to the "legacy" behavior.

[Dr.Gunjah]

Am I really the only one who understands this........

Who cares, 3.7 worked right

Not to mention every single version PRIOR to that

If I understood correctly, 3.7.1 does report latency right while any version before had latency too and just did not report it.
That's at least what Brian stated.

I wouldn't say it's correct behavior when a plugin has latency but does not report it.

[Dr.Gunjah]

Though since we all know this won't happen ( ) ... does anyone have expierence with disabling pdc for single plugins in Reaper ?(via right click on output-> pdc (x samples) -> disable)
I guess we (Reaper guys) might get the old behaviour by using this (?!)

Nope, doesn't work. Disabling it causes the plug-in to register as 0 samples reported but the total delay still goes up by 256.

hm... I also can't find a global pdc disabling button anymore in Reaper 4... so how are we supposed to use the "workaround" ?