Hacking together a metaparameter system / Guassian Filter discussion

[elanhickler]

Have a slider of -1 to +1 control a modulator value constant output. Send that to a breakpoint thigie (the object's output value offset) which is also a modulator, that then finally gets sent to a slider of my choice.

So.

host slider1 --> modulator1 (offset value) --> 
                                               breakpoint offset value1 --> target sliderA
                                               breakpoint offset value2 --> target sliderB
                                               breakpoint offset value3 --> target sliderC
                                               breakpoint offset value4 --> target sliderD
host slider2 --> modulator2 (offset value) --> 
                                               breakpoint offset value5 --> target sliderE
                                               breakpoint offset value6 --> target sliderF             

I could create a giant page of 10 host sliders, 50 breakpoint thingies, send those breakpoint thingies to target sliders.

This is what I need for Filters of Mass Destruction. This would be the dev metaparameter system I've been talking about. It's just an interface to help me create FMD. I think I can to move forward with this! Well, I still need you to make a breakpoint thingie. If you could hack something together really fast that would be amazing.

[RobinSchmidt]

yes - this mapper was what i was planning to do next. it's another a lot of work though, so it will take some time. the most work will be the gui editor. actually, i'd like to make a re-usable "NodeEditor" class or something like that. look at the guis of my BreakpointModulator, EasyQ, EchoLab ...and now that mapper - notice some similarities? each has points to insert, remove, move around - that functionality should be factored out into a baseclass. such a mapper would actually be the perfect, generic context to do such a thing

[elanhickler]

Could you do the gaussian filter first?

This is why I want to do the Jerobeam stuff, because you have a lot to do for your library... that I need done as soon as possible. It's already september and I am very far from my business goals.

It would be very bad if FMD was not out for Christmas. I wanted Chaosfly out for Christmas originally.

That also means we need skinnable GUI!!!!

[elanhickler]

Also, you still need to address the problem of presets not being found easily on Mac, license file not easy to deal with on Mac as well.

[RobinSchmidt]

ok, i'll make the smoothing filter next. it's actually simple to implement.....but there's some math challenge in it: i want to make the transition times more or less independent from the order. just chaining a bunch of 1st order filters will make the response time more and more sluggish with increasing order. the time-constant of each of the filters must be automatically downscaled with increasing order. i want to derive a formula for the time-constant-scaler as function of the order, such that all step-responses meet when they go through 0.5. ....not sure if i can figure that out, but that would be ideal. i'll try

[RobinSchmidt]

btw.: such a smoothing filter could be very useful in dynamics processors as well

[elanhickler]

such a smoothing filter could be very useful for chaotic analog emulation, for example, FMD filters.

Can I coin the term "chaotic analog emulation" or "digital chaotic design"?

The idea is that you mimic analog circuit behavior, such as a resonant filter, through oscillator self-modulation or multiple-oscillator-cross-modulation. This unit of oscillator, unlike traditional oscillator concepts, do have both an input and an output.

I wonder if the idea could be expanded to emulate analog circuits other than filters, phase-lockers, and waveform sync. Maybe it could be used to emulate an amplifier that, when fedback into itself, it gets overdriven, and self-oscillates.

Actually, I think using chaotically-interacting sinewaves to generate a sawtooth is a more correct oscillator for an analog-emulated subtractive synth, because you can reduce/eliminate aliasing by reducing the cross-modulation as you approach higher frequencies and/or inject noise into the feedback path, this in combination with a little bit of anti-aliasing/oversampling will make for very nice oscillators. I intend to eventually make a subtractive synth that uses 100% chaotically interacting oscillators to generate the source oscillators and as filters. You can also mimic soft sync, not sure about hard sync... I don't know how it'd all work together, I need the mapping system to really begin experimenting with all these ideas...

Oh! I think you can create a square wave by doing a harmonic-locking style chaos patch with sinewaves where the end result is a jump in "voltage" when the sinewave crosses a threshold. So a square oscillator would be some kind of [sinewave chaosillator] --> [sinewave chaosillator] setup. If you want to go even cheaper, actually, triangle waves can be used for EVERYTHING! Or, actually, to avoid aliasing, maybe a cheap sinewave approximation algorithm would be better.

Ok, instead of releasing Chaosfly as my 4th product, I think I want to pursue this purist-chaotic-subtractive-synth concept where EVERYTHING is chaotically-interacting oscillators. It will be the most f***ing analog sounding synth ever made. I think it will also be the most efficient analog-esque digital synth ever.

[RobinSchmidt]

try the new rsSmoothingFilter in rapt. i currently simply scale the time-constant by dividing it by the order. the step response curves don't meet in a common point, but are actually comparable in terms of transition time:

i think, i'll leave it at that simple formula. that makes it cheap to re-calculate the coeff when the time-constant is being modulated. it currently supports orders up to 10, but i think, i'll change the implementation to lift that limit. but you can already use it as is

[RobinSchmidt]

there's a typedef'd template instantiation rsSmoothingFilterDD (for double, double for the two template parameters). perhaps you should use that

[elanhickler]

what is the point of templates like that?

[RobinSchmidt]

that one can use it for different datatypes like float, double, multi-precision, SIMD-vectors, etc.

[elanhickler]

just tested, this fits the bill.

I'm using <double, double>, would rather not use library typedef, i'd rather define it for my own purposes for less cryptic code.

[elanhickler]

I'm using 0.03 smoothing as default, 10 poles. .3% cpu, meh! no one will notice. I could lower the poles with more experimentation perhaps.

[elanhickler]

Order 4 for smoothing is just fine for even mouse movements, when low smoothing/timing is used. Higher amounts of smoothing means the smoother reaches target value too slowly (non-linearly), but increasing order solves this. However, increasing order delays the reaction. So, with higher smoothing it's a balance between reaction time and how non-linear your time to reach target value. At lower smoothing, this is not an issue.

[RobinSchmidt]

i've been struggling with some math to work out a better formula for autoscaling the time-constant with the order, but no avail yet. i have, however some other idea that may solve the issues you are talking about: currently i'm using a chain equal first order lowpasses. i think, i could tweak the transition shape by using a different time constant for each filter stage. i may try some parametrized rules for the per-stage time-constant and let the user set up a shape parameter

[RobinSchmidt]

ok, you can now call setShape and setShapeParam - see comments in the class.

..i'm still unhappy with the scaling. ideally i would like to give the user a parameter, at which time the step response crosses 0.5 but all attempts to find a formula for that give totally unwieldy results. i guess, the only way is to actually measure, where it crosses .5 with a tentative filter and then scale all time-constants by that value (i.e. compress or stretch the time axis). maybe i could create tables for that

[RobinSchmidt]

for example, here are some step responses with smoother.setShape(rsSmoothingFilterFF::FAST_ATTACK); smoother.setShapeParameter(1.0f);

[RobinSchmidt]

as you can see, it now raises faster initially. you may have to tweak the time-constant when playing with that parameter to compensate for the overall change of transition time, due to not having a good scaling formula/table yet

[RobinSchmidt]

hmmm...wellll....yeah...i guess i will use a table that gets allocated and filled when the first object is created. that is, btw. an optimization possibility for the coefficient computations for the ladder filter as well. only there, i have managable formulas, so it's not that obligatory. here, i have no formula to compute the table entries - i have to run a simulation of the actual filter and make measurements

[elanhickler]

I just tried gaussian filter vs rapt::ladderfilter for audio purposes, both in general filtering and feedback fitlering. Ladderfilter is less CPU and gaussian filter doesn't seem to provide any advantages over ladder. So conclusion is gaussian filter is probably not useful for "listening/synth processing" purposes. It did however seem to provide a more analog frequency modulation response when moving the cutoff manually with a slider. But, probably some smoothing on the cutoff would be just as good.

btw, how do you set the "frequency" of the guassian filter? this formula? 1.0/(2*PI*newTimeConstant)

[RobinSchmidt]

the smoothing filter (it's not a proper gaussian design formula) provides higher orders - the ladder has 4 at max and it (the smoother) also has more flexibility for the shape/asymmetry. the modulation response thing is interesting. i'm using a slightly different update equation in the two filters (both are algebraically equivalent). maybe i should try the smoother's update equation in the ladder, too? ...but it's really strange - i think, they should behave the same. might do some tests with plots

[RobinSchmidt]

i have been trying to get the tuning tables to work today - but somehow, they don't work right yet

[RobinSchmidt]

i think, frequency and time constant are related by timeConstant = 1 / (2 PI frequency)

[RobinSchmidt]

i'm slowly getting to the bottom of why my tuning tables don't work as intended. it turns out that my most basic assumption - that when i scale all time-constants by a certain factor, i stretch/compress the step responses by the same amount - is false. it works quite well for 1st order filters, but for higher order ones, especially with asymmetry, there's a considerable deviation from that intuitively plausible rule. i wonder why....

[elanhickler]

hey do you want to do smoothing manager next? What were you thinking? jeez can i just code it for you? I'd do it myself but I don't want to do it and then remove it and implement yours. At least maybe i could get it started for you.

[RobinSchmidt]

hmm..not sure. i thought, the parameter-mapper would be the next milestone. i think, it has higher priority for your needs anyway. i would do that without charge for you, too. for the smoothing filter, i noted my work hours only partially. i'm not sure, if it's fruitful to try harder to get the tuning work or if i should just leave it as is (or put it on hold). what i'm about to do wouldn't really change the actual responses of the filter, just make it's parametrization more meaningful to the user. maybe, i should ask kvr, why my assumption about the time-constant scaling effect was so far off. maybe i should use bilinear transform instead of impulse-invariant but i'm not really convinced that this would help. it might be a dead end road

[elanhickler]

ok, continue as you are.

[RobinSchmidt]

just dragging over and adapting some basic math stuff from RSLib to rapt