Since it’s embedded, I am not sure what you are expecting to get out of using Juce with the DSP hardware? I am assuming the device will have no operating system as such. But Juce, however, is largely designed around abstracting operating system differences. Do you have another system like Linux controlling the DSP hardware?
I’m sorry, I just realized I misspoke in the initial post…
It’s the EV-21593-SOM evaluation board and uses a RTOS (I think Free RTOS). DSP will be done using CCES / SigmaDSP which are Analog Devices’ DSP programming tools, I’m interested in using JUCE for only the UI elements and cross-compatibility between Windows and Mac.
Basically, host program would run on computer and use JUCE UI for controlling the DSP in a friendly and familiar way. DSP would all run on separate hardware (AD 21593). It’s for a real-time sound design instrument.
I used Analog Devices SHARC embedded DSP. Basically, all DSP part you have to program in C/C++ using their internal libraries. You cannot install and use JUCE directly. What you can do, you can install separate Linux on their module and use it as a tool to build user interface etc. However, I skipped the idea to use JUCE there just because JUCE supports only X-Windows on Linux, which is not very practical nowadays for embedded devices. I would rather use qt or something else if you need to have graphical UI. Anyway, Analog Devices DSP routines (at least for SHARC) and internal support for i/o are really good, so you do not need JUCE in fact for that part.
Edit. In the meantime you wrote already something similar If you are going to use Win/Mac just for UI to control your hardware, JUCE is a good solution.
Good to know you’ve worked with SHARC processors before. This will be my first go.
Are there any reasons you can think of for why JUCE UI and SHARC embedded DSP wouldn’t work together well/be future proof? Curious what the other options are.
I think that if you have a separate pc/mac/linux with a JUCE app and you want to control your hardware, then it is perfectly ok and will work for ages. Another case would be if you have for example your AD SHARC board and you want everything (DSP + GUI) on that board, then JUCE is problematic in its current stage (basically due to the fact it is dependent on X-Windows, does not support Wayland, etc.), so it is really hard to run it on some small embedded Linux distro and in this case qt would be much more convenient solution.
It sounds like you want to develop a front end app for some hardware, so it really just comes down to how you communicate with the device, yes? What is the path of connection between your device and the host program? usb? pci? network? etc? you will need to write the code for interfacing to the hardware, and communicating in your protocol, but JUCE can manage all the OS related things for you.
It’ll be a DAI through USB. Probably 8 channels of I/O. Maybe more if possible.
Programming the DSP is done through CCES (cross-core embedded studio) in C++/C, JUCE only need to be used for the UI and mapping the UI controls to real-time DSP + maybe changing the order of some DSP modules. I’ll have to do some more research on the protocol for interfacing with the hardware from JUCE (which is all in C++ from what I gather?)
If you are going to use Win/Mac just for UI to control your hardware, JUCE is a good solution.