debugging the smoothing system

[RobinSchmidt]

yesterday, i spent the full day debugging the smoothing system. there are some rather subtle issues to consider - like whether the parameter observers (sliders, meta-parameters, etc.) should be notified pre- and/or post-smoothing, etc. just have a look at my comments in rsSmoothableParameter::setValue. it's not yet fully sorted out but i think, i'm closing in.

[RobinSchmidt]

ok, i have made a few changes and within my toolchain, smoothing+modulation seems to work - also for child-modules. can you try again, if it is fixed for your plugins, too?

[elanhickler]

sliders should always reflect target value.

there should be no need to notify based on smoothing.

remove the smoother from the whole system and you're just left with a non-smoothed current value.

now the smoothed value should simply be a drop-in replacement for "non-smoothed current value" which the modulation system will modulate.............. whatever.....

let's see if it works!

[elanhickler]

I'm not seeing any issues!

[RobinSchmidt]

sliders should always reflect target value. there should be no need to notify based on smoothing.get informed pre-smoothing.

yes - but there's more than just sliders. i must also deal with plots that may have to redraw themselves bases on new parameter settings. think of a filter where you can adjust cutoff/resonance in a plot and with sliders. but yes - i have now made it such that sliders get notifications (with the target value) pre-smoothing

I'm not seeing any issues!

ok - that sounds good!

[RobinSchmidt]

get informed pre-smoothing

the problem with plots and update pre-smoothing is, that i couldn't use the same filter object for computing the frequency response plot as i'm using to produce the audio (because we would then get a plot showing the pre-smoothing freq-response). i could create an additional filter object just for freq-response plotting ...but that would raise other issues too

[elanhickler]

think of a filter where you can adjust cutoff/resonance in a plot and with sliders. but yes - i have now made it such that sliders get notifications (with the target value) pre-smoothing

I don't get it... but I think that's ok.

Robin, I've decided to go all out for Filters of Mass Destruction. I'm very serious about making progress on it now. I'm asking Jim to help me create the macro controller I need to start working on it. I think we could create something tomorrow. I will ask Jim to help me with whatever else I need now, such as doing a preset browser perhaps.

What I need from you now that the smoothing system is finished is continue the bug fixes. I can't wait anymore, and I need you to keep getting some of the basics taken care of. I think, if you fix the last few bugs, I would love for you to work on the modulation animation / repaint system. I don't need any GUI code, I will write all the gui drawing code myself, I just need the "foundation" for repaint notification or whatever... you know? (Edit: And I don't need this to release FMD, it can be added later)

[RobinSchmidt]

I'm asking Jim to help me create the macro controller I need to start working on it.

well, actually that would be the next thing i would look at when all bugs are fixed. ...the meta-mapper

[elanhickler]

i don't need the meta-mapper though... like... I just need a simple tool... I'm going to have jim help me create a widget where a knob decides the location of the reference value, and that reference value is based on a breakpoint... so, exactly like your breakpoint envelope, except instead of time, there is just a "current point".

And who knows how long it will take you to make the meta mapper. I am hoping to get something I can use tomorrow. Could be another two weeks for you to get the bugs fixed AND get the meta mapper finished.

[elanhickler]

thanks for your hard work so far! It's getting down to the wire, you have almost taken care of all the issues. I still want the meta-mapper, but I don't want to rush you or wait. I think moving forward, no issues will be desperately needed, oh except the first issue on the new todo list. You can close this thread!

[RobinSchmidt]

yes, i guess maybe at least a week. the breakpoint-mapper would of course be reusable. i'm thinking of a kind of breakpoint-editor where you can move nodes around and that translates an incoming value to a mapped value (via interpolation - linear in the first iteration and later maybe splines). if jim already has something like that or can pull it off in a single day - ok, go with it. i'm calling this meta-mapper because that will be the way i want to use it, but the code should be more general. i actually consider meta-parameters as a sort of (host-exposed) macro-parameters - just the mapping function is missing

[RobinSchmidt]

exactly like your breakpoint envelope, except instead of time, there is just a "current point".

exactly. we need a widget that implements some function y = f(x) based on breakpoints - to be set up by a gui editor. such a thing can then be used in many contexts....meta, macro...whatever (edit: even as waveshaper)

btw . i think rosic::PiecewiseFuncion (in the "others" folder) could provide the "core" functionality - or at least serve as staring point (i have not yet used that class in any product - so no guarantees)

[RobinSchmidt]

...oh damn...i'm just looking at the code ... and i have no idea anymore what i was doing there - especially in the cubic case. i want to re-implement that sort of stuff in rapt

...yes - looking at the code, i think that implementation is crap. the idea is right but it need some overhaul

[elanhickler]

do you still have to call callback when callback is assigned? I need to not do that as there will be some nullptrs (trying to remove annoying constructor requirements)

[RobinSchmidt]

i think, the reason we call the callback initially when it gets assigned was to ensure consistency between the parameter value and the corresponding dsp-core-object value. i introduced that after some discussion with you, i guess i could check against nullptr on assignment and when it is a nullptr indeed, not call it...and/or add a bool parameter to the function call whether or not to call the callback

edit: i think, we are on the wrong thread....however..

[elanhickler]

you can close this

[RobinSchmidt]

yay! case closed!

[elanhickler]

oh nope, open it back up.

modulation stops functioning on child modules when modulated parameter is currently being smoothed.

tested on mushroom generator

1. send modulation to child module parameter/slider
2. move that slider as it's being modulated
3. you will hear modulation cease