lkjb QRange

[lkjb]

I added a "thick curve" option which increases the EQ curves size a bit. I'll wait a little time in case some other stuff will be added before I'll release an update, though.

I have one request - could you add 6db filters in there even if just to be used with the minimum phase mode, which is all i'm using.

I thought about that but it would in my opinion over-complicate the user interface. Not from the user's view but depending on the mode there needed to be different options/labels which is quite error-prone in the long run. Also, the question might arise whether 6dB should be added or all filters should be halved (e.g. 6/12/24 instead of 12/24/48). I considered this (as it also affects the peak/shelf filters) when adding the minimal phase mode but decided against it. For 6 dB filters you can use TinyQ but I understand that using a second plugin might not be the ideal solution.

The only thing that slows down my workflow is that the bands aren't color-coded. I always need to double/triple-check which band is which from upper graph to lower numbers section. A different color for each band would be very useful.

Instead of different colors (which is already used for coding the routing) I thought about highlighting the handle/bands if the mouse is over. But as this is a bit of work I'd like to know how large the demand is for this change and if it would even be a satisfactory solution

[sinkmusic]

Hi, Lkjb

I added a "thick curve" option

Thank you for adding a "thick curve" option. Will the thick curve be alias-free, too ?

Instead of different colors (which is already used for coding the routing) I thought about highlighting the handle/bands if the mouse is over.

I also favour color-coded dots/bands, but highlighting the band is good, indeed.

Imho, these eq do have a nice way of displaying the curve/dots, amaking the workflow both pleasing and efficient.

[lkjb]

I went for different band colors instead of highlighting bands so version 1.1.3 adds options to draw the EQ curve a bit thicker and to show colors for used bands. This can be enabled via the settings menu and should be stored in the defaults.

Will the thick curve be alias-free, too ?

All curves should be anti-aliased although my impression is that the anti-aliasing done in WDL isn't as nice as the one done by JUCE for example. This might not necessarily be the framework's fault but could as well be due to me being not acquainted enough with WDL.

[sinkmusic]

Thank you, LKJB.
It looks better wth thick lines, imho, and i like color-coded bands, too
It seems that some aliasing is still present in the curves drawing, but it's a nice update.

[lkjb]

You're right. Having a closer look, the curves are drawn without anti-aliasing although it is enabled in the according function call. I'll see what I can do...

Edit: This seems to be due to the way the curve is drawn so not sure how this can be improved.

[ronaldsifontes]

Este Eq es AMAZING.
Thanks.

[lkjb]

I was made aware of QRange introducing distortion when using higher Q-factor boosts or cuts at low frequencies. Version 1.1.4 fixes this by adding an option to switch process modes. More technical information can be found at this article.

The update can as usually be downloaded here at kvr.

[HansP]

lkjb,
I looked into that, I hope you don't mind if I offer some thoughts about this, I may be totally off, but let me just try.
my english is not good about tech stuff, so that's another area to mess up.
it might even become a different project, and therefor not possible.

what I thought of, is a concept that will not enter each new data buffer with "silence" or cut-off IIR tail. I would like to preserve a tail between two consecutive blocks, esp. as IIR means infinite.
can you imagine some "shadow processing", that has two totally independent machines, one forward, and one back, and each has its buffers and a data management that can preserve and feed us the data that was created in the past (virtualized past for the backwards path).
it would process always two blocks at a time, but shift forward in the loop only for one block per cycle. this block will be used in the place of the normal block of the original algorithm, and is windowed after it was computed, and during computing, it has available the IIR "tail" data from the previous block (all those taps), which makes the difference.
for the backwards path, I think a lookahead can be used so to derive the "future" data, and put these two neighbored blocks together again.

