I'm guessing that @DEQ+TheEnd meant this (?):
"When I looked into using my RME sound card with digital RIAA I learned that the input impedance of the RME would not give optimal load for the PU."
Would someone test this, please.
When I try REW EQ with Equaliser set to CamillaDSP it says the my measurement Sample Rate is 48kHz (I have it set at 96kHz in REW Preferences) and when I save the EQ biquads an .xml file is output in the same format as if I had selected Rephase as an equaliser but there are 20 biquads rather than 17. The out put will still have to be put through translaterewxml.py.
I had hoped that the output would just have been able to be added to the config file in the same manner as the output from translatexml.py
TNT, you are right, I had the wrong Equaliser.
However ...
filters:
filter_1:
parameters:
freq: 30.950000000000003
gain: -7.5
q: 6.202
type: Peaking
type: Biquad
filter_2:
parameters:
freq: 37.4
gain: 9.600000000000001
q: 2.003
type: Peaking
type: Biquad
filter_3:
parameters:
freq: 41.95
gain: -14.5
q: 3.724
type: Peaking
type: Biquad
filter_4:
parameters:
freq: 56.2
gain: -1.4000000000000001
q: 7.187
type: Peaking
type: Biquad
filter_5:
parameters:
freq: 72.60000000000001
gain: 2.5
q: 6.33
type: Peaking
type: Biquad
filter_6:
parameters:
freq: 79.60000000000001
gain: -3.3000000000000003
q: 5.1770000000000005
type: Peaking
The naming could be better, if you EQ bass and get filter_1 etc, then eq mid you will get filter_1 etc again, but easy fixed, just Find and replace.
However ...
filters:
filter_1:
parameters:
freq: 30.950000000000003
gain: -7.5
q: 6.202
type: Peaking
type: Biquad
filter_2:
parameters:
freq: 37.4
gain: 9.600000000000001
q: 2.003
type: Peaking
type: Biquad
filter_3:
parameters:
freq: 41.95
gain: -14.5
q: 3.724
type: Peaking
type: Biquad
filter_4:
parameters:
freq: 56.2
gain: -1.4000000000000001
q: 7.187
type: Peaking
type: Biquad
filter_5:
parameters:
freq: 72.60000000000001
gain: 2.5
q: 6.33
type: Peaking
type: Biquad
filter_6:
parameters:
freq: 79.60000000000001
gain: -3.3000000000000003
q: 5.1770000000000005
type: Peaking
The naming could be better, if you EQ bass and get filter_1 etc, then eq mid you will get filter_1 etc again, but easy fixed, just Find and replace.
UX: in the graphical view of a filter window, the color for level is blue while the most prominent color is orange representing GD. With the black background eyes are not drawn to, what could be argued, the most prominent aspect of the three displayed properties of a filter, the FR.... I find myself often eyeballing GD instead of level ;-) - my bad of course but wasn't helped either...
//
//
@HenrikEnquist Quick Config Switch works with a single click after the latest update, thank you! Is it possible to make it so that the active_config symlink is updated when you use the Quick Config Switch?
Michael
Michael
Yes I agree, that orange color is a little too loud. I'll see if I can find something better.
Yes it can definitely be done like that, but the question is if it should
What do others think? I don't use this feature myself so I don't really have any opinion.It would of course be possible to make it configurable in the backend.
Yes I agree, that orange color is a little too loud. I'll see if I can find something better.
Yes it can definitely be done like that, but the question is if it should
It would of course be possible to make it configurable in the backend.
Fair point. Probably best to explain what I am trying to do.
I use the active_config symlink on linux rpi systems. This works great, I can change configurations in the GUI and it is clear which configuration is set as the active configuration.
I use an OLED display primarily for volume indication. I want the ability to change the top of line of the display to user defined text based on loaded configuration. For example maybe I have several different input channel configurations on the same device (TOSLINK, analog, SPDIF) or have different capture devices (loopback vs same device as playback vs completely separate device). I would like to be able to switch between configuration files and have the display updated.
I have a python routine which interfaces with a FLIRC IR USB receiver and have it set so that it changes the active_config symlink and reloads CamillaDSP when KEY LEFT is pressed. The python routine for the OLED display then reads where the symlink is pointing to and updates the top line of the display based on a user defined list of configuration file names and corresponding display text. All of this works great.
However, because the OLED display python routine reads the configuration file name from where the symlink is pointing, changing configurations in the GUI causes some issues. If I use the Quick Config Switch the configuration changes but because the symlink is not updated the top line of the display does not change. Similarly if I set a configuration as active in the GUI but do not apply it to the DSP the top line of the display will update even though the configuration loaded to the DSP has not changed.
Long story short, if there was a way to read the file name of the configuration that is currently loaded in the DSP while using the active_config symlink that would solve all my problems. If this is not possible the next best solution would be an option so that the active_config symlink is updated every time I load a new configuration to the DSP.
Michael
Ok, reading the symlink can never be guaranteed to give the right config file name. But you don't need that, you can ask the running camilladsp process.
- if you have the backend running, read it via the endpoint: /api/getparam/configname
- use pycamilladsp and call get_config_name()
- directly via web socket connection, via the command "GetConfigName"
I tried using get_config_name() but that returns active_config.yml which is not very helpful.
I also just tried using GetConfigName using web socket and it also returns active_config.yml.
I do not understand your suggestion about reading it via the endpoint but before I dig in to it further will this also return active_config.yml?
I guess I do not want the configuration file name as that will always be active_config.yml but rather what active_config.yml was pointing to the last time it was loaded to the DSP. Is this possible?
Michael
Oh sorry, of course, didn't think of that. When it reads the config via the symlink, of course it returns the name of the symlink as the config name, not what it's pointing at. So you need to go one more step. When it returns active_config.yml, that should then mean that it's using the file it got by reading the symlink. If you then check the target of the symlink, it should be the file used. But when it's not using the config the symlink points at, you should get a different filename (or null if it's not from a file).
Hmm...I might be misunderstanding your response but that doesn't seem to be the behavior I am seeing.
Using Quick Config Switch the symlink stays pointed to the old configuration. For example if I have an analog input configuration loaded in to the DSP and change to a TOSLINK input configuration via Quick Config Switch the symlink stays set to the analog configuration as shown below.
Querying using GetConfigName still returns active_config.yml.
EDIT: And to be clear, the configuration loaded to the DSP definitely changes when using the Quick Config Switch.
Michael
Last edited:
Ugh it was too long ago I worked on these things. I remembered wrong that sending a new config over websocket sets the active config filename to null, but it doesn't do that. The active filename is kept, so that triggering a reload via websocket or sighup makes it load that file again.
An easy solution here could be to make the gui update the config file path of the camilladsp process when switching (without updating the symlink). That would make it reply with the right name.
An easy solution here could be to make the gui update the config file path of the camilladsp process when switching (without updating the symlink). That would make it reply with the right name.
Thank you for the explanation (and all your hardworking on CamillaDSP!).
This is not a huge priority for me, I really only use the GUI for tinkering and was just hoping there was an easy fix I wasn't aware of.
The other thing that I've done in the past was trigger off of specific information pulled from the configuration (say capture device or sample rate) but the config name is much more flexible.
Michael
I'm planning on adding "description" fields in many places in the config, for adding some more free-text info to filters and pipeline steps etc. People often add comments in the yaml files. This of course works but they are skipped when reading the file, so they can't be used in the gui for example.
There will be a description field for the entire config file too. Perhaps there should also be a shorter "title"? That could be used to show on a display.
There will be a description field for the entire config file too. Perhaps there should also be a shorter "title"? That could be used to show on a display.
A quick update. I needed to change how the resampler is configured to better support some new features. This means that config files from 1.0 won't work directly in the new version. (Don't worry, the changes are rather small so old files are easily upgraded) I'm using semantic versioning, and this breaking change means the new version should not be called 1.1. So the next version will be 2.0. Since I'm anyway making breaking config changes, I'll delay the next version so I can get some more changes in and hopefully avoid another round of breaking changes later on.
The next version is in branch "next20", and should(?) build and work ok on all platforms. I won't be making any more changes to "next11".
The next version is in branch "next20", and should(?) build and work ok on all platforms. I won't be making any more changes to "next11".