S and Q values on Multiband Compressors and Limiters?

[JonnyCodez]

Hi, I'm Jonny, please forgive my clunky newbieness, I have been soaked in the world of sound.

I have been using your fantastic plugins for about 2 years now with ardour, they're really great to use. I have been a heavy user of your multiband compressors and limiters, very powerful, my compliments.

I have noticed that with the new versions of the Multi band compressor and limiter it is no longer possible to modify the Q ans S values at the crossover point. This was amazingly powerful functionality once I finally got my head around it and I invested a lot of time sculpting a sonic framework using this functionality.

The results have been incredible. It allowed me to shape the sound into this phat, snappy and open soundscape. It was a lot of work and I am hoping I don't have to try to re-create now that I'm upgrading from Ardour3 to Ardour4. Please help!

Please don't take that as a criticism of the new version of the multiband limiter/compressor either, they have the graph feature I was hoping they would have so I could see the S and Q changes.

Is it possible to access this S and Q functionality on the new versions? I am happy to modify a save file if that could work?

Alternatively, can I install the old version for use with Ardour4? It has a date of 2008-02-09 in the manual page and my current version has 2015-03-03. This was upgrading from Mint 16 to Mint 18.

My apologies if I have missed a previous discussion on this and if I have perhaps you can direct me to it. I totally understand that you guys are doing this for love of sound, which is really appreciated. I am totally happy to supply pizza and beer as I am a great fan of your work.

Thanks
Jonny

[JonnyCodez]

I tried to install the 0.0.19 version with the Mint 18 0.0.60 version (hoping I could install the two versions side by side) and that just made a mess of duplicate plugins in Ardour.

For now I'll just install the 0.0.19 version because that is what my project has been using, maybe I can find a way to get them side by side.

I also wrote a shell script to convert the saves from 0.0.19 version to the 0.0.60 version, however I'll post that in another thread for clarity.

I really hope you add the S and Q functionality back to the multuband compressors and limiters sometime.

Thanks for a great set of plugins.

[JohannesLorenz]

@boomshop Many LMMS users may have S and Q values in their savefiles, which would be ignored by the current CALF. I'd like to implement this and make a PR if you're OK with that.

[boomshop]

Feel free. Please keep in mind that all new parameters have to be added at the end of the current list in metadata.cpp. Otherwise it will break backward compatibility on some hosts. And personally I'm quite picky about the UI ,) but let's see what you'll come up with.

[JohannesLorenz]

@boomshop As we don't need the UI in LMMS, I'd only do the parameters, and leave the UI up for you or anyone else to complete later. Hopefully that is OK.

[boomshop]

Hopefully that is OK.

Sure!

[JohannesLorenz]

Please keep in mind that all new parameters have to be added at the end of the current list in metadata.cpp. Otherwise it will break backward compatibility on some hosts.

@boomshop I'm just looking at the code. In 0.0.18, you had "stuff S+Q stuff", and now in 0.90.0 it's "stuff stuff". Your proposal, inserting "S+Q" after "stuff stuff", would break compatibility for LMMS savefiles.

Wasn't removing "S+Q" a break of compatibility already? Wouldn't it be better to re-insert "S+Q" at its old position (between "stuff" and "stuff")?

[boomshop]

Hey Johannes,

sorry for the late reply.

Wasn't removing "S+Q" a break of compatibility already? Wouldn't it be better to re-insert "S+Q" at its old position (between "stuff" and "stuff")?

This would mean even more breakage for Calf users so I would like to avoid it. We decided to not mix up the current sequence of parameters any more but add new stuff at the end of the list instead.

[JohannesLorenz]

Trying to implement it, I stumbled over this switch-statement. It currently does set the Q values depending on the mod. In order to re-add knobs for the Qs, I'd have to remove this code. This might give incompatibilities for users who rely on the current behaviour.

I don't see a good alternative to removing the switch-statement. Would this be OK for you?

[boomshop]

It's not possible to remove the current behavior since these are fixed values for linkwitz-riley filters Q in use.

[JohannesLorenz]

Sorry, I didn't fully understand what you mean.

1. Do you mean that the only filters that sound good for Multiband Compressor, Gate and Limiter are Linkwitz-Riley filters? I.e. only those from that switch statement?
2. If a user has an old LMMS savefile where the filters were not Linkwitz-Riley,

• Should we discard their values and "bash" their old filters to Linkwitz-Riley?
• If not, how can we best integrate old LMMS savefiles? Maybe patch their mode to 3 (not yet used), which would be the only case where crossover would use custom Q values? I.e. like this?

float crossover::set_filter(int b, float f, float _q, bool force)
{
// ...
    switch (mode) {
        case 0:
        default:
            q = 0.5;
            break;
        case 1:
            q = 0.7071068123730965;
            break;
        case 2:
            q = 0.54;
            break;
        case 3:
            q = _q;
            break;
    }
// ...
}

[boomshop]

The filter design for crossover filters should be linkwitz-riley since those don't alter the frequency response, i.e. completely flat response. That's what you normally want. Manual Q and separation settings will destroy the response, that's why I switched to a fixed, linear setting.

An additional mode could be used for custom Q and S values as you proposed. I don't think we'll go any higher in steepness i.e. adding a fourth LR mode.

[JohannesLorenz]

@boomshop Thanks for the good explanation. This is probably a good reason for CALF to not implement Q in the future, right? If that's true, LMMS would stay conform with CALF here and smash the Q values out, too.

Per the S values: Looking at the old code, it just seems to separate LP and HP:

lpL[0][0].set_lp_rbj((float)(*params[param_freq0] * (1 - *params[param_sep0])), /*...*/);
hpL[0][0].set_hp_rbj((float)(*params[param_freq0] * (1 + *params[param_sep0])), /*...*/);

I guess that parameter would not change the frequency response. Why did you remove it, and are you even planning to re-add S values?

[boomshop]

Separating the center frequencies of the crossovers results in a non-flat frequency response, too. I visualized it for better comprehension:

BTW look at the shitty code I once wrote - it just pushes the center frequencies apart linearly without taking the logarithmic scale into account. The separation is very small so it doesn't make a huge difference (that's why I didn't care about it), but it's still far from splendid achievement so it would be better to not put it back into Calf.. just sayin'.

[JohannesLorenz]

Oh, I didn't think of this, too... The graphic explains it well.

In this case, LMMS won't add the seperator values aswell. After that discussion, I wonder if you want to close this (your project's) bug as won't-fix or something. Though some people might want to abuse this for some crazy effects (like the OP said).

[boomshop]

It even would be much easier to use an equalizer to alter the frequency response that way, no need to abuse the crossover for this. So yes, "won't fix".