the windowing mechanism would receive blocks that have a higher accuracy because they are derived from an uninterrupted chain of processing forward (I guess this may be possible), and for the backward IIR, a 2-block or 3-block algorithm that uses data from adjacent blocks, though not from the whole chain.
(I didn't draw it on paper, so another guess, we might harvest the data that we use for the windowing, starting from the center of the first block, and ending at the center of the second block.)

if we end up with forward and backward paths having different accuracy, but in sum the best possible, it is yet to see whether this has any detrimental influence on the phase relationships.


if we switch to such a processing mode, the CPU load will probably double or more, but then also, it would be high precision and solve quite some issues.

thanks for considering, and thanks for all these great plugins, I use TinyQ very often, and am totally happy with its precision. it is for me the fastest way to EQ some remaining issues, after having a ton of plugins in the chain already.

[Bojo34]

Thanks, I've yet to try out this one. I've had good use of Luftikus, one of a kind plug to me.

[lkjb]

@HansP: While the forward path can be easily processed without blocks this would lead to an unsymmetrical impulse response as it would be infinite while the backwards processing must be finite. Therefore, the processing would lose its linear phase property. At least with the backwards processing a filter reset before processing a block is needed as the "previous" samples for the backwards processing would have to be from the future. Any change that can be made will increase the latency and is probably not much different from simply increasing the buffer size.

Although I also must say that I spent about two days creating the basic algorithm and took the first implementation that worked. It is certainly possible that other products using this technique use a more concise and efficient processing resulting in lower latencies and CPU usage for comparable results.

[HansP]

I see, just thought perhaps we can "cheat" that time-warp thing for 1 block length, when we do another lookahead to get the data and fill the IIR queue, but deliver to the window only half that block (which has the same size as the full block in the original system). A little different way to use the overlapping.
My hope is we won't get the endless process though, but at least one more block size of tail accuracy, and then perhaps it would be still "lin-phase" enough, as we could apply something like this to the forward blocks also..
Thanks for your reply!

[bass42]

Just discovered this EQ and copied the downloaded files to the respective VST directories in Windows 10.
Trying to open the VST3 plugin in Wavelab 9.5 resulted in an error telling me to better save my work and restart Wavelab, the plugin couldn't be used.

Any help regarding this?

Thank you very much!

[bwwd]

This thing is amazing but theres one major issue with it in FL studio...
When i add it to any channel, 32 or 64 bit version then suddenly my entrire track and all my sounds are delayed by 2 seconds ( !!!!!!!!)
This is very strange, theres huge delay when i press a key to playback any sound from the moment i add this effect to my fx chain in mixer.
Is there a reason for that ? Never had that before with anything .
Cpu hit is not hug but this delay makes it practially impossible to work on a track with such long delay, makes playing very annoying.
I hope it gets fixed in the future cause its one of the best EQs around .

Ok i read about latency setting and that sovles it but wow, with each instance i get more and more delay/latency for everything, its very weird, IMO it should be on NONE by default cause it just scares people off, not everyone is willing to come here and ask or read whats happening.
I also spent quite a bit of time figuring out why my track suddenly is delayed so much , tinkering with host settings and asio... so thats also big minus.
Anyway im gonna use it on none latency settings, i just wish it was default( not for me but for others who try it and run away, i know you can set it to use current state as default).
I guess its mathematically "nicer" with more latency and its less distortion or phasing issues but its not horrible with NONE setting and i cant tell the difference .thats why me personally i dont care if its a switch between useable/notuseable im going to stay on it.
Yeah i see im not the first blabbing about it but it can be an issue for newcomers...

[imrae]

It isn't strange if you know what a linear-phase EQ is.

This is an effect that should always be used with plugin delay compensation. (i.e. not on "live" channels with input monitoring)

Ok i read about latency setting and that sovles it but wow, with each instance i get more and more delay/latency for everything, its very weird, IMO it should be on NONE by default cause it just scares people off, not everyone is willing to come here and ask or read whats happening.

At the NONE setting it isn't a linear-phase EQ. That's more confusing as a default. You should be able to make a custom default in your DAW, but please don't ask for it to be inflicted everyone else.

[bwwd]

you are correct, im just glad i can turn lag off and use it like any other eq, i like "side" function in it , i missed it in a lot free EQs