QC numbers report (latency, send levels, etc.)

Hello everyone!

I’ve noticed something slightly odd happening. I was optimizing my presets to not use row 3 and felt that before that change my preset sounded better. It turns out that as soon as I link the first row to the third one, even if the third one doesn’t have any blocks, output level goes slightly up. I don’t know if it’s just the output level, I haven’t measured it. You’d expect the output to be exactly the same whether row 3 is connected or not, but it’s not. Has anyone else experienced/measured this?

Neural should allow for the complete decoupling of CPU1 and CPU2, so that they can be used as separate “units”, muting two rows when the other two are not in use. You loose long signal chains and bleed functions, but I rather have two chains of blocks that are in the 6ms range than one long chain of blocks that’s in the 12ms range.

Then one cpu could be used for FX loops and other hight latency applications, while the other cpu is for super tight riffing.

1 Like

guys I find it absurd that blocks add latency even when they are not turned on! and I find it absurd that a machine like the kemper which is objectively a much older machine doesn’t have this problem and I find it much more absurd that NDSP hasn’t already solved it as well as other problems such as the unity gain of the effects loops! and to close I say that a patch with 10 blocks divided between raw 1 and raw3 gives me 9ms of latency!!! for me it is unacceptable

4 Likes

Davide, for now you can use row 1&2 and 3&4 losing 1 block for splitting (serial splitting 1 to 2 you lose last block on row 1. )
You have 10+11 blocks (1+2) and in parallel 10+11 blocks (3+4)
If you Copy the amp in 1&2 to 3&4…you have a Monster with 6ms…with a lot of solution effects.

Meantime you wait (but i think you have already sold the qc) for a latency update, in reality…where Is the problem ?

2 Likes

@DavideAru I can report for a fact, the Kemper has the same attributes when it comes to latency that the QC does. I did several tests between the two when I first received my QC. Even with blocks turned off, the Kemper had increased latency. In my tests, when I streamlined both the patch on the Kemper, and the preset on the QC to just be an amp profile and cabinet, the QC actually had less latency than the Kemper.

3 Likes

@sleiweke hello strange because I did a lot of tests and for me with the same number of blocks kemper has much less latency, also because in kemper if the block is deactivated it doesn’t add latency which QC does instead! in QC the block adds latency even if it is not turned on ! this is what it turns out not only to me but also on other tests done by other people.

1 Like

@Niksounds I think you’re wrong because 10 blocks on raw 1 and 2 I can’t put them because the cpu can’t do it I have to distribute boobies raw 1 and 3! this is what happened to me trying it. thank you

@DavideAru Perhaps something has changes in the OS of the Kemper or the QC sense I did my tests. I’m not sure. It was right after the QC came out. I ordered mine very early on. I know there’s a setting in the Kemper that gave a constant latency setting to all presets no matter how many effects blocks a patch contained. Could have something to do with results. I’m just reporting what I personally found in my tests.

Put in parallel on 3+4 cloning the amps

Best.autocorrect.ever !
:laughing::rofl::joy::sweat_smile::crazy_face:

1 Like

@Morphire :joy::joy::joy::joy::joy::joy::joy::joy::joy::joy::joy::joy:

Routing 1+2 and 3+4

@Niksounds ok i understand but did you put 10 blocks on raw 1 and 2 and 10 blocks on raw 3 and 4 ? here 9.25 ms!

Yes,
As noted and clear for all

But with my routing we have a lot of solution at 5/6ms, waiting future patches.
Good “proseguo”, bye all

Are you sure this is correct? I believe that for example on the Helix, all the DSP required for the blocks in a preset are pre-allocated when the preset is selected, regardless of whether the block(s) are bypassed or not. I would think that might translate, at least generally, to the same amount of latency regardless of block state, but maybe not. Would really like to see someone else test your results across other devices.

As always I am hopeful that Neural will continue to optimize its code with a priority on low latency wherever possible. I think the focus should be on reducing overall latency, regardless of bypass state, so users don’t have to concern themselves with which blocks are on. Excepting perhaps complex and special effect blocks that require extreme amounts of processing time.

1 Like

If blocks had no latency when bypassed, then when you toggle them between bypassed and active, you have to deal with either extra or missing audio.
So it makes perfect sense to have the block have the same amount of latency in both states for the QC.

4 Likes

@tomfs from the tests that I have done with the kemper I have not experienced any loss of signal when switching the block on and off, and the kemper when the block is off does not add latency

At this time i think some people whining for nothing… 15ms on Kemper and two loops engaged

2 Likes

@Niksounds I did the tests! and if you’re happy we’re fine! Bye