Latency "solved"

@thomasotto Exactly ! but you also think like me that such a machine cannot have these limitations! for me it’s unthinkable and I didn’t use the loops because as you know they have a huge unity gain problem! In short, I thought I had bought a Ferrari and I find myself with an 1989 Opel …broken !

I hope so @Ringo !

Otherwise we’re stuck with a QC MK1 on our hands when the MK2 comes out with the hardware fixed (if it’s even possible!)

We might just be in a time where the tech (the processor) isn’t ready for 4 rows of blocks under 5ms !

@Ringo I hope so for them because otherwise these are the extremes for a class act!!!

@thomasotto it would be enough to make a firmware with buffer size control like in the DAW! someone had suggested it here on another thread always on this issue

With gear (and the years) I’m kinda used to seeing the limits very quickly (even with the analog stuff).

Although the QC is the first modeler that makes me smile when I do a capture of my own analog gear, it still has limits…


You mean this ?

Or even better : an advanced menu where one would choose the buffer size (the latency).
If audio cracks, slim it down or up the buffer.
Basically like in any recording studio.

From here ?


Probably row 3 adds latency synchronizing the two dsp.
I think sw related.
How do you measure the latency guys? Can you explain?

@thomasotto I think it sounds good too! but the latency limitation does not allow me to use it! because playing in time is fundamental and Qc doesn’t allow you to do it! and I can’t professionally have such restrictive limitations in building a patch and be afraid of having placed too many blocks that generate too much latency! I keep saying that for me it is unacceptable for a last generation pedal board! and for information my patch which generates 9ms of latency only occupies 50% of cpu !!!

@thomasotto exactly! like a computer! like QC pretty much

@thomasotto no :grinning:… not here is another discussion! there is a problem and it is talked about a lot

This is how I do It :

  • QC as the only audio interface in my macbook via USB.
  • Set USB 5 on the QC input, USB 7 on the Output.
  • In Logic Pro, I use the IO Plugin (used to Ping and measure external hardware latency, it’s like a console insert, doesn’t take into account the QC roundtrip latency)
  • The IO plugin returns a sample number which I divide by the sample rate (48000) and then multiply by 1000 : (number of samples/sample rate) * 1000 or 1000 / (sample rate / number of samples) if you prefer

Is this a feature request at this point? There are already posts about this. I feel like it would be more valuable to consolidate your basic data @thomasotto, add it to an existing request, and then solicit people to vote to raise the attention for it.

As it is this is less about a feature request and more becoming like a gripe session which isn’t the point of this category.


But in this config you are measuring qc as audio interface via drivers comunication.
And this doesn’t rapresents the behaviour of qc itself


Are you Shure that qc connected via USB has the same behaviour as standalone?

For me no.

Discussing, yep


I feel like it would be more valuable to consolidate your basic data @thomasotto

Already did that here

add it to an existing request

Already did that here

As it is this is less about a feature request and more becoming like a gripe session which isn’t the point of this category.

For me it was more about helping out and finding explanations & solutions than joining a “gripe session”

I’m out.


We can discuss it here if you want…


@Niksounds @thomasotto I measure like this:

  • I plug the guitar into a Radial Shotgun Input
  • Shotgun Output 1 to Neve preamp then to Pro Tools
  • Shotgun Output 2 to Quad Cortex to Neve preamps to Pro Tools

I play various “hits” on different strings and also tap with a screwdriver on the pick ups poles so I obtain supersharp transients.

Press record of both tracks then measure the timing differences

Doing like this you have the true latency that the QC or other digital machines make VS the analog DI signal :wink:

I drove a 1989 Opel Senator in the 90s and I loved it.


You make a solid point. Are there other existing feature requests for lowering latency? The title on this one is a little confusing due to the use of “solved” in the title, although it is aspirational and sums up the ultimate goal nicely. That said, at the very least the request could use a proper description, even if it is short and sweet, such as “minimize latency on QC across all paths, splits, block, loops, and global EQ usage”.

Latency is clearly an area of legitimate concern but no cause for panic. Just something that has to be constantly measured and reduced as the QC’s codebase matures. I am sure the developers are working towards it. It is one of those pieces of core functionality that isn’t as exciting as many of the other bells and whistles but is of vital importance to the QC’s usability.

I can see the QC’s potential and just hope reducing latency remains a priority over its entire lifespan, or at least until it is no longer of any consequence. I have some fairly well populated presets that I am happy with that present no showstoppers regarding latency.

Maybe this is one of those feature requests that should never be closed but used as a way to track positive milestones as execution time improves. More of an overarching goal for the device rather than a typical feature request per se.

This QC still goes “vroooom” when you hit the pedal. Just needs a little adjustment so turning on the air conditioner or windshield wipers doesn’t bog it down. It’s a sleek machine. :grin:


Good measurement method

1 Like

More appropriate place for the current stream of information. Moving there would be just fine