easyeffects
easyeffects copied to clipboard
wwmm
Plans for EasyEffects 7.0
List of features planned for EE 7.0:
- Support for multiple plugins instances (it is going to be a tough one)
- Finding a way to make the spectrum and level meters update frequency independent of the server latency value
- Adding dry/wet controls to some plugins
In order to support multiple instances we will need to identify these instances in some way so we can bing them to the correct path in the GSettings database. One thing we could something like this
"plugins_order": [
"bass_enhancer#0",
"compressor#0",
"exciter#0",
"compressor#1",
"autogain#0",
]
And each plugin section would be named in the presets json file like
"limiter#2": {
...
}
In any case I think that the work on multiple instances has to start on these two files
effects_base.cpp plugins_box.cpp
The reason is that there won't be the need to think about the presets format while working on them. It should be possible to make the plugins map to be populated on demand as things are right now. Once that works we can start to think about multiple instances.
Another issue is how the multiple instances are saved in gsettings.
At this point I wonder if gsettings is really needed. I know it's advertised as faster for config management, but if we have to handle json files for loading/saving presets, may we use it the same to store the last config on the system and read/write directly from them?
At this point I wonder if gsettings is really needed. I know it's advertised as faster for config management, but if we have to handle json files for loading/saving presets, may we use it the same to store the last config on the system and read/write directly from them?
The json files for the presets are just one thing among many. Json does not allow us to bind settings directly to the widgets in the interface. I doubt we would gain simplicity by not using gsettings. We would probably be reinventing the wheel.
We would have a lot more coupling between different sections of our code. All those presets classes would have to either be passed to other places or receive instances from other places.
And without GSettings third party scripts or programs like dconf-editor won't be able to change our settings anymore. We will lose more than we will gain(if we gain something) by not using gsettings.
Another issue is how the multiple instances are saved in gsettings.
With relocatable schemas already in place the part related to gsettings is not going to be so hard. Consider this for example https://github.com/wwmm/easyeffects/blob/cd8967b53ec35203384d183fd4816d36c15ea24d/src/autogain_preset.cpp#L26 What we have to do is generating an unique path to be used by the instance. I think it could be something like
"/com/github/wwmm/easyeffects/streamoutputs/autogain#2/"
This way when the section autogain#2 from the json file is loaded we just have to load its settings to the database in the path "/com/github/wwmm/easyeffects/streamoutputs/autogain#2/"
In short my idea is to bind the instance associated to a given #id to a gsettings database in the path /.../plugin#id. As we already use g_settings_new_with_path that part should not cause too much trouble in theory.
But none of this will matter if we are not able to create and destroy filter classes on demand. That is why I think we have to start with this.
Yeah, you're right, we need gsettings in conjunction with json format.
As the things are now, paths in gsettings are pretty static, but with multiple instances they will become dynamic.
Now if I remove the equalizer from the stack, it still remains in gsetting and that's not a big issue. But in the future if I will make a weird preset with 6 equalizers, I would have 6 paths in gsettings related to equalizer.
Then I wonder what happens to equalizer#6 when afterwards I make a decent preset. It's destined to stay there forever and nobody will touch it, until I make another weird preset with 6 or more equalizers (or I manually clean the unused settings by hand with dconf, which is not a good experience as I remember).
I wonder also if writing so may unused settings in our root path may slow things down. Imagine I add 10 instances of all plugins, not to play something (I think the whole system would freeze), but just for fun.
If we could handle only json files, the things would be easier on this side, but we lose a lot on other sides, so gsettings has to stay. Anyway we should consider how to handle unused keys.
It's destined to stay there forever and nobody will touch it
Yes. This is one of the things I count as one of the few gsettings weaknesses. When we remove keys from our database they remain on the user system until he manually resets what is on the path.
I wonder also if writing so may unused settings in our root path may slow things down. Imagine I add 10 instances of all plugins, not to play something (I think the whole system would freeze), but just for fun.
No. They won't have an impact on performance because we would not be reading or writing the unused keys in let's say equalizer#100 if there is no equalizer in the pipeline or in the current preset loaded by the user. These keys will be inert in the database until a new equalizer#100 is created. Unless the user opens dconf-editor to view them he will not notice these keys even exist. It is not elegant but I do not see any harm to performance or disk space usage These keys go to a binary file managed by gsettings.
That being said we could try to reset these unused keys somehow. But it is definitely something to only be concerned about once we actually have multiple instances working.
Imagine I add 10 instances of all plugins, not to play something (I think the whole system would freeze), but just for fun.
GSettigns is fast for readings and slow for writings. In case the user is actually using 10 equalizers the performance cost of writing all these settings to the database is not much different from the one of saving 10 different filters like we already have now. There is still room for optimization in that. At this moment I compare the new and the current value to see if there is really the need to write something. But there is probably more that can be done like exploring the usage g_settings_delay and writing things in smaller chunks so that freezes are avoided or mitigated.
I could say for sure that gsettings resets only the keys it knows about. In fact I noticed that resetting the equalizer, the old keys not used in the latest EE versions were still there.
I think gsettings reset function is looping through existing known settings in the xml schema and then they are deleted. It's not looping through all existing written keys (under the targeted path) on the system. Anyway if we will call the reset function when the instances are destroyed, maybe they are really deleted. But this has to be tested.
Maybe with the current approach we are using to reset things will be different https://github.com/wwmm/easyeffects/blob/cd8967b53ec35203384d183fd4816d36c15ea24d/src/util.cpp#L346. But yes, it has to be tested.
What would be the use of other instance? To load an app with special plugins? When you close the instance and open again it will come with the previous configs? Or it will be without any?
There is some discussion about this on #656. Depending on what is being done it might make sense to be able to put in the pipeline more than one instance of some plugins like the limiter, compressor, filter(low-pass, band-pass, high-pass), etc. It is not per application effects. It will still be the same effects pipeline for all of them.
How about add tray icon with quick profile switching functionality? Or add profile rules for apps
How about add tray icon with quick profile switching functionality?
Hi @IDeathByte. Already discussed at #300 and #544.
Or add profile rules for apps
Too difficult to implement. #1145
Tray icons are not happening. As GTK does not support them anymore we would be fighting against our graphical toolkit. What would not be productive.
I seriously doubt different effects for different applications will ever happen. Easyeffects would have to be completely changed. There are some open issues discussing that.
Could a smoother spectrum visualizer be a goal for 7.0?
It could. But the problem is that at this moment I have absolutely no idea about how to solve it.
I miss the great design of Pulseeffects, really splendid. In GTK4 everything is too big, the buttons, bars, fonts ... but the same happened with the transition from GTK2 to GTK3... in the end, you get used to it :(
It would be nice to add some graphical element and text in the spectrum visualizer/equalizer for the frequency clusters/names:
Sub-bass: 16 – 60Hz
Bass: 60 – 250Hz
Lower midrange: 250 – 500 Hz
Midrange: 500 – 2kHz
Higher midrange: 2 – 4kHz
Presence: 4 – 6kHz
Brilliance: 6 – 20kHz
https://www.headphonesty.com/2020/02/audio-frequency-spectrum-explained/
It would be nice to add some graphical element and text in the spectrum visualizer/equalizer for the frequency clusters/names:
The problem is finding space in the window for them. And there is also the problem that these frequency ranges are somewhat arbitrary. It would not take long to have people requesting them "to be fixed".
I think that we could find a space as e.g. with Rtings graphs or other measurement tools: https://www.rtings.com/headphones/tests/sound-quality/raw-frequency-response
We could take a default reference standard (Rting, etc..) and let the user change the range in the preferences (where we select already also other spectum graph options)
Suggestions:
- moving away from tablet/mobile UI/UX, why everything is HUGE? it is not optimized for mouse/keyboard at all
- option to disable UI animations
- performance improvements (with 3 plugins, it's sitting at ~0-20% cpu usage when there is audio playing
- adding high-level, user friendly options, such as "loudness", like on windows:
moving away from tablet/mobile UI/UX, why everything is HUGE? it is not optimized for mouse/keyboard at all
I do not see what in EasyEffects window is being optimized for tablet or mobile devices. I do not even have one running Linux. GTK developers may have such targets. But in this case whatever it is you have in mind has to be done at the toolkit level.
I use mouse all the time when using EasyEffects. So I honestly do not understand what you mean by that.
option to disable UI animations
Another one that has to be properly implemented at the toolkit level. But I wonder what is the problem with the animations. At least on my computer they are so subtle I do not even think about them.
performance improvements (with 3 plugins, it's sitting at ~0-20% cpu usage when there is audio playing
Almost all of the plugins used in EasyEffects are from third party projects that have audio engineers and musicians as target. They are not developed to be used by us. Changing these plugins code is out of my reach. Not only because I am not the one developing them but because of lack of knowledge too.
Some algorithms are heavy on resources. It is annoying but it is life. How noticeable that is depends on the CPU. Which one do you have? On my Ryzen 3700 X I do not even notice EasyEffects is running.
Some plugins like the maximizer, the bass enhancer, crystalizer, etc are a lot heavier than the others and a powerful cpu is recommended. Specially in the occasions where PipeWire switches to low latency.
adding high-level, user friendly options, such as "loudness", like on windows:
This is not going to happen. We offer one compressor, one multiband compressor, 2 loudness plugins and one autogain plugin based on the EBUR128 standard for loudness estimation. Different ways are already provided for the user to deal with loudness correction.
- adding high-level, user friendly options, such as "loudness", like on windows
How would you implement it? I made one preset inspiring on it (I published it in my repository), but don't know if it really reflects what Windows is doing. Maybe a user just need the only Autogain plugin, but I don't like it.
but don't know if it really reflects what Windows is doing. Maybe a user just need the only Autogain plugin, but I don't like it.
As the description talks about perceived volume I imagine that under the hoods the Windows plugin is either using loudness curves and a compressor to correct audio or the EBUR128 standard through some kind of autogain. In any case it is probably more than just a compressor.
I use our autogain plugin all the time. Like any other method for automatic volume correction it is not perfect. But at least for my needs it is has been doing a great job.
I do not see what in EasyEffects window is being optimized for tablet or mobile devices. I do not even have one running Linux. GTK developers may have such targets. But in this case whatever it is you have in mind has to be done at the toolkit level.
This is an interface for Touch devices
The problem is using GTK4/Adawaita, it is very opinionated UI toolkit that seems to target a wide range of devices, with a focus on touch driven input
I don't know what is scrollable, i don't know what is a button, i don't know what is a slider, everything is HUGE, everything is spread, there is no identity, no colors, nothing properly aligned
This is the settings menu from iOS...
Constantly asking the user to scroll, scroll, scroll, huge buttons as if i was running the app on a small iPhone screen... just bad
Another one that has to be properly implemented at the toolkit level. But I wonder what is the problem with the animations. At least on my computer they are so subtle I do not even think about them.
It is a problem because of the issue above, it looks like it is trying to mimic the swipe feature of touch driven UXs
Sorry to feel very negative, but i'm just disappointed at the state of UIs on linux
For comparison, macOS app, no huge 128x128 checkboxes, everything properly packed and properly aligned, no waste of waste
https://user-images.githubusercontent.com/44361234/155257699-900b8465-bb77-48d4-9d1a-35882a97af19.mp4
I am not a fan of the direction desktop linux is taking with gnome
How noticeable that is depends on the CPU
with just 3 plugins... on an i5 10400
The preset if someone is interested: https://gist.github.com/ryuukk/1702e352b4de3217cad1e971cb46e181
with just 3 plugins... on an i5 10400
It isn't so bad. That 30% you are seeing does not mean 30% of a maximum of 100%. It is 30% in a scale that goes up to 12 * 100 = 1200%. That is how the default top configuration measures CPU usage.
Linux for desktop is heading towards a funest and dark future
Although there is a fair amount of personal opinion when it comes to this topic I can understand how you feel. Personally I have no problems with the direction GTK is going. The thing is that the kind of things you do not like are partially in the theme design domain. They can't really be fixed on our side because we have no control of what theme the users are using. A fix may play nice with some themes and not with others. So whatever "solution" is tried for this it has to be on the toolkit level.