New version 6.3.0

[Digitalone1]

Since lots of changes have been done (multiband gate, wet and dry options, -inf value, etc.), maybe the next version could be 6.3.0?

Before of the big 7.0.0. version with multiple instances (and maybe change the name to Easy Effects adding the space to be compliant with Gnome naming convention, I read that in the Gnome Circle ticket...)

[wwmm]

maybe the next version could be 6.3.0?

I do not see any problem. One more release and it will be 6.3.0 anyway.

Before of the big 7.0.0. version with multiple instances...

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

and maybe change the name to Easy Effects adding the space to be compliant with Gnome naming convention, I read that in the Gnome Circle ticket...

As only the name visible to the user is going to change I think it is fine.

[polarathene]

But If I do this the current settings will be ignored when the new version starts.

Might be better to detect the old settings at this point, then notify the user with a prompt to convert? Or did I misunderstand, and having some conversion/migration method would not help as something else is dependent on the old gsettings path that a conversion step cannot address?

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.

I'm not familiar with how you have this handled, but are you not able to separate the internal ID/index with the UI representation?

On the UI side, since the number of items would be small, it shouldn't be an issue to identify what value should be assigned? eg If you want to have 1, 2, 4 instead become 1,2,3?

Or with the earlier example with compressor#2 being removed, if that would result in 1,3, you could iterate through that array and bump a counter incrementally when a matching value is found, thus we get 2 as not in use and can assign that?

On the internal name (I'm not familiar with what a gsettings path is), if this is not something that affects UI name, then you could use any UUID value, or a hash derived from the items metadata?

One final alternative to numbered IDs if none of the above is acceptable is leveraging something like colour. That can still associate meaning/identity and with a low range to support, still allow for distinctive choices that do not have a sequential relationship?

[wwmm]

I'm not familiar with how you have this handled, but are you not able to separate the internal ID/index with the UI representation?

Each plugin has a path in the GSettings database. And the widgets in our window have properties that have to be bound to the keys in the corresponding paths. So they are not independent. A simple solution is just looking at the current largest number being used and incrementing it. It will work.

On the UI side, since the number of items would be small, it shouldn't be an issue to identify what value should be assigned?

Probably. I am just thinking if it is worth the effort of doing something like this or not.

if this is not something that affects UI name, then you could use any UUID value, or a hash derived from the items metadata?

I am considering a UUID. But as it would be present in the presets files as well as the database paths I would like to have short identification numbers for readability reasons.

In the next days I will have some time to work on this. I will probably just increment the numbers and move on. I just want to make sure there isn't a super clever solution I could be using before doing that.

[polarathene]

Probably. I am just thinking if it is worth the effort of doing something like this or not.

Honestly, I doubt the user will care too much about that right now.

My understanding is this is the sort of app that gets a fair bit of experimentation time early on, but once the user is comfortable they don't have much need to frequently open it and make broad adjustments.

They're more likely concerned with functionality/feature support than UI labels sequentially consistent naming scheme. Probably better to address it when/if users raise a complaint about it?

I would like to have short identification numbers for readability reasons.
I just want to make sure there isn't a super clever solution I could be using before doing that.

Given this context, why not just use words? The numbers don't have much semantic meaning other than creation order?

• red, blue, green, cyan, magenta, yellow, black, etc
• apple, banana, cherry, ...
• ape, bear, cat, dog, ...
• accordion, banjo, clarinet, drums, ...

Still short and readable, technically better for grepping than numbers and doesn't look odd if not sequential 😅

---

I will probably just increment the numbers and move on.

That's perfectly fine too 👍

[vchernin]

Given this context, why not just use words?

Wouldn't these have to be translated though? I dont think it makes sense to have IDs that can be different across systems. Not to mention what happens if the user changes their system language and has existing instances of effects?

[polarathene]

Wouldn't these have to be translated though?

I thought there was two concerns:

• internal usage with the gsettings path (locale isn't important?)
• UI label

The words was for internal use.

If using UI labels, you could use something like a colour/accent beside the effect type to distinguish it. I've seen graphic EQ UI for example use colours to distinguish frequency bands via BG or the marker element (often a circle).

Could be helpful but, then there's the types of colour blindness where that becomes an accessibility problem. Probably best to just stick with incremental numbers until it's raised as a UX complaint 😅

[wwmm]

And anyway, since the work on this could introduce bugs, it may be better to do a new stable release first.

Yes. There maybe be some small and harmless preparation work that can be in the next release but I am definitely not enabling this right now.

Wouldn't these have to be translated though?

Although these tags will be visible in the preset file they aren't really intended to be seen by the users. If they open the preset file in an editor they will see them. Nothing I can do about it. But the tags are for internal usage when mapping settings to the correct plugin instance.

[Digitalone1]

This conversation should go in #1316

And anyway, since the work on this could introduce bugs, it may be better to do a new stable release first.

Besides if a new big bug will be discovered by users and a release fix is needed, it's easier to apply it on the commit of the previous stable release rather than mixing with the work in progress for plugin multiple instances.