search

wwmm / easyeffects

Limiter, compressor, convolver, equalizer and auto volume and many other plugins for PipeWire applications
GNU General Public License v3.0
6.45k stars 269 forks source link

Plans for EasyEffects 7.0 #1316

Closed wwmm closed 1 year ago

wwmm commented 2 years ago

List of features planned for EE 7.0:

wwmm commented 2 years ago

what do you think?

It is fine. Only the name displayed to the user will be changed.

Digitalone1 commented 2 years ago

So I gave a look at the multiple instances. Great work, a big step forward for this project.

I see you changed keys from plugin#0 to plugin->0 which is better. Anyway some keys are going to remain in gsettings until another multiple instance is used.

In example, If I test 3 filters, I have filter->3 as the third instance. Then I change preset and do not reset all the filters. filter->3 will remain and it will stay until I don't make another preset with 3 filters.

The current state will leave a messy situation in gsettings with lots of unused keys, especially for those users which tests lots of configurations.

This is not our problem, we might argue that gsettings has to do something for unused keys, but this is not going to happen. dconf is even hanging when resetting paths with lots of keys.

So if we can do something easy to limit them, I think we should try. Unused keys were not a big problem for single instances, because the user could load the effect and click on reset button, but in the new configuration where the used could load up to 100 instances for every plugin, I don't like the app leaves lots of unused keys in gsetting without even try to clean them.

What can we do? Resetting them after removing the effect does not seem the solution. Because the same effects could be reloaded and it might take more time to load the next preset (even in the current state I feel a little lag while loading a new preset).

So I was thinking, maybe at the shutdown stage, before terminating the service? If it's doable, we should consider what to clean.

wwmm commented 2 years ago

What can we do? Resetting them after removing the effect does not seem the solution. Because the same effects could be reloaded and it might take more time to load the next preset (even in the current state I feel a little lag while loading a new preset). So I was thinking, maybe at the shutdown stage, before terminating the service? If it's doable, we should consider what to clean.

I think we should just favor performance and keep the unused keys there. I do not think it is worth the headache of trying to clean them. As GSettings puts everything in binary files and has no reason to iterate over unused keys their impact on performance is probably negligible if there is any... It is definitely annoying to see lots of unused keys in dconf when we open it but most users do not even know how to use dconf.

As you have already noticed the recursive reset is not that fast. Independently of where we try to do it we will just be slowing things down while trying to remove these keys.

bhack commented 2 years ago

Do we have some interesting info/data that we could expose on dbus? Having a gnome-shell extension to display some Easyeffects useful info integrated in the shell could be interesting..

vchernin commented 2 years ago

FYI there is already the presets gnome extension https://github.com/wwmm/easyeffects/wiki/Preset-Selector-GNOME-Extension

bhack commented 2 years ago

@vchernin Nice! Do we expose already peaks? They are nice to have live in the shell without switching the working context...

vchernin commented 2 years ago

It looks like the extension is just reading gsettings keys, so whatever happens to be stored in gsettings I guess is "exposed".

wwmm commented 2 years ago

Do we expose already peaks?

No. This would require dbus or something similar. But at least in my opinion dbus API is horrible to work with. Super verbose. Exposing all these level meters would be really tiring...

vchernin commented 2 years ago

But at least in my opinion dbus API is horrible to work with.

I also think it wouldn't work well for things like showing the spectrum if wanted since d-bus isn't very fast (some implementations are lower latency like zdbus in rust but that obviously won't help here).

bhack commented 2 years ago

Mhh yes probably it is better to create a client in the extension directly:

https://github.com/tmigone/pulseaudio

bhack commented 1 year ago

Do you think it will possible to have an implementation of ITU-T H.870

wwmm commented 1 year ago

Do you think it will possible to have an implementation of ITU-T H.870

I am not sure. I will need some time to read the document in more detail. At least in the EBUR 128 case I had to rely on a library. If this "safe listening protocol" requires too many operations writing a plugin totally from scratch may take quite some time.

bhack commented 1 year ago

Yes we cloud still use that library with eventually a small extension:

https://github.com/x42/meters.lv2/issues/35

On our side we need to handle the user input of few technical data like Headphone sensitivity, impedence and the AMP max vrms.

Then we could indicate recommended max db volume level and store the amount of time of the listening session.

wwmm commented 1 year ago

I have just released EasyEffects 7.0. With the exception of the spectrum and level meters update frequency improvement the main objectives were achieved. And it has already passed 2 months since the last release.

It is time to think about the candidates for the next major changes. The spectrum update frequency is probably going to be one of them again. But I still have no idea about how to fix it :-(...