Cross platform Elk development?

[plow]

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.

1. 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).

2. 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.

[Stefano]

Hi @plow,

you can run the GUI on the RPi3. The only thing we don’t support is a Desktop server like Xorg or Wayland, which are anyway a bad choice for an embedded device. What we recommend and support as way to use display is QT through the EGLFS plugin, which makes it possible to use Graphics HW acceleration without the extra overhead of a full Desktop server.

As for using JUCE instead than QT, you will have to use the JUCE framework to render your graphics in a QT buffer. I know it’s theoretically possible and have heard of people doing it, but it requires you to set up the whole toolchain & process as JUCE GUIs for Linux relies on X11 & co.

For the “single codebase for everything”, the major problem might indeed be this. It might be easier, and get you a result which works much better on small touchscreen displays for embedded products, to have the embedded GUI in a separate project.

Another obstacle in keeping a single codebase for both the Desktop UI and the plugin is that, even if you use JUCE + QT on the RPi, the GUI will run on a separate process and so it will be pretty different from the scenario of a plugin GUI where you have shared memory access between UI & engine.

[jimmycater]

@Stefano

you can run the GUI on the RPi3. The only thing we don’t support is a Desktop server like Xorg or Wayland, which are anyway a bad choice for an embedded device. What we recommend and support as way to use display is QT through the EGLFS plugin which makes it possible to use Graphics HW acceleration without the extra overhead of a full Desktop server.

As for using JUCE instead than QT, you will have to use the JUCE framework to render your graphics in a QT buffer. I know it’s theoretically possible and have heard of people doing it, but it requires you to set up the whole toolchain & process as JUCE GUIs for Linux relies on X11 & co.

For the “single codebase for everything”, the major problem might indeed be this. It might be easier, and get you a result which works much better on small touchscreen displays for embedded products, to have the embedded GUI in a separate project.

Another obstacle in keeping a single codebase for both the Desktop UI and the plugin is that, even if you use JUCE + QT on the RPi, the GUI will run on a separate process and so it will be pretty different from the scenario of a plugin GUI where you have shared memory access between UI & engine.

that is informative man i was looking for this sort of information