I love your EQ 560 (it's probably the greatest graphic EQ there is in JS format) but I noticed that there might be a miscalculation in the max Q value.

In line 79 the maximum Q value of 5.763566 seems too large. If you divide it by 8, so that it becomes 0.72044575, the gain/Q interaction becomes pretty much identical to UAD's API 560. I don't own a real one (unfortunately) so I can't say for sure that this is how a real 560 behaves, but UAD are usually pretty close with the filter shapes in their EQs.

I did upload my own modded version to the Reaper stash, but I should ofc have asked you first. If you'd like I can remove it again!

Thanks for your great work!

(PS: Now that Reaper has native plug-in instance and FX-chain oversampling it could make sense to have a on/off control for the internal oversampling, just in case someone wants to use the FX-chain oversampling function)

Hi,

first of all, thank you for your nice work.

I was wondering if it would be possible to add an optional/adjustable "look-ahead" function to the gate/expander (and perhaps to compressors, too).

Have you thought about turning your github repositories into reapack repositories to make them easier for people to install and keep up to date?

https://reapack.com/

Bus Comp, Track Comp, and Consolidator all seem to behave the same way in this regard.

If I start playback "in the middle of" some audio file with a level that triggers compression, for the first (approximately) half second or so, the audio "ducks" as though it's overreacting to the signal. After that the compressor sounds normal; it's only that initial "ducking" that sounds wrong. (To really notice this behavior, be sure to set the threshold low enough that significant compression happens.)

By comparison if I start playback prior to an audio event that would trigger the compression (starting playback on silence, or at a lower level audio item that doesn't trigger the compressor), the compressors behave nicely once the compression is triggered by louder audio.

So they work well most times, but that behavior could be problematic for rendering (and also it can be very distracting when starting/stopping playback while adjusting the compressor's settings).

I should also mention: I can "smash" other compressors by lowering their threshold a lot, and they don't exhibit this sort of behavior. The reaction of the other compressors (ReaComp for example) would sound consistent; starting/stopping playback, or starting playback in the middle of a loud audio item, makes no initial overreaction.

The Wave Scope has a setting that should halt the display whenever Reaper is paused, so that what's currently visible in the display stays there and doesn't vanish off to the side.

Reaper apparently doesn't correctly report the play_state value to JSFX.

According to the official JS documentation, when Reaper plays back a project, the play_state value is 1. When playback is paused, it should update the play_state value to 2, but instead it just stays at 1, letting the JSFX think the project is still playing.

This has been reported and discussed in 2011, in 2014 and in 2018 on official forums and bug trackers already. Sadly, the broken play_state behaviour is still broken in Reaper version 7 in 2024, a mere 13 years later.

Until the play_state behaviour is fixed in Reaper, the "halt on playback pause" feature in Wave Scope will not work.

You should consider putting "chokehold" or a similar keyword in your effects. It would make it easier to filter the effects list for all of your effects. :)

Dear chkhld,

Sometimes when I load Knee Clipper, the graphics look like this instead of the I/O levels.

Thank you for an awesome plugin, though!

Hello

Is it possible, with the help of one of your plugins, to have a, let's say, square frenquency of 200 Hertz with a positive offset (from 0V to 1V, with no negative voltage) ?

Does this setup generate a positive offset square frequency (of 15 Hz here) ?