We’re producing plugins using Juce for VST and AU. This is done using a monolithic Juce codebase, with normal separation of concerns for UI and engine code. (such separations are offered by architectural suggestions of the Juce C++ framework).
We’d like to also develop the products for a proprietary Elk based hardware solution. My concept for a prototype would comprise a screen or touchscreen with trackpad or mouse. The peripherals for the hardware solution would therefore closely mimic what is typically used in the context of a Windows or Mac VST.
As the UI’s will be basically the same between a desktop and Elk/hardware implementation, the goal is to develop one codebase to cover both environments, if such a thing were deemed to be realistic. Normal UI interactions occur in Juce in the monolith, versus an Elk implementation working over, for instance, OSC in a completely decoupled way.
I apologize if some of these questions can be answered by perusing the existing documentation, but just wanted to get my thoughts down so the Elk developers can better understand our intentions.
For Elk Pi Hat, is the UI able to be run on the RPi 3b+? Or is it expected to offload UI responsibilities to another device? The engine runs on the RPi, correct? Therefore it seems to be the wiser choice to implement a UI on a separate board, perhaps a second RPi even? (given that the goal is to maximize available resources for the engine, without UI getting in the way).
Is it possible to devise a way to standardize such UI development between desktop VST in Juce and a proprietary Elk solution? This would presumably entail standardization of UI also in Juce running in conjunction with Elk, to offer cohesion between desktop VST and hardware deployments. Ideally, either Juce OOTB, or through class extensions or intermediary framework, would abstract away the mechanisms of communication between Elk’s engine and the decoupled UI, versus a monolithic desktop VST, such that it would become possible to develop a singular code base with separated out UI and engine code. From there, the goal is to target both the desktop VST and proprietary Elk Pi Hat (for now) device which we’ve standardized internally.
Sorry if I am overthinking this, particularly if such facilities are already offered by Juce and Elk – this doesn’t appear to be the case at first glance. The upside to this is absolutely HUGE - especially if one were to make their cross-platform engine that sits on top of Juce open source, along with open sourcing any standardized hardware UI + Elk Pi Hat solution upon which such a solution depends.
End goal: Build a plugin using Juce, decoupled UI and engine code that just “works”: compiles as both a VST for desktop (monolithic UI + engine in a VST), and for the proprietary Elk UI && engine platform (decoupled UI and engine code running on Elk Pi Hat and proprietary UI hardware).
Any thoughts at all are appreciated.