I have been working on a small project using JUCE mainly for building a desktop audio tool but I have been thinking about integrating some web-based features into it I know JUCE is more about C++ and native apps but I want to know if anyone here has tried blending it with web frameworks or libraries I am interested in creating a hybrid interface where part of the UI could be handled in a browser-such as environment.
it got me thinking about building certain interactive UI components with React & somehow embedding them into my JUCE project; I am not sure if that is a smart move or if it will just turn into a huge maintenance headache.
Has anyone here experimented with this kind of setup. I want to hear about your experiences challenges and any best practices you might suggest please share with me.
You’ll probably want to commit to either 100% webview or 100% JUCE UI - you could theoretically have multiple juce::WebBrowserComponents that only display a single widget, but that sounds more trouble than it’s worth.
Since JUCE 8 the WebViewPluginDemo is your best bet for a quick start.
Shameless plug, I was one of the coauthors of this presentation on combining WebUI and high performance audio in C++ with JUCE
The JUCE8 implementation of this paradigm is very ValueTree oriented which may be quicker in the short term, but long term, having a strongly typed and defined API between the GUI and the C++ side is more sustainable.
Using more than 1 WebBrowserComponent is possible, but you start paying a lot per instance for performance and can cause some oddities.
personally I find the ValueTree API lacking – mostly because it’s up to you as the developer to remember the type and the values that are in the storage. But this is a general issue with all “property bag” type APIs, JSON objects included.
At scale, I have found that having a strongly defined protocol and clean API between your Web and C++ components results in an easier to maintain application, but for simply updating values between your GUI and Audio code, the ValueTree might be perfectly fine.
There’s two broad ways to make software (1) the developer’s brain is responsible for how the code works, or (2) you craft APIs that enforce correct usage of the code. ValueTree falls in (1).
You can easily solve the problem of needing to remember types on the C++ side, but creating interfaces. I’m sure you can do the same up in the JavaScript. I use classes that present domain specific interfaces (which I call ValueTreeWrappers), but I haven’t officially published this idea, it is available in some open source projects (A8Manager and SquidManager). A more polished version of the idea is available from a library called Cello (that is an S sounding C, like cellotape) from @bgporter. It’s finer grained and well documented.
Thanks for the mention – anyone interested can check the talk I gave at ADC 24 or more thoroughly, the writeup I’m doing on my personal site: Cello Overview
Adds type safety, thread safety, guaranteed initialization, property validation, simple interprocess sync, and in general works to hide the API calls so your code feels like working with plain objects, so instead of writing
It indeed seems extremely useful. I have been very happily using your excellent Friz and for some strange reason I didn’t see Cello until now. It should certainly be included in Sudara’s awesome-juce list.
…my fault for not submitting it as a PR to awesome-juce; I had been waiting for it to get more real world usage, and then just forgot about taking care of that. Will add to my list.
update: PR submitted to awesome-juce, thanks to @aamf for the nudge.
