Manage settings with structs

[pljones]

(Yes, I'm still trying to sort this out...)

My mind's eye view is that the server has a set of settings: SServerSettings. This is everything the server needs to know.

On start up, the structure is created (in main.cpp, defined in server.h).

Then, if GUI-enabled, CSettings populates it with values from the inifile - hence CSettings doesn't get passed a server instance any more - the server doesn't yet exist.

Next, all the values collected from the command line overwrite the appropriate entry in the settings structure.

And then finally, CServer gets instantiated with the SServerSettings instance reference.

To change a server setting, you call the server as you do now and it records that value in SServerSettings&.

When the server terminates, if GUI-enabled, CSettings is passed the SServerSettings reference to store to the inifile.

---

It's actually a fairly straight forward change in the server. The only concern I have when it comes to the client code... it isn't anywhere near as simple a model. Much of what's in the inifile isn't even for the client. So I'd keep the SClientSettings struct "unpolluted", free of GUI settings, perhaps having a separate SClientGUISettings for those.

---

One benefit is dropping all that code I added checking for command line options to prevent the inifile being used. The logic above handles that without any effort.

It could also help make it clear on what will persist to the inifile -- if it's not in one of the structs, it's not getting saved.

[corrados]

Should we really change anything with the settings? It just works as it is right now.

[pljones]

It's a "wait and see" -- the setting / command line haven't changed recently but, when I raised this a lot of change was happening.

[pljones]

OK, some more thoughts.

A couple of people have wanted to decouple of client GUI from the client itself and have a more programmer-friendly way of controlling the client - effectively, all the calls to the client from the GUI and the emits from the client to the GUI would need replacing with some other asynchronous interface.

Ideally - and what one of the people wanted - this would allow easy custom GUI construction, on top of that interface.

The other requirement was that remote control would be possible.

Whilst the server has some support for running without a GUI, it doesn't provide a full runtime control interface, either.

So, how does this relate to my ideas on the settings? Well, this was a kind of first step down the path - get the settings clearly separated out and managed by specific calls to update them.

I'm still half thinking "it's not going to happen"...

[gene96817]

One caution about enabling custom client UI. It will become a nightmare to support. It will get complicated for users to help each other. The only way to avoid this complexity is if a custom client UI is in a closed ecosystem because they may be having different UI experiences. The proliferation of closed ecosystems will fragment the Jamulus user community.

The most important reason to have a custom client UI (that I can imagine) would be for
1- branding purposes for commercial projects
2- a school seeking to brand their program (perhaps with proprietary enhancements)

[atsampson]

have a more programmer-friendly way of controlling the client

I've wondered occasionally if it'd be worth making Jamulus understand OSC - it's used by lots of other audio applications already (e.g. Ardour, which uses the liblo library), and it'd be a pretty good fit for controlling things like recording and the mixer remotely.

[WolfganP]

have a more programmer-friendly way of controlling the client

I've wondered occasionally if it'd be worth making Jamulus understand OSC - it's used by lots of other audio applications already (e.g. Ardour, which uses the liblo library), and it'd be a pretty good fit for controlling things like recording and the mixer remotely.

A bit off topic...
We already have MIDI control for the mixer. What will OSC bring extra in terms of functionality?

[pljones]

One caution about enabling custom client UI. It will become a nightmare to support.

That's my biggest concern. My default position on this is simple: "No, it's a very bad idea". But this is open source, so it's not up to me. Enablement (why isn't that a word...) and provision are two different things.

[ann0see]

@pljones I assume you're working on this (next-big-thing) branch on your repo? Can we close this?

[pljones]

Well, this sort of is "the issue" my branch will be the PR to once I get it anywhere near finished... It's going to take time... (and that's been scarce in terms of enough at the same time to make progress).

[ann0see]

@pgScorpio, I think this is somehow also related to the settings redesign?

Note: I will unsubscribe from this issue and won’t receive responses from any new comments. If you have any questions concerning maintenance, feel free to ping me.

[pgScorpio]

Should we really change anything with the settings? It just works as it is right now.

Yes ! It works, but is far from ideal!

I'm working on settings too (See my branch) with the initial idea already implemented.... (But still far from complete)
And after the sound-redesign there could be even more improvements...

[pgScorpio]

@pljones

I'm still half thinking "it's not going to happen"...

I'm still thinking "This HAS to happen" (Too much problems now)
Please let's work on this together.

[pgScorpio]

@pljones

Well, this sort of is "the issue" my branch will be the PR to once I get it anywhere near finished... It's going to take time... (and that's been scarce in terms of enough at the same time to make progress).

Well I started working on this also (while waiting to get all my other PR's going.) and I think I'm already quite far in the right direction with settings. So let's work on this together.

[pgScorpio]

@ann0see

@pgScorpio, I think this is somehow also related to the settings redesign?

Yes, for 100%

[ann0see]

@pgScorpio I think your PR and design choices are worth getting in Jamulus 4 in some way or another.

Personally, I'd suggest - based on this:

1. A class saving current settings - this is accessible throughout the app
2. This class gets populated by CLI, JSON RPC, GUI, config file in the respective order. Those could/should probably be separate classes like in Adding global commandline parameters #2599

@pljones @softins can we get a consensus on design decisions here?

[ann0see]

One caution about enabling custom client UI. It will become a nightmare to support. It will get complicated for users to help each other.

I think this shouldn't happen. We should focus on a more modular, decoupled front and backend. Making it trivial to add a new GUI is not the goal IMO. Just creating a clear and clean API.