Decent Filters?

[lalo]

well..this is one of my favourite topics....

it's an important issue because modulation is the 'soul' of electronic instruments...and here is where the digital domains often fails...unless the things are well coded and interpolated....

try to do some fast filter modulation with an external midi controller on some Reaktor ensemble
(i don't know if they improves in R5..i'm speakin' about an old demo)...

this is definetly what i call a 'quality' issue...
along with smooth enevelopes and clickless mono synths when played with hi release times

lalo

[Barbed Wire Kiss]

whats OMG?

Oh My God! Ohmforce's filter that comes with Computer Music.

[Sascha Franck]

I'm no expert, but I don't know how this automatic interpolation with MIDI or GUI control is supposed to work. The host or the plug-in have no way of knowing how quickly you're moving the knob or plan to move a knob, so how can steps be smoothly interpolated?

I wouldn't happen to know HOW it's established, all I know is that you can actually do it.

I have a very small plugin some friendly soul sort of custom coded for me. All it does is lowering the volume - I wanted something comparable to MIDI CC 11, which often is used for relative volume and defaults to 127 = fully opened, so I could automate swells ans such on tracks without using the main volume fader (because in that case you're losing overall level control).
This plugin has two sliders: Volume and Smoothing. When you don't use smoothing you can easily hear steppings on quick automations, when you push it in, it's all gone.
I can send it to you in case you wanted to try for yourself (it's very handy sometimes).

While things might be way easier for such an easy plugin, I'm sure the principle behind it would be just the same for a filter.

From what I remember, Emagics ES1 was the first synth that didn't suffer from stepping when doing manual (or MIDI automated) cutoff movements. Meanwhile there's quite some more.

[9b0]

I'm no expert, but I don't know how this automatic interpolation with MIDI or GUI control is supposed to work. The host or the plug-in have no way of knowing how quickly you're moving the knob or plan to move a knob, so how can steps be smoothly interpolated?

Simply. By filtering the controller data with an envelope follower/filter so that the steps remove.

[renø]

The low MIDI resolution has nothing to do with that.
All digital sound generators and effects should implement parameter smoothing.

"Nothing"?
The low MIDI resolution has *something* to do with that.
Some digital sound generators were created *before* parameter smoothing. I'm keeping my old synths even if they step (because of MIDI resolution).

I think, parameter interpolation should be managed by the host you are using, but because no one of the hosts do the job, it's the duty of the developers nowadays to create instruments instead of "just" plugins.

agree with that. But the best to me would be the launch of an improved MIDI2. I guess it will never happen though - too much changes for home/project/pro/studios.

[fac]

I'm no expert, but I don't know how this automatic interpolation with MIDI or GUI control is supposed to work.

I'm not sure either, but here's my guess with linear interpolation:

Suppose your plugin uses only one parameter linked to some MIDI CC. Here's how I would process the current block:

function ProcessCurrentBlock(input, output, blocksize)
1) midicc_delta = (ReadMIDICC() - midicc) / blocksize
2) for i = 0 to (blocksize - 1) do
2.a) midicc += midicc_delta
2.b) parameter = MapFromMIDICC(midicc)
2.c) output = Process(input, parameter)

where

- midicc is the interpolated value of the MIDI CC
- ReadMIDICC() is a function which obtains the latest value sent by the MIDI controller
- MapFromMIDICC() converts a value from the MIDI CC range (0-127) to the parameter range
- Process() is the function which actually calculates the output (no read-ahead though).

[fac]

Oh, and most surely this can be optimized to calculate a parameter_delta instead of the midicc_delta, so only one sum per sample is required to interpolate each parameter.

[useruseruser]

I'm no expert, but I don't know how this automatic interpolation with MIDI or GUI control is supposed to work.

I'm not sure either, but here's my guess with linear interpolation:

Suppose your plugin uses only one parameter linked to some MIDI CC. Here's how I would process the current block:

function ProcessCurrentBlock(input, output, blocksize)
1) midicc_delta = (ReadMIDICC() - midicc) / blocksize
2) for i = 0 to (blocksize - 1) do
2.a) midicc += midicc_delta
2.b) parameter = MapFromMIDICC(midicc)
2.c) output = Process(input, parameter)

