Make GUI work without running CamillaDSP process

[JWahle]

As mentioned in https://github.com/HEnquist/camillagui-backend/pull/9#issuecomment-762517607, I would like to make the GUI work without a running CamillaDSP process.

Currently, a running CDSP process is needed to:

• save the current config (via the "Apply" button)
• Load config from a local file
• display the result of the config check (in the "Config status" field)

I see 3 solutions to make this work, if there is no running CDSP process:

1. Simply ignore the failing config check, load and save the config unchecked. This sucks for usability, but is very easy to implement.
2. Add a CDSP path to the config and automatically start a backup instance in wait mode, listening on a free port. Always use the backup CDSP, if necessary. This would be relatively easy to implement, but can theoretically lead to conflicts, when another program wants the port afterwards.
3. Add a CDSP path to the config and use this CDSP only for config checking. A save would be canceled, if the config is invalid. The load would be canceled, if the config is invalid. Currently, the running CDSP instance also fills all the optional settings with its defaults. We could either change CDSP's CLI to do it, or simply use the defaults of the GUI. Using defaults of the GUI could theoretically lead to configs breaking, if defaults of the GUI do not match CDSP's defaults.

I prefer solution 3, but if you want the defaults to be supplied by CDSP, I would leave the implementation of the CLI changes to you.

Do you see another way of doing this? Which solution do you prefer?

[HEnquist]

1) is easy but I agree it sucks. 2) isn't so bad, you just have to configure a different port for the validator-camilla. 3) is a nicer solution, but I don't think it's worth implementing because it would only be temporary. I have other ideas that I think would give a much better user experience. That little text box showing the error is better than nothing, but I wouldn't call it good!

The reason that the gui uses the camilla process for validation is just that it was an easy way to implement it. The problems are that it can only report one error (the first it finds) and everything that would prevent the config to run is an "Error". I don't want to overcomplicate the validator inside camilladsp, so the validation for the gui would have to be done separately. This is my vision:

• Each gui component should validate it's own fields. That way they can give immediate feedback. Here is a mockup of how it could look in a Mixer:

• pyCamillaDSP should learn to validate the config and return a list of Errors and Warnings. It should also fill out the defaults. An error would be stuff like adding a filter to a channels that doesn't exist. A warning would be for example if it can't read the FIR coefficient file. That could easily happen if the gui is running on a different machine than camilladsp, then the coeffs may not be available or at a different path.

The validation that CamillaDSP does it essentially four separate steps (but steps 1-3 are completely handled by the Serde library): 1) Check that the file is valid yaml - very easy to do in Python 2) Check that it follows the camilla format - probably best done with a json schema 3) Fill out the missing values with defaults - a bit boring but straightforward 4) Run through a series of checks of the values in the config - the existing Rust code should be translated to Python.

The gui should by default produce output that always passes 1&2. Then the internal checks of the gui should prevent most errors in step 4. This whole thing will take some time to implement. I think it's good to do something simpler for now, and your option 2 seems like a good compromise.

[JWahle]

Sounds reasonable, I'll try that. Thank you for the detailed answer :+1: