Collaborate on building Reaktor filters in Gen?

@stkr: dude... hi! I'd love to talk, maybe a google hangout some day? :D

@ernest: thanks man - it's all coming back to me now, hehe. I remember finding myself doing those smoothers for every little thing in gen.
I don't know, I find the inputs more or less unusable until this process has been done to them, at least in... "practical applications", with modulation and all that.

Awesome stuff, again. Keep it up!

You're most welcome.For gaincompensation, I've also uploaded a fast response limiter. The link is now on the same page:

http://www.yofiel.com/software/cycling-74-patches/svf-saturating-filter

That being said, I think it would be a good idea to add table-based gain compensation for selfoscillation to this filter. While there are table-based gain compensators in the Reaktor core library, they don't work for this filter because it provides mixed 2/4-pole output, rather than switched output, as well as internal saturation. Has anyone made a patch to generate gain compensation tables for filters at different resonance and pitch settings?

An updated version of the SVF is uplloaded.
* Optimized Mixer Control Path
* Encapsulated Filter Object
* Added optional smoother object

http://www.yofiel.com/software/cycling-74-patches/svf-saturating-filter

If you have contributed to the discussion and wish to have a credit on the web page, please send your name and contact information to the contact form on Yofiel.

Port of Integrator-based zero delay feedback Butterworth low-pass filter(to 8 poles).

from : https://github.com/fukuroder/Reaktor_Files/tree/master/ZDF-Butterworth-LPF

Thank you for the link, afw. I did see a Reaktor version was made available on a third party website some time ago, yes.

As mentioned before, please send a note on the Yofiel webserver with your full name and contact information if you wish your filter work to be included in the distribution package. I wont distribute other people's files without such written request.

Here is a performance test of the SVF versus Reaktor without a polyphonic noise source and no modulation. With 16 voices on a 3GHz i7 in standard configuration, Max 64 reports 18%, and Windows reports 5% usage. For an equivalent design in Reaktor, it is 15% and 3%. So it appears gen~ is, at a base level, very approximately 20% slower than Reaktor core. This does not take into account any modulation, which would increase Max cpu load more than Reaktor.

I repeated the test with 200 voices. Max does a better job at palatalization, and while it reports 27% CPU usage, the load was more balanced across CPU cores. However attempting to reopen the patch caused Max to crash. Reaktor uses SSE2 MIMD acceleration on Intel CPUs which provides much smoother polyphonic performance, but it is not so scalable for future multicore enhancement for a single instrument, as it runs on one core only.

here are the max results with 200 voices

HI striker, I did quite a bit of experimentation with code boxes and params, and I think you are right that in code boxes, params are evaluated on vector boundaries. But also, and I could be wrong, I think handling of code boxes is slightly different in code boxes and with ui objects. Outside code boxes, the compiler can scan through the net list and re-evaluate params only when they change; but in codeboxes the compiler can't know whats going on inside loops and conditional expressions, so it re-evaluates all params on every boundary vector.

I tested how params are handled with the gen~ code

Param sel, x1,x2;
if (sel != 0) {
    out1 = selector(sel,x1,x2);
}

when setting x1 to a some value and sel to 1, it outputs the value of x1 as expected. However, when setting sel to 0, the output still goes to zero. This means the selector statement is being reevaluated when sel changes, even though the condition should be stopping it.