Plans for EasyEffects 7.0

[wwmm]

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

[wwmm]

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.

[Digitalone1]

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?

[wwmm]

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.

[wwmm]

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/"

[wwmm]

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.

[wwmm]

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.

[Digitalone1]

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.

[wwmm]

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.

[wwmm]

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.

[wwmm]

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.

[Digitalone1]

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.

[wwmm]

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.

[servimo]

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?

[wwmm]

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.

[servimo]

Sorry, I was thinking about other instance of EE.

[IDeathByte]

How about add tray icon with quick profile switching functionality? Or add profile rules for apps

[Digitalone1]

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

[wwmm]

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.

[7RST1]

Could a smoother spectrum visualizer be a goal for 7.0? (resolves #1001)

[wwmm]

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.

[saltasatelites]

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 :(

[bhack]

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/

[wwmm]

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".

[bhack]

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)

[ryuukk]

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:

[wwmm]

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.

[Digitalone1]

• 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.

[wwmm]

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.

[ryuukk]

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

[wwmm]

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.

[wwmm]

It isn't so bad.

I mean when looking at the whole CPU. 30% of one core is not pleasant. But it is what it is...

The preset if someone is interested: https://gist.github.com/ryuukk/1702e352b4de3217cad1e971cb46e181

That is what I get with your preset on my Ryzen 3700 X with your preset while keeping EE window opened. It will use less CPU with its window closed. The multiband is not the heaviest plugin used in EasyEffects but it requires some processing power. And if its author did the same approach he did on his other plugins the code is already using vector instructions like SSE, etc. I doubt there is a lot of room for optimization.

[Digitalone1]

@ryuukk maybe EasyEffects is not for you. Why do you use it?

You can have an extended choice of plugins using carla-rack with pw-jack. The plugins can be customized with the native UI. Here is an how-to.

[ryuukk]

That is what I get with your preset on my Ryzen 3700 X with your preset while keeping EE window opened. It will use less CPU with its window closed.

When closed it go down to 15% when audio is playing, that's better!

@Digitalone1

I use EasyEffects because it allows me to achieve good results, i'm not complaining about it, it's a great program

I'm having difficulties with the way the UI/UX is, that's it

After reading my post above, i sound very rude.. i apologies, i should be more respectful, i edited it to remove non-necessary complains

[wwmm]

After reading my post above, i sound very rude.. i apologies, i should be more respectful, i edited it to remove non-necessary complains

No problems. The "GTK direction" is a somewhat emotional topic. And people have the right to not like that direction. In time when gtk4 usage becomes more widespread someone will probably write a theme for it customizing these spaces and the size of the widgets. It is probably the only way to properly "fix" this for people that do not like the default style. If we apply custom css rules on our side we will probably be forcing everybody to have the "small size" approach. And the people who like it will complain. So for us it is better to follow the default GTK style as much as possible.

[bhack]

Also if you have any other constructive feedback you can always interact with the upstream Team/proejct at:

https://gitlab.gnome.org/Teams/Design/hig-www

[Digitalone1]

I'd like to refer to this post to add some hints.

The players/records view needs work. I don't see one row needs to take up so much space.

That's right. Moreover the volume switcher prevents to scroll the page ending on changing the app level. I will think about another layout.

The function of the GtkSwitchers is unclear. The "blocklist" feature is unclear. State "running" apps should probably be at the top.

It's surprising to me that the enable switch could be unclear. We could add an Enable label. Blocklist is not a beautiful word (and before it was blacklist which we changed), I did not literally translated it in my language because there's other more intuitive. I think we should change to something like Excluded Apps or Not Handled Apps...

Overall, pages etc probably need some text explaining what's going on. For example, the Input plugins are applied before going into the recorder.

This is a never ending problem. We added the arrows, but it's not enough. Adding the name of the device is tough because that column is narrow and the name could be very long.

The app is called "EasyEffects" but the word "Effects" does not appear in the UI. Probably "Plugins" should be named "Effects"?

That's not a bad idea and it's easy to implement. We can just change the label.

Empty states are mostly not handled. Needs things like "Currently no app recording audio" etc

I never thought about that, but it's right. Opening the application and seeing a blank page because no app is being processed is not really good. An idea that came to my mind is adding a widget under the app list which inform the user that no application is handled by EasyEffects. First though was "No application is playing/recording", but that's not really right because an app could be blocklisted/excluded, but still reproducing and not shown in the list.

Then, when the list is populated, that widget is hidden. We should have a counter of the entries in the list somewhere. There should be easy to hide it when the count is greater than 0.

Took me a minute alone to find the delete button in presets autoloading (the scrollbar at the bottom does not scroll the relevant UI). Great feature, took me too long to understand.

That's right. I think it's a scroll bar bug of GTK4, but the real issue there is that the delete button is hidden when the window width is reduced. Should be always visible at any size.

HIG would require the app name to be written with a space: Easy Effects

Well, maybe not for 6.x versions, but from 7.0, since lots of changes will be added (multiple effects instances the big one), should not be a big issue adding a space in the app name.

Anyway, these hints are not for joining Gnome Circle, I don't care, I only think they will improve the application and could be implemented.

[wwmm]

An idea that came to my mind is adding a widget under the app list which inform the user that no application is handled by EasyEffects.

I almost did that but other things had higher priority at the time. Take a look at libadwaita demos. They do that in each example introduction page. I did not look at the code in detail but I think that the same approach can be used here too.

[wwmm]

Took me a minute alone to find the delete button in presets autoloading (the scrollbar at the bottom does not scroll the relevant UI). Great feature, took me too long to understand.

I am honestly having a hard time trying to understand how that icon could not be visible in an ordinary use. I have to reduce the window width to a ridiculously small size for the horizontal scrollbar to even be active.

[mcarans]

I think dry/wet settings for relevant effects like noise reduction would be a great improvement.

[bhack]

Can we simplify the visibility to the current profile in use without requiring a specific click?

EXTRA: Can we use any UX trick to inform the user if the profile in use is exactly as loaded or it is in a "modified/derived" status?

[Digitalone1]

EXTRA: Can we use any UX trick to inform the user if the profile in use is exactly as loaded or it is in a "modified/derived" status?

Not impossible but difficult because the label showing the preset name is just the "last preset correctly loaded", used to get it from gsettings at the next startup (if no autoloading preset is configured).

Improvements have been made to inform the user about the case of loading failed, but showing the current/derived state is very tricky.

[wwmm]

And on top of what has been already said by @Digitalone1 there is the fact we have 2 pipelines. So any solution to this will have to also make it clear to which pipeline the preset was applied. In my opinion it is better to keep things as they are.

[Digitalone1]

Continuing from the discussion...

Most if not all of the refactoring needed for them is done. Now comes the hard part that is deciding how to name each instance and how to generate their paths in gsettings, etc. Initially I thought about something like compressor#1, compressor#2,compressor#3, etc but besides the fact I still have to see which characters are allowed or not in the gsettings xml there is also what todo if compressor#2 is removed while compressor#3 is still supposed to be in the pipeline. Changing the index of the plugins that are still in the pipeline do not seem the right thing to do. But then if the code creating the names just reads the last index and the user creates another compressor we would have compressors 1,2 and 4 what is a little strange and may have to be taken into account in some places.

I think the safest way to do this would be generating a unique key which is unique for the preset and it does not depend on the order.

The matter would be how to generate the key. Anyway I suppose we should also track the unused keys and reset them, otherwise we leave a mess in gsettings if the user tries lots of presets.

I also would like to not break compatibility with old presets again... And Ideally I would like to have gsettings paths ending like compressor/instance#0, compressor/instance#1, etc. But If I do this the current settings will be ignored when the new version starts. So we probably will need a hybrid approach where the first instance uses the current path but the others are created somewhere else. Either under compressor#1 and so on or compressor/instance#1. In other words as a "sub path" of the "default instance".

If this brings complexity, I think introducing a new format would be more convenient.

[wwmm]

As expected it took a really long time to implement multiple filter instances. But it is finally possible to play with it https://github.com/wwmm/easyeffects/tree/filter_instances. As far as I could see our current preset files can be loaded. What is still to be done is actually being able to save a preset file that takes into account multiple instances. What happens now is that the last instance overwrites the fields of the others in the preset file. But this is something I should be able to implement in the next days.

In any case it is in a state that can be tested.

[wwmm]

I have updated the master branch with the multiple filter instances code. Let me know if there is something broken. Users will have to manually load a preset to restore their settings after updating but other than that things should be normal.

[Digitalone1]

I can't apply my presets to equalizer.

The following was saved from the previous format:

JSON preset

``` { "output": { "blocklist": [], "equalizer#0": { "balance": 0.0, "bypass": false, "input-gain": 0.0, "left": { "band0": { "frequency": 32.0, "gain": 3.5, "mode": "RLC (BT)", "mute": false, "q": 1.6, "slope": "x1", "solo": false, "type": "Bell" }, "band1": { "frequency": 64.0, "gain": 2.0, "mode": "RLC (BT)", "mute": false, "q": 1.6, "slope": "x1", "solo": false, "type": "Bell" }, "band2": { "frequency": 128.0, "gain": 1.0, "mode": "RLC (BT)", "mute": false, "q": 1.6, "slope": "x1", "solo": false, "type": "Bell" }, "band3": { "frequency": 256.0, "gain": 0.0, "mode": "RLC (BT)", "mute": false, "q": 1.6, "slope": "x1", "solo": false, "type": "Bell" }, "band4": { "frequency": 512.0, "gain": -0.5, "mode": "RLC (BT)", "mute": false, "q": 1.6, "slope": "x1", "solo": false, "type": "Bell" }, "band5": { "frequency": 1024.0, "gain": -1.5, "mode": "RLC (BT)", "mute": false, "q": 1.6, "slope": "x1", "solo": false, "type": "Bell" }, "band6": { "frequency": 2048.0, "gain": -0.25, "mode": "RLC (BT)", "mute": false, "q": 1.6, "slope": "x1", "solo": false, "type": "Bell" }, "band7": { "frequency": 4096.0, "gain": 1.25, "mode": "RLC (BT)", "mute": false, "q": 1.6, "slope": "x1", "solo": false, "type": "Bell" }, "band8": { "frequency": 8192.0, "gain": 2.75, "mode": "RLC (BT)", "mute": false, "q": 1.6, "slope": "x1", "solo": false, "type": "Bell" }, "band9": { "frequency": 16384.0, "gain": 3.0, "mode": "RLC (BT)", "mute": false, "q": 1.6, "slope": "x1", "solo": false, "type": "Bell" } }, "mode": "IIR", "num-bands": 10, "output-gain": 0.0, "pitch-left": 0.0, "pitch-right": 0.0, "right": { "band0": { "frequency": 32.0, "gain": 3.5, "mode": "RLC (BT)", "mute": false, "q": 1.6, "slope": "x1", "solo": false, "type": "Bell" }, "band1": { "frequency": 64.0, "gain": 2.0, "mode": "RLC (BT)", "mute": false, "q": 1.6, "slope": "x1", "solo": false, "type": "Bell" }, "band2": { "frequency": 128.0, "gain": 1.0, "mode": "RLC (BT)", "mute": false, "q": 1.6, "slope": "x1", "solo": false, "type": "Bell" }, "band3": { "frequency": 256.0, "gain": 0.0, "mode": "RLC (BT)", "mute": false, "q": 1.6, "slope": "x1", "solo": false, "type": "Bell" }, "band4": { "frequency": 512.0, "gain": -0.5, "mode": "RLC (BT)", "mute": false, "q": 1.6, "slope": "x1", "solo": false, "type": "Bell" }, "band5": { "frequency": 1024.0, "gain": -1.5, "mode": "RLC (BT)", "mute": false, "q": 1.6, "slope": "x1", "solo": false, "type": "Bell" }, "band6": { "frequency": 2048.0, "gain": -0.25, "mode": "RLC (BT)", "mute": false, "q": 1.6, "slope": "x1", "solo": false, "type": "Bell" }, "band7": { "frequency": 4096.0, "gain": 1.25, "mode": "RLC (BT)", "mute": false, "q": 1.6, "slope": "x1", "solo": false, "type": "Bell" }, "band8": { "frequency": 8192.0, "gain": 2.75, "mode": "RLC (BT)", "mute": false, "q": 1.6, "slope": "x1", "solo": false, "type": "Bell" }, "band9": { "frequency": 16384.0, "gain": 3.0, "mode": "RLC (BT)", "mute": false, "q": 1.6, "slope": "x1", "solo": false, "type": "Bell" } }, "split-channels": false }, "limiter#0": { "alr": false, "alr-attack": 5.0, "alr-knee": 0.0, "alr-release": 50.0, "attack": 10.0, "bypass": false, "dithering": "None", "external-sidechain": false, "gain-boost": false, "input-gain": -5.0, "lookahead": 10.0, "mode": "Herm Thin", "output-gain": 0.0, "oversampling": "Half x4(3L)", "release": 20.0, "sidechain-preamp": 0.0, "stereo-link": 100.0, "threshold": -1.0 }, "plugins_order": [ "equalizer#0", "limiter#0" ] } } ```

[Digitalone1]

I thought it was the new format, but also loading the former one the preset is not applied to the equalizer. There should be something wrong with the equalizer preset reading. @wwmm did you test all the plugins? Limiter and compressor seems working correctly.

[wwmm]

There should be something wrong with the equalizer preset reading

It seems that the band parameters are not being applied. Others like the number of bands and the mode are working. I will take a look at it.

[wwmm]

The values were being loaded to the old path that does not take the instance id into account. It should be fine now.

[Digitalone1]

I'm compiling the latest master.

Meanwhile I'd like to talk about the splitting of the app name. We were told about that in the submitting for Gnome Circle.

Here are explained the guidelines: https://developer.gnome.org/hig/guidelines/app-naming.html

The main points are:

• Consist of one or two simple nouns.
• Non-standard punctuation or whitespace (for example: SuperWriter).

So we should rename the app Easy Effects.

@wwmm what do you think?

Edit: Okay, Equalizer is loading correctly. I will check the other effects when have time.