Expanded Impulse Response length

Or out of space

I have 24,3 GB available. You could fit a few long IRā€™s in the QC

Yep, i think the same, but i donā€™ t know future plans of ndsp

After doing some extensive IR recording and captures on the Quad Cortex these last couple of days, I definitely hear a difference in the QC captures or IR due to the 21ms being too short.
The symptoms are the same whether it is an IR or a capture (I suspect captures are truncated to 21ms too)

Itā€™s less apparent for ā€œimmediate soundingā€ amp heads or cabs but obvious on gear that has a ā€œbloomā€ quality to them (pretty subjective words in quotes here).

My open back custom cab with 2x12 has its natural low end missing on the IRs imported (and trucated) on the QC. Btw, it is not room generated low-end, itā€™s really the cab doing its thing.

My mid gain amp heads with a bit of sag sound the same as above.

I really believe it is as wrong to say 20ms is all we need for replicating a piece of gear as it was when people said 320 mp3s were just as good as CDs (remember those years ?).

I do encourage people to test their IRs with clean or mid gain and play around with the IR length (not on the QC but on a IR loader in order to play around with the length/truncation).

As a quick footnote, NDSP plugins carry longer IRs which makes them sound a lot better (and a lot more amp-like) than the QC.

I hope NDSP make the decision (because thatā€™s all it is) to allow longer IRsā€¦

Yup, increasing length (i.e. number of filter taps) allows a FIR filter to have greater frequency-domain precision - not to mention the ability to model longer time-domain behavior. Human hearing perceives pitch logarithmically - thus, this increase in precision is most audible at low frequencies. (Pardon abbreviated summary; on mobile. Check out some introductory DSP textbooks for more detail!)

Each of the two SHARC DSPs in the QC has a 1024-tap hardware FIR filter accelerator, which is probably used for the IR loader. (See this Analog Devices press release.) In order to increase FIR length, youā€™d need to rewrite the IR loader to use general purpose DSP instead. Not infeasible as far as I know, but not quite a trivial change either.

Itā€™s likely thereā€™s also a memory limitation in play; Iā€™m unfamiliar with this specific SoC, but upon cursory inspection it appears the SHARC can only directly address a subset of RAM, which is very normal. Again: there are ways around this, but itā€™s not just a matter of turning up a variable. (Offloading an IR computation back to the ARM would be particularly hilarious!)

IIRC Fenderā€™s TMP has no such limitation as itā€™s doing everything on a general-purpose CPU anyway - no hardware DSP. (My memory is notoriously unreliable thoughā€¦take that with a block of salt.)

(EDIT: fixed markdown formatting)

@compucat ,
Thank you for that !

Dammit, shoulda looked at the SHARC datasheet before postingā€¦
As you say, itā€™s an understandable clunky/backwards fix to use the general ARM CPU for IR and capture calculation/computationā€¦

I guess the only solution for now (for me) is to double up the IR blocks and use each block with 21ms portions of the IR (with a 21ms delay on the second one)ā€¦

Trying to find solutions hereā€¦

1 - Could this fix be implemented on a new IR or Capture block (that block being an ā€œinvisible to the eyeā€ double block) ?

2 - Less development here : stop the IR upload limit (1024 actually) and add a start truncation knob to IR blocks. Let the user decide on the starting point and delay inside the IR block. That way the user could use whatever portion of the IR (in a double IR block for ex).

Iā€™ve got a feeling weā€™re going to be stuck with ā€œwhat you bought is what you gotā€ but Iā€™d love be wrong on this one.

Anyways, thanks @compucat

Both are likely possible, though the second would make for a somewhat obtuse UI. Given the design ethos of QC (make UI fast/intuitive to avoid disrupting creative flow) and the rare use cases for IR trimming, I donā€™t think it makes sense to add that as a feature.

I misspoke earlier - after a more careful read of the datasheet, the SHARC cores can access more of main DRAM than I initially thought. See page 12 - SHARC instructions must be located in specific locations, but data can be accessed from most of system memory - with some latency compared to data in SRAM cache.

There are a few viable solutions here - finding one that is sufficiently efficient and doesnā€™t create resource conflicts will be the trick. Iā€™d remain optimistic.

1 Like

I too sincerely hope for this feature.
21ms is far too short.
Most IRs are offered at 200ms, so they need to read at least 200ms to perform at their best.

I wonder why the NDSP focuses on this feature at all.
Frankly, I would like to see this feature implemented even if it means reducing the number of IRs that can be saved.

The length of the readable IR is definitely one of the factors that makes QC look cheap, and is a reason for many people not to buy it.

Hey Neural DSP Team, please update us on this subject. Can this be included on a future update?

You definitely can use Celestion IRs, thatā€™s all I currently use (my main one being the G12M closed 4x12 mono ā€œHi-Gain All micsā€, which obviously is a blend). Sounds great.

Today Headrush Flex prime in house.

2048 irs sounds fantastic, they seems more organic during playing!

We Need at least 42ms neural DSPā€¦ and not anhecoic ir.

Also.
They sounds goodā€¦

ā€¦but they can sounds Better on 1600ā‚¬ of unit!

2 Likes

Just adding a comment to keep this recent. Would love to get any info even on whether this is a topic of interest to neural. Would love to be able to use longer IRs.

1 Like