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!
1 Like