Smooth CC formula

[jpcima]

I have studied effects of bend_smooth, and I share some results. In SFZ specs, smoothcc under Modulators is a "see also" to opcode bend_smooth.

The experiment is to load a sine tone and modulate midi pitch bend with a ramp lfo. The results were observed on spectrogram in real-time. Then, it was matched to a faust program which plays a sine modulated with identical LFO and range.

• sfz: sine440.sfz.gz
• pitch modulator jack client: bendlfo.cc.gz
• sine modulator sinemod.dsp.gz

:warning: note that the smooth filter must be applied on the CC values, not cents values which are result of the conversion following.

The smoothing filter is one-pole LPF which is defined by a time-constant tau. (cf. faust basics.lib) pole = exp(-1.0/(tau*Fs))

These are approximate results measured visually. tau is observed starting at 0, varying +3 ms by bend_smooth unit.

#bend_smooth        tau measured (ms)
10                 30
20                 70
30                 90
40                 120
50                 160
60                 180
70                 220
80                 230
90                 270
100                300

[paulfd]

So it's a straightforward lowpass filter with this constant then? Thanks for the investigation. For this one the nice part is that it's not modulated at all so it's much simpler..

[jpcima]

Yes, I was not expecting anything more complicated.. as it turned out, the model was fitting on the first attempt.

[paulfd]

⚠️ note that the smooth filter must be applied on the CC values, not cents values which are result of the conversion following.

Re-reading all of this, this is going to be a bit annoying I think.

[jpcima]

Yes but also it makes more sense implementation-wise. It's cheaper to apply filtering once per CC rather than modulation sink where it's applied to.

Btw these measurements are 1. pitchbend only, 2. ARIA

I'll try to get a new set measurements based on cakewalk, and by use of CC values.

[paulfd]

Well except you can't really apply it per CC, since different regions might have different inertia parameters. You're kind of forced to compute it for each target.

At least for the current state of the modifiers now it would be simpler to apply it after conversion 😄

[jpcima]

You could still precompute it, per-CC and inertia and curve. Anyway I'll try later to check how the information above holds on cakewalk.

[paulfd]

For sure but then is it in general cheaper to apply a possibly nonlinear function (e.g. exp or log functions mainly) to a full envelope rather than building the envelope out of points from the nonlinear functions? You can do cheap multiplicative ramps using simd so right now I went with the latter.

Note that having a "multiplicative" filter could be a way to solve this dilemma 😁

[jpcima]

Note that having a "multiplicative" filter could be a way to solve this dilemma

Not possible, however: since you will be repeating these identical instructions for all CC, you could SIMD then in "vertical" manner and handle the filters 4 at a time by SSE.

(it's the same kind of vertical processing I hope to do to speed up strings after finalizing)

[paulfd]

Todo to finish implementation:

• [x] Add a simpler smoother that the voices will hold

• [x] Preallocate the smoothers in the voices after loading the files -- à la filters/eqs

• [x] Add smoothing to the modifier loops where necessary.

• [x] Add smoothing for bends too

• For simplicity I think we can safely assume that the smoothed modifiers are always going to be read in the same order w.r.t. gain/cutoff parameters and state. This means pre-setting the gain is possible, and that

• For multiplicative-type smoothing an adaptation of e.g. the filters is possible (see e.g. this tentative which seems to behave properly when implemented in python with an exact power function), provided there's a proper way to approximate a pow function. Check the stability of this approach, otherwise there is always the possibility to just smooth linearly in the log-domain, with possibly slightly worse results.