[Request] Allow multiple instances of effects

[parras]

Currently, each effect has exactly one instance. It would be very nice to be able to duplicate effects, or IOW to have several instances of each effect. This makes sense in particular for the multiband compressor and limiter that frequently need to be present at multiple stages of the processing chain, for instance for broadcasting.

[wwmm]

This will require a lot of work. The problem is that becoming like Ardour or LMMS was never the intention. So PE code does not have the required flexibility in its foundation. For example our preset system as well as the code used to remember the last used setting is very tightly integrated to GSettings. And handling multiple plugins instances with GSettings keys defined in xml files will be a little challenging as far as I know. As things are right now they will touch the same keys. The logic used to change plugins position in the chain will probably need some rework too.

But who knows. Let's keep this open and see what happens in the future.

[Digitalone1]

A more simple workaround to this would be implementing few other plugins from other studios.

For example, I though it was a bad idea removing calf linear compressor to add lsp sidechain compressor. Even if I prefer the lsp one, it's a different type of compressor, maybe other users prefer the linear one that takes in consideration all the frequencies rather than middle or side parts only.

There are also other multiband compressor from lsp or zam audio.

[Digitalone1]

@parras Can't be done now with multiband compressor, but you can tweak the maximizer to behave like a second limiter.

[parras]

@Digitalone1 Indeed, that's what I'm currently doing! BTW I like your idea of having several equivalent effects from different providers as a workaround.

[wwmm]

I can see the point but offering different variants of the same kind of plugin adds a development and maintenance burden I can't take. We can't use the plugin's native graphical interface like Ardour does. So I have to write a custom interface for each plugin as well as write code for the presets to work. Defining keys in each plugin GSettings xml, binding these keys to each parameter, etc. The approach that can be taken right now is having one plugin for each kind of task. So the plugin that offers more functionality is chosen.

The obvious solution would try to be like Ardour and letting the user add whatever plugin he/she wants. But as I said above this is far from trivial. We must be able to show the built-in plugin interface. This probably requires to write a LV2 and LADSPA host. And as we use GStreamer to handle our pipeline these built-in hosts will have to interact with GStreamer somehow. An alternative solution that may be even harder would be to add graphical interface support for the GStreamer's LV2 and LADSPA wrapper. We would also have to completely replace our presets system by something else more appropriate.

It would be cool to have all of this? Yes. But I don't see this happening any time soon.

[parras]

Thanks for the extensive explanation @wwmm ! No worries, PulseEffects is already awesome as it currently stands. Given the effort needed to implement this RFE vs the added value, it is definitely not worth it.

[Digitalone1]

@wwmm Thanks anyway for your work.

If in the future I want to add a plugin, which steps should I follow?

• looking for the gstreamer plugin
• make a new class for the new plugin
• define the default settings for the new plugin
• bind gstreamer plugin settings to exposed settings in the UI
• build the UI
• load the new plugin in the gstreamer pipeline

And... what else?

When loading a preset, if a setting is missing, the method is applying the default value, right?

[wwmm]

Yes. If a setting is missing in the preset a default value should be loaded.

Besides the points you have already listed it is also necessary to update the plugin list in these files:

https://github.com/wwmm/pulseeffects/blob/master/data/schemas/com.github.wwmm.pulseeffects.sinkinputs.gschema.xml

https://github.com/wwmm/pulseeffects/blob/master/data/schemas/com.github.wwmm.pulseeffects.sourceoutputs.gschema.xml

You only have to update both files if the plugin is used in both pipelines.

[Digitalone1]

@wwmm When I have time I can work on adding the calf compressor, previously used by PulseEffects in place of the sideband one. With it the user has more choices, since wideband and sidechain are two different types of compression and for the downward I always preferred the wideband from calf.

If I would be able to do it, will you accept the pull request? Thanks.

[wwmm]

First I would like to make sure this is really needed because as far as the docs https://lsp-plug.in/?page=manuals&section=compressor_stereo and the plugin parameters go it is a wideband compressor. It does not seem to be applying different compression ratios for each frequency band. If it were it would be a multi band compressor.

Looking at Calf source the default value for stereo_link makes it taking the average of both channels https://github.com/calf-studio-gear/calf/blob/0f45a436b729e71cc975d82beb4f369026e5db9f/src/modules_comp.cpp#L588. This is the same that lsp does in its sidechain when you set source to middle https://github.com/sadko4u/lsp-plugins/blob/a6a8e9ca03429899e2514da9d56feaccc0a2ec7d/src/core/util/Sidechain.cpp#L146

It is not that I doubt that you are able to hear a difference between them. I just want to make sure that there really is a point in offering 3 compressors. That it is not possible to configure lsp compressor to behave in a similar way as the one from Calf. I did not see this yet.

[Digitalone1]

Not really. I'm not an expert, but as far as I understood, the lsp compressor in PE uses only the middle part (central frequencies) or the side parts (low and high frequencies only, and as an optional choice, only one of the channel) as sidechain signal for the compression stage. I never liked this, at least for downward compression.

In fact, the calf manual explains this better:

Normally a compressor uses the full range signal to detect a level above the threshold. A sidechain compressor provides a filter (or equalizer) for the detection signal to reduce the bandwidth or to remove some frequencies from it.

This means that if you set middle, only the amplitude of the central part of the signal is meaningful for the compression. If you have peaks in side parts, those are ignored. This behavior may be useful in certain situations, but not in others and personally I don't prefer it. In contrast, wideband compression (the old one used by PE) analyzes the full range.

Sure they are compressors, but different types and I was never able to get the lsp one behave like calf one, even at the hardest settings. To me the sidechain is only good for upward, not for downward.

Anyway, I don't know if I'm able to reintroduce it in PE, I'm a web developer, not a c++ programmer. Maybe I can take the old code and make some changes to stick it inside the pipeline. But if you won't accept the pull request, I won't even try.

[wwmm]

I understand your concerns but I think you are confusing a few concepts. When talking about the stereo matrix middle does not mean you are doing a frequency filter. You just add the left and the right channel signals together and divide by 2. If you look at the Calf compressor source in the link I pasted above you will see that it does that if you enable stereo_link. What I think is the default behavior. The difference here is that lsp compressor allows you to do something else to the signal. Like using the side signal. That if I am not mistaken is obtained by subtracting one channel from the other. Again no frequency filtering is done.

And I am not sure that what Calf manual is saying about sidechain compressors is mandatory. LSP compressor does have a low pass filter available in its sidechain settings. So Calf description makes total sense IF you tell the compressor to use this filter for example. I did not look lsp compressor sources in depth yet but it did not seem at first site that there is some kind of frequency splitting that is always enabled.

[wwmm]

When I say no filtering I mean in the usual sense of the word. Once you subtract the signals the content that is common to both channels will be cancelled. So when using side you will throw something away. Probably the low frequencies as they are more or less equally distributed between the channels.

My point is that you do not have to use the side option in lsp. middle will do the same as Calf. If there is still some difference after that it is coming from one of the other options in lsp compressor.

[Digitalone1]

You're right. I was confused because the sidechain is too difficult to set and I misunderstood the middle option. I noticed now that choosing peak mode is similar to the calf compressor.

Thank you @wwmm.

[wwmm]

In Calf compressor you can also choose between rms and peak. But I do not remember which one is the default.

[DanMan]

Is this easier/possible to implement in EasyEffects now that "plugins" can be added/removed individually? Would be nice to be able to add 2 equalizers. One to load an APO preset and one to adjust for taste/preference/hearing correction.

[wwmm]

Is this easier/possible to implement in EasyEffects now that "plugins" can be added/removed individually?

This new feature helps us to go in this direction but we are not there yet. The presets infrastructure and the filter linking system is not ready for multiple filters instances.

Would be nice to be able to add 2 equalizers. One to load an APO preset and one to adjust for taste/preference/hearing correction.

How many bands does your APO preset use? Our parametric equalizer has 32 bands. Depending on the situation and on the desired audio effect you could try to use some bands for the APO preset and the others for more corrections. It may not be exactly the same as putting another equalizer after it but the result may be very close.

[DanMan]

The APO preset for my headphones uses 10 bands. I shall try what you suggest.

Edit: since the link above also provides .wav files, I solved it by using those with the Convolver to correct the audio, then use the EQ however I want.

[wwmm]

Implemented in the current master branch.