Rubberfilter - extreme filter with up to 384dB/Oct!

[trimph1]

This is a wonderful little filter. Thank's so much for this little bugger!!

[asseca]

Hi Christian,

Thanks for this plugin and the latest update

I just updated the plugin to use the latest VST framework. This fixed several bugs and issues.

Some more little "problems" when used in VstHost with both GUI-window and Parameters-window opened:

• when adjusting a knob in the GUI then the parameters are not updated in the Parameters-window
• when "Bypass" is "Off", then "POWER" is also "Off"
• personally I prefer to use the SHIFT-key to finetune a knob, and use CTRL-key to set the default value
• somehow the knob movement seems a bit too "slow" compared to other plugins

[pheeleep]

3 years late to the party. Better late than never. Just tried out this filter. Really liking it. You can adjust the cutoff frequency and select a slope, but we don't have control over the resonnance, correct? Very cool sound. I will be using it.

-edit-

Win 7 64-bit using FL Studio 9.1

I can only automate one frequency knob. As soon as I start automating 2, there's a bunch of clicking going on. I'm only automating frequency knobs..

[Christian Budde]

Hi,

some info on the issues mentioned:

[*]Some more little "problems" when used in VstHost with both GUI-window and Parameters-window opened:
[*]when adjusting a knob in the GUI then the parameters are not updated in the Parameters-window

I have to check this. So far I had only either one window open. From what I remember I can imagine that two parameter windows open at the same time will result in problems, as it was not designed for this goal. It should be fixed, but I see no point to hurry so far.

[*]when "Bypass" is "Off", then "POWER" is also "Off"

A reason for this might be the fact that I accidentally exchanged the "on" and "off" states in my framework. Ever since I get confused about the right setting. I will fix this.

[*]personally I prefer to use the SHIFT-key to finetune a knob, and use CTRL-key to set the default value

I think all my latest plugins uses this paradigm as well, but I won't change the current plugin, since some people might be used to how the plugin works.

[*]somehow the knob movement seems a bit too "slow" compared to other plugins[/list]

Yes, I put some "weight" on the dials. Which means I limited the acceleration. So if you change a value very quickly it will react slower than probably expected.

You can adjust the cutoff frequency and select a slope, but we don't have control over the resonnance, correct? Very cool sound. I will be using it.

The filter type I am using here is a Butterworth filter, which pre-defines the resonance to a fixed value (= just about as flat as possible without typical resonance like peaks)

I can only automate one frequency knob. As soon as I start automating 2, there's a bunch of clicking going on. I'm only automating frequency knobs..

As I wrote on previous pages of this thread, automation is not guaranteed to be click-free. This is a design-decision. At least reducing the clicks to a probably inaudible level might increase the CPU usage by a factor of two.

For small changes the clicking might be inaudible, that's why automation of parameters is allowed, but there is no guarantee for clicking-free operation.

Kind regards,

Christian

[Christian Budde]

To Asseca: Are you sure you tested the latest version?

I just tried it and I can not see any problem you described. Especially the GUI update and the bypass issues are non-reproducible (at least with the latest version of VSTHost and Rubberfilter).

Kind regards,

Christian

[thecontrolcentre]

Thanks for the update Christian

[asseca]

To Asseca: Are you sure you tested the latest version?

I just tried it and I can not see any problem you described. Especially the GUI update and the bypass issues are non-reproducible (at least with the latest version of VSTHost and Rubberfilter).

I am using VstHost v1.48.0.1, dated 26 Oct 2010, and both RubberFilter DLLs (from 7z and installer, which seem to have different sizes), dated 10 Dec 2010.

I have also tested in Kore2 and Reaper v3.74pre4 same problem in both:
If I change a value in the RubberFilter's GUI, then the value is not updated ti the host. Also the bypass issue persists in those hosts ...

[Christian Budde]

I have also tested in Kore2 and Reaper v3.74pre4 same problem in both:
If I change a value in the RubberFilter's GUI, then the value is not updated ti the host. Also the bypass issue persists in those hosts ...

Maybe I packed the wrong DLL into the installer, because at least the bypass issue is very much impossible, as I had already removed the (trouble making) code a while ago, as I found out earlier today.

