Closed kevontheweb closed 2 years ago
Hi Kevin, thanks for finding this bug. I think there are two reasons that cause HQ mode different than the normal mode. First, you mentioned that there is a filter caused "low-end null issue". I do have a low-cut filter that cuts frequency under 20hz(which barely affects the sound). However, in HQ mode, the buffer is 4 times larger than the normal one, so I guess the low-cut filter frequency was also multiplied by 4 and became 80Hz. So that's why there's a drop in the low-end while you turned on HQ mode. The second reason is probably the phasing issue. I haven't fully tested yet, but I think there is a delay in HQ mode while you mix your original sound there will be a phasing problem. I'll try to find out and fix the bug ASAP, thanks anyway.
Hi, I made a new release here: https://github.com/jerryuhoo/Fire/releases/tag/v0.9.8 Does it solve the problem in your case?
Hi, the phasing on the mix knob is (at least to my ears) gone, there is still phasing if I use reapers built in mix knob but that's ok if fire's mix knob works.
The mix knob is a bit strange though. If I add all 4 bands with no effects on them then turn the mix all the way down, the sound is different from when bypassed. I would think that the sound should be identical to the dry sound when the mix is all the way down. (this only happens when the multibands are being used). This problems goes completely away when I change my buffer size and stop and play again.
I think the issue is now fixed and its just stability maybe? Fire also causes Reaper's GUI to freeze up when open. I will try to test this in another DAW as well.
here is the result of a null test with 2 instances of fire running the test1 preset that I have attached (its all the bands with 50% drive on arctan function) one instance is running at 48kHz and the other is running at 96kHz
Pleae let me know if I should open a different issue for the this, but I think it still relates to the sample rate stuff.
Hi, I tested it with the multi-band mode and find this serious bug. I messed up the global mix control and the band mix control. I will re-release v0.9.8 and see if it fixes your environment.
https://github.com/jerryuhoo/Fire/releases/tag/v0.9.8
For the GUI part, I don't have Reaper to test. But that happened in Logic Pro. The frozen part is the distortion graph(top right) and when you start to play the audio, it stops freezing. Is that right? You can open another issue for this but it may be a little difficult to fix. Because when you turned on "S" mode, which means the drive will automatically drop down according to your input value. So it might not be able to display the first time you open the plugin. But I will try anyway.
when you start to play the audio, it stops freezing. Is that right?
^ This is true for reaper as well, but I don't think it is too major. Maybe there could be a button to disable the spectrum analyser?
For the global mix control, it is still weird. When I turn the mix all the way down with the multi-bands all I hear is the high end here is a video (I had to zip for file size limits)
The first part of the video is showing the strange mix knob behaviour. It seems to be an issue with the highest band and the mix knob because the issue is less prominent when the highest band is disabled.
the null test starts at 2:20, I used the exact same settings on 2 tracks. when the plugins are set the same they null but when HQ mode is active they do not null.
Hi, thank you so much for the video. For the first bug, I thought I had fixed it in v0.9.8, but it still appears in your situation. That's really weird. Would you mind trying to delete the plugin completely and recopy the plugin to the folder? And then, in the DAW, rescan the plugin and see if the bug is still there. (I know the reason. The two versions you downloaded are all v0.9.8, so the DAW won't replace the old version) The second null test: the reason that the two tracks sound different is because of the "S" mode, which will automatically decrease the drive value. The sound changes for some reason when doing oversampling. If you turned it off, they might sound similar. I don't know if it is a feature or a bug, but I will look into it.
I deleted the old Fire, and copied over the new one again, as well as cleared the cache and rescanned my plugins.
I didn't understand how the S mode worked, but I do like it (especially on the single sine mode), so I would call it a feature 😄!
After disabling the L and S modes for each band, it now nulls perfectly with a dry version of the signal when the mix is all the way down! (tested with white noise this time for full spectrum test). So I would say that the mix knob works as expected with the S and L modes disabled.
The phasing on the mix knob is back, though ☹️. I also tested the BYOD plugin by ChowDSP (open source). It has phasing in the minimum phase mode, but not the linear phase mode when automating the dry wet control. This might have to do with using FIR/IIR filters. FIR filters have linear phase, but IIR filters cannot have linear phase. Which filters does Fire use? If minimum phase IIR filters are being used, this may be ok as long as it is indicated in documentation that the plugin is minimum phase and the mix knob may introduce phasing.
The normal and HQ modes in Fire still do not null. The HQ mode has noticeably more high end. This could also be ok, so long as that is made known in documentation. I came across a similar issue in the ChowCentaur plugin (also open source) and the developer said that it had to do with the filters that were sample rate dependant, this causes the filters to all have higher cut-off frequencies when oversampling is used. The dev did not fix this (as far as I know) but in a newer plugin BYOD they updated the ChowCentaur oversampling method so that this is no longer the case. The BYOD plugin does not null perfectly when testing 1x and 2x oversampling, but it still nulls to around -78dB which is nearly inaudible.
Here is a video showing that the normal and HQ modes do not null each other even with the L and S modes disabled. The second half (1:08) of the video shows the phasing back on the mix knob.
I did a test and here's what I am going to do.
For multiband mode, we cannot avoid phasing(after the multiband process, the signal is different from the original signal). But I can avoid phasing on the global mix knob. So when mixing dry and wet signals, the dry signal should be processed after multiband frequency division so that it won't cause the phasing issue when the mix knob is turned to 50%.
Sounds like a good solution! Thank you for all the work!
I just released v0.9.9 v1.0.0 and fixed a lot of bugs. Hopefully, it won't cause any new bugs. 😂
https://github.com/jerryuhoo/Fire/releases/tag/v1.0.0
Thanks for this excellent open source multiband saturator! It has a great interface and is a pleasure to use.
One issue I have come across in my testing is regarding phase.
When the HQ mode is active, the mix control causes a lot of phasing that is not present in normal quality mode. The effect also sounds slightly different when running at 96kHz and when running at 48kHz. When doing a null test between a 96kHz rendered file and a 48kHz rendered file with the same plugin settings, it seems to be mostly low-end left when the plugin is in normal quality mode and the plugin does not null very well at all in HQ mode, so there are some phase differences between sample rates. This doesn't happen with FreeClip (by Venn Audio). Maybe there are some filters or other operations that are sample rate dependent that are causing these issues when the HQ (oversampling?) mode is active and when the plugin is used at different sample rates.
Tested in reaper 6.61 at 48kHz and 96kHz (128, 256, 512, and 1024 buffer sizes) using the arctangent clipping modes in FreeClip and Fire for comparison tests (not using the multiband features for the null test). These null issues at different sample rates are apparent in the other clipping modes as well, with the low-end being left.
(it also seems to make reaper's GUI freeze sometimes when the plugin is open, but I can open another issue if that problem persists)