[sai'ke]

Changelog 1.37
- Tempo sync lfo.
- Normal LFO displays frequency in Hz.
- Dragging sliders an option now.
- Drag more slowly if you hold SHIFT.

Changelog 1.38
- Bugfix ignore x4 parameters for inversion parameter in RMS mode (they otherwise can lead to negative RMS).

P.S. This was a feature before, but maybe some of you were not aware of it, if you use the scroll-wheel while over the control, you can make more precise adjustments. This is what I tended to use for the last tweaking.

I think there are two reasons Filther is on the expensive side for some of the filters. First, I use a fair amount of trig functions to get the saturation behavior that occurs inside these filters (specifically the opamps show saturation behaviour). It's this saturation behaviour that makes them sound fatter as you drive them. Trig functions are usually pretty expensive however. On some filters, I used approximations of trig functions to make them a bit faster, but I only did this where I couldn't hear (or see) a difference in the sound for my test sounds. Even with this, it is still not super cheap.

Second, the non-linear filters can't be solved explicitly, which means that for every sample, I have to solve a system of equations. The most extreme ones (WASP, CCM, SEM, Moog) have 4 equations, which means I have to invert a 4x4 matrix multiple times. While I hardcoded this with the equations substituted in to make it faster, this is still just going to be relatively expensive, no matter what. I thought that since it's a single voice effect, it'd be okay for a post processing effect such as this.

If I were to do a synth however, I'd probably try to approximate the trig functions with something that I can solve explicitly so that I don't have to do this iterative procedure anymore inside the sample loop. This would make the filter sound a bit different; but in a polyphonic setting you'd probably not notice this as much.

If you want to keep down cpu, don't oversample too much. If you're mostly interested in the filters and not the waveshaping, then it's rarely necessary to oversample more than 3x.

As for jsfx. I think jsfx is super cool in that you can really get from 0 to a running prototype very quickly. The only downside is that the language is a bit sparse on abstractions and that I'm not entirely sure how clever the code optimization is and that it's a bit tricky to measure performance. If you code a VST in C++, you usually have a bit more control on how specific things are handled. For example, processors have special units that can operate on several numbers in parallel (Single Instruction, Multiple Data) and if you structure your equations in a specific way, you can make use of these. This way, you get more computation per cycle. I suspect (but don't know) that jsfx tries to find such optimizations when compiling jsfx to runnable bytecode, but it's not entirely clear to me what coding practices allow it to do so better. Anyways... long story short, there may be future optimizations that I can still do; but Filther will always be on the slightly more expensive side of things.

If there's a lot of demand for it, I can maybe provide a little hint in the combo box for how expensive the different filters are.