Morning here 
Long time no see ya'...
Well i'am mocking to get my bluetooth remote working proberly on moOde 7.3.
I need to use the mute function's at pyCamillaDSP GitHub - HEnquist/pycamilladsp: Python library for handling the communication with CamillaDSP via a websocket.
With my python3 script i can make e.g this work as expected (just a snip):
I proberly use the get/set_mute function's wrong, so i do not post what i try here, would rather have a little explanation of how it should be used (syntax)
Hoping to understand it then
When i got back home from work, i could also check if i actually use the newest version of pycamilladsp? - But i think it's included in the MoOde 7.3 dist.
Jesper.
Long time no see ya'...
Well i'am mocking to get my bluetooth remote working proberly on moOde 7.3.
I need to use the mute function's at pyCamillaDSP GitHub - HEnquist/pycamilladsp: Python library for handling the communication with CamillaDSP via a websocket.
With my python3 script i can make e.g this work as expected (just a snip):
Code:
from camilladsp import CamillaConnection, CamillaError
cdsp = CamillaConnection("127.0.0.1", 1234)
... get_volume() is working
... set_volume(value) is working
... get_mute() Does not work, seem's it's missing ?
... set_mute(value) Does not work either, also seem's as it's missing ?I proberly use the get/set_mute function's wrong, so i do not post what i try here, would rather have a little explanation of how it should be used (syntax)
Hoping to understand it then
When i got back home from work, i could also check if i actually use the newest version of pycamilladsp? - But i think it's included in the MoOde 7.3 dist.
Jesper.
Last edited:
It seems like I forgot to release a new version of pycamilladsp after adding the get/set_mute functions. Sorry!
If you update to the pycamilladsp version in the current master branch, then it should work. It's still called version 0.5.0, but really should be 0.5.1. I'll fix that and make a new release asap.
The mute functionality in camilladsp is part of the Volume filter. If you have get/set_volume working, then the config already has everything it needs for mute too.
If you update to the pycamilladsp version in the current master branch, then it should work. It's still called version 0.5.0, but really should be 0.5.1. I'll fix that and make a new release asap.
The mute functionality in camilladsp is part of the Volume filter. If you have get/set_volume working, then the config already has everything it needs for mute too.
Hey...
Can confirm it's working now Henrik.
Jesper.
Can confirm it's working now Henrik.
Code:
[B]Quick test, no problems [/B]
pi@TESTmoode:~ $ python3 t1.py
Volume : 0.0
Mute : False
Mute : True
Mute : False
Code:
pi@TESTmoode:~/pycamilladsp $ sudo -H pip3 install .
Looking in indexes: [url=https://pypi.org/simple]Simple index[/url], [url=https://www.piwheels.org/simple]piwheels - Simple index[/url]
Processing /home/pi/pycamilladsp
Requirement already satisfied: PyYAML in /usr/local/lib/python3.7/dist-packages (from camilladsp==0.5.0) (5.4.1)
Requirement already satisfied: websocket_client in /usr/local/lib/python3.7/dist-packages (from camilladsp==0.5.0) (0.57.0)
Requirement already satisfied: six in /usr/lib/python3/dist-packages (from websocket_client->camilladsp==0.5.0) (1.12.0)
Building wheels for collected packages: camilladsp
Running setup.py bdist_wheel for camilladsp ... done
Stored in directory: /tmp/pip-ephem-wheel-cache-vmxsl7kt/wheels/77/74/e7/8c8f6fae89f542bf8e93afbf134e948c1d63bfd0dfa5ae9717
Successfully built camilladsp
Installing collected packages: camilladsp
Found existing installation: camilladsp 0.5.0
Uninstalling camilladsp-0.5.0:
[B]Successfully uninstalled camilladsp-0.5.0[/B]
[B][COLOR="Red"]Successfully installed camilladsp-0.5.0[/COLOR][/B]Jesper.
beforeFirst wanted to say thank you to Henrik, I've switched all of my multichannel DSP systems from miniDSP to RPis running CamillaDSP and I am very happy.
I just started using the web interface as I wanted a more real time way to update configurations and visualize the results. It mostly works very well but I think I may not fully understand how the configuration is updated.
My CamilladDSP script and my active_config in camillagui.yml both point to the same .yml configuration file. When I go to the web interface it seems to correctly read this configuration file however there is no specific .yml file name shown in the lower left. As a result when I make a change in the web interface and click "Apply to CDSP" to apply it I get an error stating "Internal Server Error Server got itself in trouble".
If I go to the Files tab and either load or save the configuration it will be shown in the lower left and I am able to make changes in the web interface and apply them by clicking "Apply to CDSP". This works well but if I refresh the web interface I need to load / save the configuration again to be able to make updates.
Is this expected behavior? Is there a way to make it so that I can always make changes in the web interface and apply them without saving / loading the configuration?
Michael
I just started using the web interface as I wanted a more real time way to update configurations and visualize the results. It mostly works very well but I think I may not fully understand how the configuration is updated.
My CamilladDSP script and my active_config in camillagui.yml both point to the same .yml configuration file. When I go to the web interface it seems to correctly read this configuration file however there is no specific .yml file name shown in the lower left. As a result when I make a change in the web interface and click "Apply to CDSP" to apply it I get an error stating "Internal Server Error Server got itself in trouble".
If I go to the Files tab and either load or save the configuration it will be shown in the lower left and I am able to make changes in the web interface and apply them by clicking "Apply to CDSP". This works well but if I refresh the web interface I need to load / save the configuration again to be able to make updates.
Is this expected behavior? Is there a way to make it so that I can always make changes in the web interface and apply them without saving / loading the configuration?
Michael
Attachments
You need to "get" the config from the DSP after a page reload...
I don't refresh the page when doing EQ sessions - thats makes it OK... there is no need really.
I'm afraid I have to say that the new GUI has not improved the user friendliness for me. Its (still) somewhat confusing to me...
//
I don't refresh the page when doing EQ sessions - thats makes it OK... there is no need really.
I'm afraid I have to say that the new GUI has not improved the user friendliness for me. Its (still) somewhat confusing to me...
//
Thank you for the info.
By "get" the config I assume you mean the load / save procedure that I described? Or are you referring to the "Load from CDSP" button in the lower left?
I agree that I found the manual configuration file much easier to understand than the GUI, although another motivation for pursuing the GUI was to play around with volume control in CamillaDSP (which seems to work very well).
Michael
By "get" the config I assume you mean the load / save procedure that I described? Or are you referring to the "Load from CDSP" button in the lower left?
I agree that I found the manual configuration file much easier to understand than the GUI, although another motivation for pursuing the GUI was to play around with volume control in CamillaDSP (which seems to work very well).
Michael
There is a way to fetch whats is currently active in the DSP and populate the GUI with that indo. In this way, you can actually develop new/other filters while your system is playing and save that work to file and come back to tweak whats playing by do (I think) Load from CDSP.
- The "C" in CDSP - what is that?
- "Load from CDSP" - load from is really ambigous... I dont think that is good phrasing / choice of words..
- The up/down arrows in Configs. It's also uses "Load" but also save - to what? The there are columns where 2 of them is consistent with what is below - then there is a Trash symbol but below that there are function to save (somewhere?)
- The DSP functions are lovely but GUI is a usability disaster - sorry!
One more try Henrik.
//
- The "C" in CDSP - what is that?
- "Load from CDSP" - load from is really ambigous... I dont think that is good phrasing / choice of words..
- The up/down arrows in Configs. It's also uses "Load" but also save - to what? The there are columns where 2 of them is consistent with what is below - then there is a Trash symbol but below that there are function to save (somewhere?)
- The DSP functions are lovely but GUI is a usability disaster - sorry!
One more try Henrik.
//
There are four places where a configuration can be:
a) In a file in any folder on your computer (the where you run the browser)
b) In a file in the folder where the backend stores configs (a specific folder on the machine that runs the backend)
c) Loaded in the CamillaDSP engine (in ram of the machine that runs camilladsp)
d) Loaded in the Gui (in ram of the machine that runs the browser)
Browser, backend and camilladsp can all be running on the same machine, or the camilladsp+backend can be on one while the browser runs on another.
The Config box on the lower left lets you transfer configs between c and d (Load from CDSP, Apply to CDSP).
The Files tab in the gui lets you transfer files between a and b (Upload, Download, Save to somename.yml), as well as between b and d (Load somename.yml).
I guess some of the confusion comes when running everything on the same machine. Then upload, download etc isn't very intuitive. But think of it as if CamillaDSP was running on a separate server somewhere, then I think it makes more sense.
If you have any suggestions for improvements, please let me know. Just remember that things must make sense in all the different ways the gui can be used. This is where it gets difficult. And I won't make separate versions for running locally and remotely.
There is a live mode planned, that will (optionally) apply changes directly. This will then keep c and d in sync.
a) In a file in any folder on your computer (the where you run the browser)
b) In a file in the folder where the backend stores configs (a specific folder on the machine that runs the backend)
c) Loaded in the CamillaDSP engine (in ram of the machine that runs camilladsp)
d) Loaded in the Gui (in ram of the machine that runs the browser)
Browser, backend and camilladsp can all be running on the same machine, or the camilladsp+backend can be on one while the browser runs on another.
The Config box on the lower left lets you transfer configs between c and d (Load from CDSP, Apply to CDSP).
The Files tab in the gui lets you transfer files between a and b (Upload, Download, Save to somename.yml), as well as between b and d (Load somename.yml).
I guess some of the confusion comes when running everything on the same machine. Then upload, download etc isn't very intuitive. But think of it as if CamillaDSP was running on a separate server somewhere, then I think it makes more sense.
If you have any suggestions for improvements, please let me know. Just remember that things must make sense in all the different ways the gui can be used. This is where it gets difficult. And I won't make separate versions for running locally and remotely.
There is a live mode planned, that will (optionally) apply changes directly. This will then keep c and d in sync.
OK - CDSP = Camilla DSP - I should have got that one. But CDSP... is that b), c) or d) ? tricky..
I think you need to create a set of short names vid definitions and a model of the system in order to get som proper structure. E.g:
FS: a File System
CE: Camilla Engine (the worker)
CC: Camilla Configurator (the user tool)
Load / Store: Used for file reading / writing between CC and FS
Upload / Download: Used for setting/getting actual running engine configurations.
Load CC (from FS)
Save CC (to FS)
Upload CE (from CC)
Download CE (to CC)
So a roundtrip would be: Load, Upload, Download, Save. Command never reused so no need actually to specify what/where - command will decide.
Info flow can only be: FS<->CC<->CE i.e. to Download a running config in a CE and Save that to file on the FS one need to do two operations.... might be OK...
But thats maybe how it actually works.. I cant recall that user aspects was ever presented as a description of the operator interface concepts, structure and operations...
Wy is the backend storage needed - or maybe... why does the user need to know about it?
//
I think you need to create a set of short names vid definitions and a model of the system in order to get som proper structure. E.g:
FS: a File System
CE: Camilla Engine (the worker)
CC: Camilla Configurator (the user tool)
Load / Store: Used for file reading / writing between CC and FS
Upload / Download: Used for setting/getting actual running engine configurations.
Load CC (from FS)
Save CC (to FS)
Upload CE (from CC)
Download CE (to CC)
So a roundtrip would be: Load, Upload, Download, Save. Command never reused so no need actually to specify what/where - command will decide.
Info flow can only be: FS<->CC<->CE i.e. to Download a running config in a CE and Save that to file on the FS one need to do two operations.... might be OK...
But thats maybe how it actually works..
I cant recall that user aspects was ever presented as a description of the operator interface concepts, structure and operations...Wy is the backend storage needed - or maybe... why does the user need to know about it?
//
Last edited:
Hmm not convinced that abbreviated names will help, I just think that would make things more confusing.
But improving the (basically non-existing) gui documentation would, perhaps by adding a Help tab in the gui. That could have a sketch of the different locations, and explain how to move stuff between them.
The backend storage is used to make it easy to transfer configs and coefficient files to/from the camilladsp server by using a browser. Without it the gui couldn't show a list of available coefficient files for example. A browser can't access the file system, it can't be allowed because that would be wildly unsafe. The backend exposes the files in the storage so that the browser (and the gui) can interact with them.
Main limitation is as always time. The gui always ends up last in the queue..
But improving the (basically non-existing) gui documentation would, perhaps by adding a Help tab in the gui. That could have a sketch of the different locations, and explain how to move stuff between them.
The backend storage is used to make it easy to transfer configs and coefficient files to/from the camilladsp server by using a browser. Without it the gui couldn't show a list of available coefficient files for example. A browser can't access the file system, it can't be allowed because that would be wildly unsafe. The backend exposes the files in the storage so that the browser (and the gui) can interact with them.
Main limitation is as always time. The gui always ends up last in the queue..
Version 0.6.0 is published!
Changes compared to 0.5.2:
New features:
- New Wasapi backend with support for exclusive mode and loopback.
- Do proper shutdown on SIGINT (ctrl-c).
- Add StopReason websocket command.
- Add GetPreviousConfig websocket command to get the previously active config.
- Add option to stop on detected sample rate change.
- Add support for rate adjust on the ALSA USB gadget capture device (introduced in kernel 5.14).
Bugfixes:
- Add missing token handling in .wav FIR coefficient filenames.
Get it from here: Release v0.6.0 * HEnquist/camilladsp * GitHub
There are also matching versions of pycamilladsp and pycamilladsp-plot, both also versioned 0.6.0.
Changes compared to 0.5.2:
New features:
- New Wasapi backend with support for exclusive mode and loopback.
- Do proper shutdown on SIGINT (ctrl-c).
- Add StopReason websocket command.
- Add GetPreviousConfig websocket command to get the previously active config.
- Add option to stop on detected sample rate change.
- Add support for rate adjust on the ALSA USB gadget capture device (introduced in kernel 5.14).
Bugfixes:
- Add missing token handling in .wav FIR coefficient filenames.
Get it from here: Release v0.6.0 * HEnquist/camilladsp * GitHub
There are also matching versions of pycamilladsp and pycamilladsp-plot, both also versioned 0.6.0.
As promised, once I got it all working, here's the GitHub for the project on a RasPi4B:
GitHub - raptorlightning/I2SHat: An SPDIF Hat for the Raspberry Pi 2-X for SPDIF Communication
It took an extra revision of the PCB due to footprint stupidity, but everyone's been there.
Let me know how cheap you can get the BOM! If you're <$300USD for the system, RPI+Hat, you've still beaten miniDSP. (I'm already there with C0G 0.1uF decoupling caps. )
GitHub - raptorlightning/I2SHat: An SPDIF Hat for the Raspberry Pi 2-X for SPDIF Communication
It took an extra revision of the PCB due to footprint stupidity, but everyone's been there.
Let me know how cheap you can get the BOM! If you're <$300USD for the system, RPI+Hat, you've still beaten miniDSP. (I'm already there with C0G 0.1uF decoupling caps.
)
Yes.
"Load from" is awkward. You dont Load *from* something, you load (to) something...
Get or Retrieve?
Your tooltip looks better!
... "and save some somefile" - is this the maintenance of the backend storage. UX wise I would try to hide this - it clutters the UI and the whole understanding of whats going on... but I see why you would like/need to have it. Hide it and just make use of it as a feature - don't describe the implementation.. i.e. don't go by the "if it was hard to implement, it should be hard to use"
//