If you open the information dialog in VSTHost you should not read anything about supporting the bypass function from the plugin side (Flags: 01EF08D8H and 'Has Editor', 'Supports accumulating output' and 'Supports in place output')

However, I wonder why the original poster was able to confirm that the GUI update bug was solved?!

Can you confirm the DLLs you loaded are indeed dated to the 10th of December (20:54)? I have just downloaded these files again to ensure that I have uploaded the right files. Or maybe you have a phantom copy of the old version lying around somewhere?

Kind regards,

Christian

[pheeleep]

Thanks for your explanation. I guess what I am hoping for is a version that only has one low and one high cutoff frequency knob. If I could at least automate the low or high freq that would be cool. With the current version I can't automate the freq when the link button is engaged, and I can only automate a cutoff freq for either the left or right channel, not both at the same time. Not sure I'll actually have much use for this filter after all...

If there was a version that only had 1 low cut and 1 high cut (no separate left and right), and I could automate one or the other at one time without clicks, I would use it.

[Christian Budde]

If the plugin don't work for you, than I'm fine with it. As I said it has been developed right from the beginning as a static tool, definitely NOT meant for automation.

Since the development has been done in the past and the development cycle is over, I can & will only present fixes and maybe a port to other operating systems. Changing the design goals when the plugin is already finished and in use will result in a chaos.

Maybe I can consider these things for a version 2.0 or a different plugin.

Kind regards,

Christian

[pheeleep]

Thanks. No worries. I understand. But isn't a static filter just an Eq? Not trying to be a smart ass. Just trying to understand the benefits of a filter that can't be automated...

Oh and just want you to know that I love my Electri-Q CM edition. Love it since the first time I tried it.

[asseca]

I have also tested in Kore2 and Reaper v3.74pre4 same problem in both:
If I change a value in the RubberFilter's GUI, then the value is not updated ti the host. Also the bypass issue persists in those hosts ...

Maybe I packed the wrong DLL into the installer, because at least the bypass issue is very much impossible, as I had already removed the (trouble making) code a while ago, as I found out earlier today.

If you open the information dialog in VSTHost you should not read anything about supporting the bypass function from the plugin side (Flags: 01EF08D8H and 'Has Editor', 'Supports accumulating output' and 'Supports in place output')

However, I wonder why the original poster was able to confirm that the GUI update bug was solved?!

Can you confirm the DLLs you loaded are indeed dated to the 10th of December (20:54)? I have just downloaded these files again to ensure that I have uploaded the right files. Or maybe you have a phantom copy of the old version lying around somewhere?

I have downloaded both just before my last post.
7-zip reports that the 7z's DLL is dated 10 Dec 2010 18:40.
7-zip reports that the installer's DLL is dated 10 Dec 2010 19:54.

I have tested both DLLs, just to be sure ...

BTW I am refering to the Bypass parameter ...

[Christian Budde]

7-zip reports that the 7z's DLL is dated 10 Dec 2010 18:40.
7-zip reports that the installer's DLL is dated 10 Dec 2010 19:54.

19:54 vs. 20:54 seems to be a summer/winter time issue, and the 7z DLL was exactly what I sent to the original poster, so even with the early time it has been confirmed to work.

I tested the version reported to be 20:54 over here in the latest VSTHost, I downloaded directly from the website.

BTW I am referring to the Bypass parameter ...

Ah, you mean the 'Bypass' parameter exposed in the parameter view. This is indeed something that needs tweaking. I just changed the label to 'Power' as it reads on the GUI. The fix will be uploaded tonight.

Regarding the GUI updating issue, I need to check this in detail. It might be related to another issue of a different plugin not writing automation data. I wonder why this only happens on foreign systems and never on mine?!

Thanks for the report so far,

Christian

[Christian Budde]

Update:

• The exposed parameter 'Bypass' in the host's GUI now labels 'Power'
• All parameters can again be automated properly -> most likely the issue with the non-updating host GUI on some computers/hosts shall be fixed as well.
• synchronized both the 7z and the installer to have roughly the same time stamp

[LeVzi]

Hi Christian,

Thanks for the RubberFilter update, I was wondering if you were going to update the butterworth and cheb filters too ? Basically the order resets to 1 every time you reload the project.

Thanks again