This is the server part of CamillaGUI, a web-based GUI for CamillaDSP.
This version works with CamillaDSP 2.0.x.
The complete GUI is made up of two parts:
- a frontend based on React: https://reactjs.org/
- a backend based on AIOHTTP: https://docs.aiohttp.org/en/stable/
Go to "Releases": https://github.com/HEnquist/camillagui-backend/releases Download the zip-file ("camillagui.zip") for the latest release. This includes both the backend and the frontend.
Unzip the file and edit config/camillagui.yml as needed, see Configuration.
The Python dependencies are listed in three different files, for use with different Python package/environment managers.
cdsp_conda.ymlfor conda.requirements.txtfor pip, often combined with an environment manager such as venv.pyproject.tomlfor Poetry.
The easiest way to get the Python environment prepared is to use the setup scripts from camilladsp-setupscripts.
If doing a manual installation, there are many ways of installing Python and setting up environments. Please see the documentation for pycamilladsp for more information.
The backend configuration is stored in config/camillagui.yml
---
camilla_host: "0.0.0.0"
camilla_port: 1234
bind_address: "0.0.0.0"
port: 5005
ssl_certificate: null (*)
ssl_private_key: null (*)
config_dir: "~/camilladsp/configs"
coeff_dir: "~/camilladsp/coeffs"
default_config: "~/camilladsp/default_config.yml"
statefile_path: "~/camilladsp/statefile.yml"
log_file: "~/camilladsp/camilladsp.log" (*, defaults to null)
on_set_active_config: null (*)
on_get_active_config: null (*)
supported_capture_types: null (*)
supported_playback_types: null (*)The options marked (*) are optional. If left out the default values listed above will be used.
The included configuration has CamillaDSP running on the same machine as the backend,
with the websocket server enabled at port 1234.
The web interface will be served on port 5005 using plain HTTP.
It is possible to run the gui and CamillaDSP on different machines,
just point the camilla_host to the right address.
Warning: By default the backend will bind to all network interfaces.
This makes the gui available on all networks the system is connected to, which may be insecure.
Make sure to change the bind_address if you want it to be reachable only on specific
network interface(s) and/or to set your firewall to block external (internet) access to this backend.
The ssl_certificate and ssl_private_key options are used to configure SSL, to enable HTTPS.
Both a certificate and a private key are required.
The values for ssl_certificate and ssl_private_key should then be the paths to the files containing the certificate and key.
It's also possible to keep both certificate and key in a single file.
In that case, provide only ssl_certificate.
See the Python ssl documentation
for more info on certificates.
To generate a self-signed certificate and key pair, use openssl:
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout my_private_key.key -out my_certificate.crtThe settings for config_dir and coeff_dir point to two folders where the backend has permissions to write files. This is provided to enable uploading of coefficients and config files from the gui.
If you want to be able to view the log file in the GUI, configure CamillaDSP to log to log_file.
The active config file path is memorized via the CamillaDSP state file.
Set the statefile_path to point at the statefile that the CamillaDSP process uses.
For this to work, CamillaDSP must be running with a statefile.
That is achieved by starting it with the -s parameter, giving the same path to the statefile as in camillagui.yml:
camilladsp -p 1234 -w -s /path/to/statefile.ymlIf the CamillaDSP process is running, the active config file path will be fetched by querying the running process. If its not running, it will instead be read directly from the statefile.
The active config will be loaded into the web interface when it is opened.
If there is no active config, the default_config will be used.
If this does not exist, the internal default config is used.
Note: the active config will NOT be automatically applied to CamillaDSP, when the GUI starts.
See also Integrating with other software
By default, the config validator allows all the device types that CamillaDSP can support. To limit this to the types that are supported on a particular system, give the list of supported types as:
supported_capture_types: ["Alsa", "File", "Stdin"]
supported_playback_types: ["Alsa", "File", "Stdout"]If you want to integrate CamillaGUI with other software, there are some options to customize the UI for your particular needs.
NOTE: This functionality is experimental, there may be significant changes in future versions.
The configuration options on_set_active_config and on_get_active_config can be used to customize
the way the active config file path is stored.
These are shell commands that will be run to set and get the active config.
Setting these options will override the normal way of getting and setting the active config path.
Since the commands are run in the operating system shell, the syntax depends on which operating system is used.
The examples given below are for Linux.
The on_set_active_config uses Python string formatting to insert the filename.
This means it must contain an empty set of curly brackets, where the filename will get inserted surrounded by quotes.
Examples:
-
Running a script:
on_set_active_config: my_updater_script.sh {}The backend will run the command:
my_updater_script.sh "/full/path/to/new_active_config.yml" -
Saving config filename to a text file:
on_set_active_config: echo {} > active_configname.txtThe backend will run the command:
echo "/full/path/to/new_active_config.yml" > active_configname.txt
The on_get_active_config command is expected to return a filename on stdout.
As an example, read a filename from a text file: on_get_active_config: "cat myconfig.txt".
Some functionality of the GUI can be customized by editing config/gui-config.yml.
The styling can be customized by editing build/css-variables.css.
It is possible to configure custom shortcuts for the Shortcuts section and the compact view.
The included config file contains the default Bass and Treble filters.
To add more, edit the file config/gui-config.yml to add
the new shortcuts to the list under custom_shortcuts.
Here is an example config to set the gain of a filter called MyFilter
within the range from 0 to 10 db in steps of 0.1 dB.
custom_shortcuts:
- section: "My custom section"
description: "Optional description for the section. Omit the attribute, if unwanted"
shortcuts:
- name: "My filter gain"
description: "Optional description for the setting. Omit the attribute, if unwanted"
path_in_config: ["filters", "MyFilter", "parameters", "gain"]
range_from: 0
range_to: 10
step: 0.1
- name: "The next setting"
...The gui config is checked when the backend starts, and any problems are logged.
For example, range_from must be a number. If it is not, this results in a message such as this:
ERROR:root:Parameter 'custom_shortcuts/0/shortcuts/1/range_from': 'hello' is not of type 'number'
Options can be hidden from your users by editing config/gui-config.yml.
Setting any of the options to true hides the corresponding option or section.
These are all optional, and default to false if left out.
hide_capture_samplerate: false
hide_silence: false
hide_capture_device: false
hide_playback_device: false
hide_rate_monitoring: falseThe UI can be styled by editing build/css-variables.css.
Further instructions on how to do this, or switch back to the brighter black/white UI, can be found there.
Changes to the currently edited config can be applied automatically, but this behavior is disabled by default.
To enable it by default, in config/gui-config.yml set apply_config_automatically to true.
The update rate of the level meters can be adjusted by changing the status_update_interval setting.
The value is in milliseconds, and the default value is 100 ms.
Start the server with:
python main.pyThe gui should now be available at: http://localhost:5005/gui/index.html
If accessing the gui from a different machine, replace "localhost" by the IP or hostname of the machine running the gui server.
This repository contains jinja
templates used to create the Python environment files.
The templates are stored in release_automation/templates/.
To render the templates, install the dependencies PyYAML and jinja2
and run the Python script render_env_files.py:
python -m release_automation.render_env_filesWhen rendering, the versions of the Python dependencies are taken
from the file release_automation/versions.yml.
The backend version is read from backend/version.py.
Install the pytest plugin pytest-aiohttp.
Execute the tests with:
python -m pytest