Equalizer doesn't update band count when loading a preset

[FFY00]

The equalizer supports a dynamic number of bands (ex. 10 or 15 or 20 etc. different frequencies). The UI should be updated with the correct number of bands when loading a preset.

[rautesamtr]

Yes this is the old behavior. I assume that the original implementation planned to add support for more ladspa plugins but ultimately settled for just the mbeq 1197 which as far as i can tell only supports those exact 15 bands. https://github.com/swh/ladspa/blob/master/mbeq_1197.xml

Still correctly rebuilding scales will be added once i am finished with my first iteration of getting presets into its own class. So basically the idea will be to just recreate the widget when a new preset is set to the Equalizer ApplicationWindow.

[FFY00]

Then we should check the band count when loading a preset and validate it against the plugin used.

What I meant when I opened the issue is that if I start the equalizer with one preset, it doesn't update the UI (band count) when loading a new preset. I don't know if you got that, my bad.

[rautesamtr]

Then we should check the band count when loading a preset and validate it against the plugin used.

Good idea.

What i initially had in mind was to inherit a GtkContainer lets call it PresetControls or MbeqControls with getter and setter for the preset. The setter then handles clearing the container and correctly re adding the bands for it. But part of that idea came from the misassumptions on my side that we need to dynamically handle scales creation per preset which doesn't seem to be the case for mbeq_1197.

For the mbeq_1197 we could move most of it to a template ui file and just change the scales depending on the preset like the original code did.

What I meant when I opened the issue is that if I start the equalizer with one preset, it doesn't update the UI (band count) when loading a new preset. I don't know if you got that, my bad.

What you describe is actually a bug i had happening to me when loading the broken Bass Boost.preset e.g. while it was in config file format or when i corrupted my equalizerrc. The bug occurs if you stay on the broken preset exit the application and start it again since the broken preset had been written to the config file. As you suggested validating band count could at least prevent us from loading such files.

[FFY00]

What i initially had in mind was to inherit a GtkContainer lets call it PresetControls or MbeqControls with getter and setter for the preset. The setter then handles clearing the container and correctly re adding the bands for it. But part of that idea came from the misassumptions on my side that we need to dynamically handle scales creation per preset which doesn't seem to be the case for mbeq_1197.

I think we would benefit from adding a check function to all plugin structures. Basically, that function would check if a specific configuration was valid under that plugin. This would make easier to migrate a preset from a plugin to another. The preset itself needs to have a plugin field, obviously, but this way you could easily change the plugin you want to use. Let's say we add a more flexible plugin, if someone would want to change the preset from MBEQ to that new plugin, they would just change a hypothetical dropbox and select the target plugin. In the background, we would run the check function for the target plugin and make the change if it was valid, if it wasn't we would show an error. Actually, we could enable/disable items in that dropbox based on the check.

If you don't understand something just let me know so I can clarify. I am just brainstorming.

For the mbeq_1197 we could move most of it to a template ui file and just change the scales depending on the preset like the original code did.

Sounds good.

What you describe is actually a bug i had happening to me when loading the broken Bass Boost.preset e.g. while it was in config file format or when i corrupted my equalizerrc. The bug occurs if you stay on the broken preset exit the application and start it again since the broken preset had been written to the config file. As you suggested validating band count could at least prevent us from loading such files.

Yes, my bad :sweat_smile:.