Things to do for next releases

[Digitalone1]

For 8.1.1:

• Implement a clear_data function for some plugin class. playing new sound will play a already paused/stopped sound prev #3422
• Implement a voice suppressor. Vocal Isolation #1400

For 8.1.3:

• Fully exposing the global bypass control through CLI or the local server. CLI option "--bypass (-b)" stopped working #4402
• Reverting the tray icon changes unless a way to fix Tray icon in dark mode #4855 is found
• Implement a way to rename convolver impulse files like we do to preset files. Convolution filters with names too long cannot be deleted. #4905
• Blocklist KDE Plasma volume level meters.
• Stop using passive links. From PipeWire 1.6 onward they are not handled the same way. And problems like Kodi has no sound and I don't know whether to blame Kodi, EasyEffects, GNOME, or kernel 6.19 #4914 can happen.

For 8.1.6:

• Add explicit mnemonics. [Feature request] Explicit mnemonics in action texts #4504
• Increase decimals for some frequency controls. [Feature Request] Allow setting at least two decimal values ​​in the Frequency Hz fields. #4930
• Increase decimals for ratio controls. [Bug] It is not possible to set decimal values ​​for the Ratio parameter. #4931

[wwmm]

Ensure the new profile autoloading algorithm is working correctly.

With the last fixes I think this is as good as it can possible be. Based on what I heard from PipeWire developers even they have a hard time dealing with how much different one hardware is from another when it comes to headphones connection. There is probably nothing more we can do on our side until PipeWire itself has a major change related to headphone management that could provide us an alternative way.

[wwmm]

As everything in 8.0.1 list is done I will release it now.

[wwmm]

Configure the zita convolver to handle impulse responses with more of two channels.

I am looking at our convolver file and I think that before adding anything there I have to refactor it in a similar way as the pipewire and presets managers were. I will change 8.02 release target to this.

[Digitalone1]

As everything in 8.0.1 list is done I will release it now.

You didn't create the release tag.

[wwmm]

You didn't create the release tag.

I forgot 😄 . In the end it was a good thing. The latest round of weblate translations was included in the release.

[Digitalone1]

@wwmm When the Convolver is in a good state, we should make a release because some people are affected by the bug of the input text field.

[wwmm]

@wwmm When the Convolver is in a good state, we should make a release because some people are affected by the bug of the input text field.

As the refactoring had no effect over its qml files it should be possible to temporarily bring the previous class files back just for the sake of doing a new release. But I would like to investigate the convolver bug for at least one more day before having to resort to that.

[wwmm]

@vchernin After converting the manual to mkdocs I decided to make it an ordinary Github page. No offline mode anymore. What also means that Qt's webengineview is not a required dependency anymore and can be removed from the Flatpak package dependencies.

[wwmm]

I think that we finally have a good foundation for the manual/app site:

https://wwmm.github.io/easyeffects/index.html

https://github.com/wwmm/easyeffects/tree/master/src/contents/docs

Now it is just a matter of having time. And ideally more people contributing to fix outdated information.

[vchernin]

Now it is just a matter of having time. And ideally more people contributing to fix outdated information.

I feel now that everything is always on a webpage and formatted in markdown, we could maybe merge the wiki into the mkdocs setup. There doesn't seem to a very well defined difference between the two places besides the wiki being publicly editable. In both cases we want to encourage people to edit them.

If we merge them, it may also help contributions since there is one place to go to edit the docs/manual. Keep in mind it is possible to edit files in a GitHub repo (i.e. the new manual pages) using the browser editor. So you don't need to know git.

[wwmm]

If we merge them, it may also help contributions since there is one place to go to edit the docs/manual. Keep in mind it is possible to edit files in a GitHub repo (i.e. the new manual pages) using the browser editor. So you don't need to know git.

Yes. For now I just added to the manual some of the wiki's links 7.2.3. But we probably should merge them. The question is how. The idea would be moving the wiki text to the manual and in the wiki section put just a link to the manual website?