# Best smoothing time for Knobs?

Discussion in 'Building With Reaktor' started by Quietschboy, Jul 29, 2018.

1. ### herwNI Product Owner

Messages:
6,403
for \$=1 and start at z=0 you get after 1000 steps:

\$=0.5, z=0

\$=0.5, z=0.25

and decreasing
\$=0, z=0.5

If you smooth a hardware motion it is more complex as you change \$ and z continuously.
So this is only a simple example for fixed \$ and z (start).

Last edited: Sep 12, 2018
2. ### colBNI Product Owner

Messages:
3,246
I don't have Monark to test the actual code, but thinking about using a slew limiter with the rate linked to input delta makes sense.

Turning a knob at a fast but steady pace generates a sequence of events with equal value spacing.
If the rate of the slew is based on the difference between the latest knob event value and the slew value at that time. The slew will start slow because the first event is at 'minimum distance' from the slew state - one knob click from the previous value.Then, when the next value arrives, the distance between that value and the slew value is greater (because the knob is moving faster than the slew), so the slew rate is increased. Assuming the code that updates the slew time is nicely tuned, the slew rate can very quickly catch up with the speed the knob is being turned.
In some ways it is similar in response to the timing approach - the initial slow slew of the first event is very similar to the single tick lag in the timer version.
My quickly thrown together slew version (I suppose the Monark one is somewhat more refined?) works pretty well. When set up to have a similar response to the timing approach, it has a slightly better feel at slow input speeds, is almost identical with fast large inputs (the lag is very similar). It is slightly worse with fast but small input movements.

The tuning is all about applying appropriate curves to the relationship between the |input-slew| delta and the new slew rate.

tldr: it doesn't 'guess' or 'calculate' the time between events. It speeds up it's rate based on how far it is lagging behind.

EDIT: added a slightly optimised version of the slew based smoother

#### Attached Files:

• ###### adaptive smoothing 06 wip.zip
File size:
82.5 KB
Views:
47
File size:
81.5 KB
Views:
39
Last edited: Sep 12, 2018
3. ### herwNI Product Owner

Messages:
6,403
As the MONARK smoother isn't very well in CPU-usage it is no option for me although it works very well.
MONARK uses only a few smoother, so it is no CPU-problem, but EMSCHER has 140 smoother and is only a small modular. My target are 200 smoother and more.
Mark is testing several smoothers and i hope he will find a good compromise. I will insert his best smoother to EMSCHER and modular x.
I have seen some smoother curves for fast and slow changes. MONARK's was very impressive.
Perhaps Mark shows some curves.

Last edited: Sep 12, 2018
4. ### colBNI Product Owner

Messages:
3,246
I guess it must work differently to my slew based version. That is set up so that when idle, it's just a read/compare/router to control the clock.

Certainly works fine at various clock rates. Do you have some sort of cpu testing harness for smoothers ?

FWIW i've attached a version that takes a clock bundle as input for easy clock rate tweaking.

EDIT: This needed some additional code to manage initialisation (otherwise all controls would start active until they reach their control value - would be cpu Armageddon).

EDIT: hmm, a few tuning tweaks, and I'm pretty happy with the performance of this now.

#### Attached Files:

File size:
83.9 KB
Views:
46
File size:
84 KB
Views:
50
Last edited: Sep 12, 2018
• Like x 1
5. ### herwNI Product Owner

Messages:
6,403
Mark is testing since weeks and created several nice versions, i think based on your ideas.
Wait until he has time to answer (i think at 0.00 a.m.)
He has made a test ensemble with 10 (?) optimised versions.
I have his newest version and will test it in EMSCHER.
A single smoother works in different ensemble in different way; the real problem is, to test it in big ensembles, especially in modular x, which is very ambitious.
My problem is that i really don't understand what he is doing inside the smoother.
Have to expand modular x.

PS: But what i see is, that smoothers inside a big ensemble with many knobs is really difficult to repress and not trivial.

Last edited: Sep 12, 2018
6. ### herwNI Product Owner

Messages:
6,403
Mark's Version is much better than MONARK's.
Needs at the moment +10 %, if all containers are activated, means 60% instead of 50% for snap 001 Bank1 in EMSCHER.
142 knobs with polyphonic smoothers (4 voices)

Last edited: Sep 13, 2018
7. ### colBNI Product Owner

Messages:
3,246
That sounds pretty good, although I guess it just highlights the fact that Monark has a relatively simple interface, and where there's no need for optimisation, you shouldn't be doing it

EDIT: Although it doesn't mean a whole lot without specs and more detailed comparisons. And also context plays an important part in performance.

e.g. Tweaking the last version I posted for optimal performance, I'm running 128 smoothers with 4 voice polyphony clocked at 48kHz, when idle, cpu is ~5.5%. Clocked at 6kHz its ~1.5%. But that's with every smoother connected to the same control input (although I am ensuring that they are all running)... Even just attaching different inputs to every one might bump up the cpu… or not... And system performance varies wildly...

It might be nice to have some sort of Reaktor Benchmark, but it would be pretty tricky to create a robust one that was even remotely general enough to be useful.

Last edited: Sep 13, 2018
• Like x 1
8. ### herwNI Product Owner

Messages:
6,403

Mark's test ensemble

• Like x 2
9. ### colBNI Product Owner

Messages:
3,246
That looks interesting. It's funny that that is one area where you can't beat primary level switches!

I chucked some smoothers into Emscher.
For the default patch 'simple synth (SCO5)', UL version I'm getting ~29%-30% cpu. For the same thing with smoothers installed on all the knobs in the synth, running at 6kHz, it's roughly 35%-36%. Bumping up to 12kHz adds another 1%..2%

