@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 !
@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 !!!
⌠not here is another discussion! there is a problem and it is talked about a lotThis 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.
4 Likes
But in this config you are measuring qc as audio interface via drivers comunication.
And this doesnât rapresents the behaviour of qc itself
Or
Are you Shure that qc connected via USB has the same behaviour as standalone?
For me no.
Discussing, yep
2 Likes
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.
2 Likes
@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 
I drove a 1989 Opel Senator in the 90s and I loved it.
3 Likes
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. 
3 Likes
Good measurement method
1 Like
More appropriate place for the current stream of information. Moving there would be just fine