where

- midicc is the interpolated value of the MIDI CC
- ReadMIDICC() is a function which obtains the latest value sent by the MIDI controller
- MapFromMIDICC() converts a value from the MIDI CC range (0-127) to the parameter range
- Process() is the function which actually calculates the output (no read-ahead though).

Smart dude!
But your example actually would require, that there is a somehow "fixed" blocksize...

If the host divides the blocks into several small parts for some reasons, i.e. on note or controller events or with automation, then you could get blocksizes of exactly 1 or equally short amounts.

So what's then?

Right, your code dosn't work anymore and you get: clicks never the less.

The idea was not that bad and has potential to find a better solution.

[useruseruser]

I'm no expert, but I don't know how this automatic interpolation with MIDI or GUI control is supposed to work. The host or the plug-in have no way of knowing how quickly you're moving the knob or plan to move a knob, so how can steps be smoothly interpolated?

I'm not saying it can't be done-- I know that J&H has a heap more knowledge than I do, and Sascha Franck as well. I'm just curious about how it's supposed to be accomplished effectively or how other developers have already accomplished it.

In the meantime, I just use automation (or in the case of the Classic Auto Filter, 'automatic' modes, which do not step).

Greg

You are no expert?
Ah, yes... I know. You merely create "beta bugs"...

What's the matter with you?
You are developer! So can't you see a solution?

Of course, the host has no information about the speed, you twak the controls. It's not the host's job. But your plugin actually has. Because it "knows", how many sampleframes are inside a block. And it also knows probably, how a rapidly moved control should be handeled to not to produce any digital artifarkts...

[9b0]

Stepping occours because of the following problems:

- the MIDI bandwith is 1000 messages/second (audio samplerate is in the worst cases 44100 samples/seconds) This bandwith is much lower when you not only send automation, send out piano data, when you send MIDI data for more devices...

- the MIDI bit depth is a byte only

You can awoid one of this annoing problems if you tweak the knobs on a plugin with the mouse. If the plugin is programmed that way, it'll be able to send automation data even in 32bit floats to the host. The steps will still be there because of the refresh rate of the mouse wich can be tweaked in the registry higher, but makes the computer slower (makes no sense either...).

Another problem is that most of the hosts don't support high resolution automation and some of them not even use techniques like drawing automation with SPLines/lines/vectors. The mostly used pencil tool has very low resolution. Even if they would use a higher resolution for the pencil, the result would still suck because of the low resolution of the monitor. No one would edit automation in 1:1 resolution where you could only see an average of 1024 samples at once (depending from the monitor). SPLines/lines/vectors could send data in a customizable sample rate (offcourse higher samplerates would eat up CPU, so i think there wont be any improvement in the near future, because nowadays the most important question for everyone the CPU usage is... ). Ideal would be the sample rate of the sample, but even less then the 1/4 of it would be enough for removing steps.

Anyway. This problems can be handled very well with very low CPU usage in a plugin.

[useruseruser]

....

Sorry, but you completely missed the point.
And there are some questionable things in your theoretical excerpt above.

It can be done. Inside the code of the plugin itselfes. Period.

[9b0]

Sorry, but you completely missed the point.

It can be done. Inside the code of the plugin itselfes. Period.

I think, you missunderstood me. I wrote the reasons of the steps. We handled them well in our plugs (except NWEQ where it makes no sense).

And i also wrote this in my post:

Anyway. This problems can be handled very well with very low CPU usage in a plugin.

[useruseruser]

Please take my excuse !

[9b0]

[fac]

If the host divides the blocks into several small parts for some reasons, i.e. on note or controller events or with automation, then you could get blocksizes of exactly 1 or equally short amounts.

So what's then?

Right, your code dosn't work anymore and you get: clicks never the less.

As I said, I was making just a guess as I've never coded an audio plugin. Anyway, my example code avoids clickings caused by block processing, not the ones caused by quick changes in the controller or low MIDI CC resolution - the latter ones could be managed with a slew-rate limiter (ie.- an LPF) but then you would have a trade-off between smoothness and responsiveness.