CorOS Version: 4.0.1
Describe your issue:
The FX Send 1 & 2 gain values displayed on screen in the I/O Settings and FX Loop block settings are incorrect.
Steps to reproduce your issue:
- Set the Output 1, FX Loop 1 Send, and FX Loop Return gains to zero in the I/O settings screen.
- Create a new empty preset
- Change the input block of the first row in the new preset to be one of the USB inputs.
- Open a DAW and route a channel output to the USB output select in the previous step.
- Add a test signal generator in the DAW channel to output a sine wave to the selected USB output.
- Open the I/O settings screen to check the OUT 1 level meter. At this point, the empty first row should be passing the DAW signal straight from the USB input to OUT 1 with no change in gain. Adjust the output level of the test signal in the DAW to make sure you have a about 10dB of headroom on the meter.
- Note the OUT 1 meter level in I/O Settings.
- Using a 1/4 TRS to TRS cable, connect the FX Loop Send to FX Loop Return
- Add an FX Loop 1 block to the first row of the preset and make sure the block gains are all set to zero and the mix is 100%.
- Make sure the block settings are correct and the FX loop is active and open the I/O settings screen again to note the OUT 1 meter level again.
I expected this to happen:
When I perform the test above, I expect a gain setting of 0dB in both the effects loop send and return to result in unity gain through a jumper cable (within +/-0.5dB to account for manufacturing tolerances, the loss in the cable, etc.)
My expected result was a matching metered input level on the USB input and the OUT 1 level within a reasonable tolerance.
My observation is that an FX Loop send level of 0dB results in a boost of about 4.5dB and conversely, setting an FX Loop send level of -4.5dB achieves unity gain within +/-0.5dB.
I have tried the following things:
- I have tried multiple different jumper cable in the FX loop to rule out faulty cables.
- I have tried using all of the different USB inputs to inject the test signal to see if it made any difference (it did not, which is expected).
- I have tried injecting the test signal externally through Input 1, using that as the row input in the test preset instead of a USB Input with the DAW in order to verify that an empty row doesn’t have an inherent effect on gain without any FX loop blocks (as expected, an empty row has no effect on gain) and also to make sure there isn’t a difference in the gain reference between the Input 1 and OUT 1 (there is no gain difference).
- Verified that the RET 1 and RET 2 metering levels matched the OUT 1 levels in the test preset to make sure there wasn’t a difference in the metering or referencing between the two.
I propose the following changes to the current behavior:
- Change the displayed value for the FX Loop send gain controls so whatever underlying value currently displays -4.5dB will now display 0.0dB for the same underlying value. This way, whatever is saved in existing preset fx loop blocks and I/O settings for system backups will not be affected by a breaking change. With this approach, the user doesn’t need to do anything to preserve their existing presets gain levels, but they will see the corrected gain if they view them after the fix.
- Change the factory default FX send gain level from whatever the current underlying value which displays 0.0dB to the value which currently corresponds to --4.5dB. For most users, unity gain across a jumper cable is going to be the expected behavior. The current behavior is likely to cause confusion and the current volume boost increases the likelihood of clipping.
- To get perfect unity gain across the FX loops on my particular device, I also had introduce a gain setting of -0.3dB on the FX loop RET levels in addition to the send level adjustment I already mentioned. If there is a small, known offset in the displayed return gain level, that might also be worth fixing. However, if this just a result of manufacturing tolerances, which I think it is, then this small difference of a few tenths of a dB is certainly reasonable and too small to matter for practical purposes.
I hope this is helpful and I think changing the current behavior would make things easier for most users in the future.
I also wanted to acknowledge that I have read about a nearly identical issue on the full-size Quad Cortex, but the mini QC is my first hardware from Neural DSP, so that’s all I had to test. It is likely that since nearly identical behavior has been seen on the full-size QC, that this is a software/display bug which affects both.