All the knobs having different ranges is a bit of a pain though!
It's possible that there is an impact from having to convert to and from an 0..1 range, but I don't think it's much - only should effect cpu while control value is changing.

Anyway, ~6% seems like not too bad a hit considering, and it could probably be reduced still, but the laws of diminishing returns begin to bite soon.

10. ### QuietschboyNI Product Owner

Messages:
465
How long is the compiling time? Have a stopwatch? Really!
Can you beat my 11.4 seconds or Max´(Monark) 8-9 seconds? Measured in polySVA. Makes no sense on different computers, but what?
Btw, Herwig left some few knobs without smoothers. So my tests with EMSHER respect this selection.

Sorry for not answering here immediately. I´m working on the Display for showing the Smoother Curves. The zooming was banana, but it´s looking good now. I´ll show some things later on.

11. ### colBNI Product Owner

Messages:
3,246
I'm at about 6.5 seconds give or take. That's inside the polySVA core cell. Seems faster elsewhere.

That's on a system that runs the current UL version with the SimpleSynth(SCO5) at ~29% cpu.
unsmoothed UL version compiles in ~4.2 seconds for me in polySVA section.

I wondered about leaving smoothers off some, but decided for testing purposes to smooth all except the scope controls. Which controls didn't you smooth?

Last edited: Sep 13, 2018
12. ### colBNI Product Owner

Messages:
3,246
I suppose where the smoothers are installed might have an impact on compile time.
They could go here:

but I chose to put them here:

mainly because I used an 0..1 smoother, and the scaling of each parameter is particular to the specific control, so it really needs to be in the app section to make sense. Cant see it really making a difference though.

Ideally the knobs would all be 0..1 at least from the point of view of smoothing . Alternatively, sending the actual knob value through then convert it pre smoother, then post smoother, convert to the range used by the algorithm - at least that way there are 2 conversions rather than 3. Although I guess it would only save memory and maybe a smidge of compile time - the cpu difference will be negligible.
I haven't looked much deeper - I wondered if there's a technical reason why the controls are all scaled so that the knobs always move in steps of 1. maybe some trick using integers as an optimisation of some sort?

EDIT: attached the smoother version I used

#### Attached Files:

• ###### smoothMk2 edit.zip
File size:
7.2 KB
Views:
59
Last edited: Sep 14, 2018
13. ### QuietschboyNI Product Owner

Messages:
465
Wow! Incredible!
The compiling time is so low...i can´t believe... did not compare the CPU load, yet.
Do you bypass Init and Snap Recall events? Else the CPU will be blown away when all smoothers beginn to run simultaneous.

Herwig and me place the smoothers into macro "app", too.

14. ### colBNI Product Owner

Messages:
3,246
Yeah, my PC is pretty good at compiling - it's getting old now, but still powerful-ish - i74770K

I tried to bypass Init and Snap Recall - I'm guessing if I missed anything you will find it
It's based on the idea from the Monark one. I wrote it from scratch, but it ended up looking pretty similar - I guess it's a pretty simple concept so that was likely.
The main thing is that the idle process is just read/compare/router. It doesn't push the cpu on init. However I have had some problems, particularly with LFO2. Not sure if that's something I introduced of if it's an existing bug.
I can upload the version with the smoothers installed, or email it or whatever. Its about 6Mb so not sure if it will attach here on the forum - cant remember what the limit is.

15. ### tenandtracerNI Product Owner

Messages:
163
Really impressive (and inspiring!), colB. Thank you for sharing!

16. ### herwNI Product Owner

Messages:
6,403
I have installed 142 smoothers as i said in last posts.
the reason is the display of all knobs. The knobs displays are mainly multi text modules. But i am using the display areas as buttons too. If you mouse over the display it changes from label to number. If you click on it, it changes permanently. So the easiest way is to combine label, display, button to use integers. Here is an example of LFO 2 (same for LFO 1 and GEIGER).

It has three ranges [0|2Hz], [0|20Hz] and [0|200Hz].
Depending on its panel elements ...

... the macro range calculates flashing display. Remember that several knobs use fine tuning too. Best for me was (is) to use integers. So i can use similar range macros for all knobs.

Calculating the used value is then a simple process.

Last edited: Sep 14, 2018
17. ### herwNI Product Owner

Messages:
6,403
You are right. I had changed the frequency knob of LFO 2 only in one of the containers (arrgh, was late in night i think) and forgot to change in the others.
I will change soon and upload.

PS: have corrected and uploaded - thanks Colin

Last edited: Sep 14, 2018
18. ### colBNI Product Owner

Messages:
3,246
Heh, that wasn't the problem I was having. It was related to the range scaling.

The smoother I'm testing uses a 0..1 range, so I convert to and from this range.
The LFO has a control to change it's range. So I needed to dynamically update the conversion parameters to match the active range setting.
But even this didn't fix it!
What I found is that it seemed to be getting the controller value with the new range before the new range setting arrived, causing the smoothers scaling to go out of bounds and throw an -inf fit.
The problem is in the display macro in the user interface section. I guess its that old Reaktor issue that orders events depending on the order the wires were connected! I stuck an order module in there and it seems to have fixed the issue. I can change the LFO range now without clicks and -infs

19. ### colBNI Product Owner

Messages:
3,246
152 poly here I think?, and maybe 20? mono if there are 20 mono knobs in there...

Last edited: Sep 14, 2018
20. ### herwNI Product Owner

Messages:
6,403
I don't use smoothers in scope, midi and in mono part (later, is not so important for now - still want to test).

Last edited: Sep 14, 2018