I can indeed confirm that the "windowsbuild" branch builds fine by default on Mac as well, also with FFTW enabled.
While your on it, when you now use cpal, I think you can actually build a version of CamillaDSP that can run in the browser, right? With Emscripten you should be able to build a webassembly version. Wouldn't that be cool
While your on it, when you now use cpal, I think you can actually build a version of CamillaDSP that can run in the browser, right? With Emscripten you should be able to build a webassembly version. Wouldn't that be cool
Major update! CamillaDSP goes cross-platform
The "develop" branch has been updated and now has support for both Wasapi on Windows and CoreAudio on macOS!
It should be considered an alpha version for now, since it hasn't been tested much beyond that it runs and can play sound. Any feedback is appreciated
The "develop" branch has been updated and now has support for both Wasapi on Windows and CoreAudio on macOS!
It should be considered an alpha version for now, since it hasn't been tested much beyond that it runs and can play sound. Any feedback is appreciated
Another update, pre-built binaries for the most common systems! These are built and published automatically for each new release.
I'm currently building for Linux on AMD64, Linux on armv7 (Raspberry Pi), Windows on AMD64 and macOS on AMD64.
(note: "AMD64" is one of the names for 64-bit Intel or AMD cpus, also called "x86_64" or just "x64")
See the Releases page here: Releases * HEnquist/camilladsp * GitHub. Click "Assets" to view the files.
The Readme for the develop branch has also been updated with this info: camilladsp/README.md at develop * HEnquist/camilladsp * GitHub
I'm currently building for Linux on AMD64, Linux on armv7 (Raspberry Pi), Windows on AMD64 and macOS on AMD64.
(note: "AMD64" is one of the names for 64-bit Intel or AMD cpus, also called "x86_64" or just "x64")
See the Releases page here: Releases * HEnquist/camilladsp * GitHub. Click "Assets" to view the files.
The Readme for the develop branch has also been updated with this info: camilladsp/README.md at develop * HEnquist/camilladsp * GitHub
Åhå
OK - I found out that Safari adds that filtype (.dms) and its an old bug...
:./camilladsp-macos-amd64.app --help
CamillaDSP 0.3.0
Henrik Enquist <henrik.enquist@gmail.com>
A flexible tool for processing audio
Built with features: cpal-backend, socketserver
USAGE:
camilladsp-macos-amd64.app [FLAGS] [OPTIONS] <configfile>
FLAGS:
-c, --check Check config file and exit
-h, --help Prints help information
-V, --version Prints version information
-v Increase message verbosity
-w, --wait Wait for config from websocket
OPTIONS:
-p, --port <port> Port for websocket server
ARGS:
<configfile> The configuration file to use
(base)
Bloody great ;-D
//
OK - I found out that Safari adds that filtype (.dms) and its an old bug...
:./camilladsp-macos-amd64.app --help
CamillaDSP 0.3.0
Henrik Enquist <henrik.enquist@gmail.com>
A flexible tool for processing audio
Built with features: cpal-backend, socketserver
USAGE:
camilladsp-macos-amd64.app [FLAGS] [OPTIONS] <configfile>
FLAGS:
-c, --check Check config file and exit
-h, --help Prints help information
-V, --version Prints version information
-v Increase message verbosity
-w, --wait Wait for config from websocket
OPTIONS:
-p, --port <port> Port for websocket server
ARGS:
<configfile> The configuration file to use
(base)
Bloody great ;-D
//
I updated my build scripts, so now the binary downloads are compressed.
Linux: .tar.gz
Mac/Win: .zip
I have played a bit with the ASIO support of the CPAL lib. Unfortunately in the current state the it's not very useful. The main problem is that CPAL only supports 16-bit integers and 32-bit floats, and for ASIO 24&32-bit int gets converted to 16-bit ints. That means it's stuck at 16 bits for most hardware. 32-bit float would have been a lot better, then we at least get the equivalent of 24 bits.
CPAL will get support for more sample formats some time in the future, and that should take care of this.
Linux: .tar.gz
Mac/Win: .zip
I have played a bit with the ASIO support of the CPAL lib. Unfortunately in the current state the it's not very useful. The main problem is that CPAL only supports 16-bit integers and 32-bit floats, and for ASIO 24&32-bit int gets converted to 16-bit ints. That means it's stuck at 16 bits for most hardware. 32-bit float would have been a lot better, then we at least get the equivalent of 24 bits.
CPAL will get support for more sample formats some time in the future, and that should take care of this.
.dmg :-D
//
PS: zip ok but probably mac user would rather be associated with Linux so tar.gz is also ok
Last edited:
Haha ok I'll switch to tar.gz.
About the websocket server. I want to add some functions to it and I have realized that the simple protocol I made up is too simple and actually makes things more difficult. So I want to scrap it and replace with something based on json. That will make it much easier to add new commands, and much better for JavaScript clients. Existing Python scripts will need to be updated but that should be fairly quick.
Do I understand correctly that it would perhaps require just adding F32/ASIOSTInt32LSB and F32/ASIOSTInt24LSB combinations to process_output_callback cpal/stream.rs at fe22704d4adc2795f33f2e298c5450ece476d58c * RustAudio/cpal * GitHub and process_input_callback cpal/stream.rs at fe22704d4adc2795f33f2e298c5450ece476d58c * RustAudio/cpal * GitHub and maybe extending some config param checks? F32 is a powerful format, used e.g. by jackd.
Yes I think it's pretty easy to fix, I might give it a go and submit a PR.
I think it's enough to change in the places you found, and the place where they map Cpal <> Asio formats: cpal/device.rs at fe22704d4adc2795f33f2e298c5450ece476d58c * RustAudio/cpal * GitHub
There is comment there:
I have no idea why they decided to map to I16, seems like a weird decision..