#1

Hi,

I know there are a few web developers here, so i wondered if I could pick some brains :slight_smile:

I want to develop a ‘mobile app’ for Orac, which will allow me to release Orac for the rPI and Bela, as it’ll allow users to configure and control the hardware remotely, even though its ‘headless’. (once configured, they can chose to run without the app)

I could quickly write a native app, C++/juce/networking all in my skill set, and the orac code is cross-platform, and supports a distributed model - so no issues, and quite quick to do.

BUT i don’t have the a apple developer account, nor current ipad, and id also have to do the same for android (and get the hardware) - all this sounds painful, and potential expensive. (considering this is all open source and free)

so, I thought id do a web-app, but last time i did browser stuff was 20 years ago (when you wrote your own servers etc) , and now it appears every man and his dog has written a framework, so I’m a bit bewildered at the array of options!

so am looking for some guidance/suggestions/thoughts…

to narrow things down, this is a simple app, basically i just need bi-directional async comm, not massive amounts of data, no database, no transactions, probably only single client - nothing complex.

however, it needs to be as light as possible, ideally, id embed it in my current server running, as its sometimes on a single core, so the few processes the better…
also that server already has the data model, so potentially can do the rendering (the code already renders 2 ui’s so adding new ones is ‘easy’), so that reduced interprocess comms.

for a web app, i cant re-use the current distribution, which is osc over udp, but i could quite easily add a new one.

my current thoughts/idea are (after a few hours of research, so be kind :wink: )

my server could implements websockets, so it could serve up the client html/js but also have a custom protocol to send osc over to the client. (or json, or whatever)

the client side would be pretty simple, mainly ‘filling in a panel’ who contents is sent from the server (via the ws) , and sending data back from controls (js knobs/buttons etc) - a bit like how you might do it if you used something like Lemur.

part of the reasoning here, is my JS/html/css is pretty rusty/basic, keep client side minimal, and essentially do most of the ‘rendering’ on the server (where I have the skills)… and don’t want to spend months learning new skills before i can finish this.

i think approach is also pretty efficient, as it means the client does not need to see every parameter change/keep the data model, rather it only gets updates when the UI actually needs to update.
(and as i said, the rendering code is pretty much already there on the server, and it has the full data model already)

Im also hoping if this client side is resizable etc it will also work on different devices from phones-> desktops… (im hope some framework will help this?)

I recognise this will not lead to the most flexible/fancy UI, that’s ok, this is a first stab, a way to get the ball-rolling, if its popular, then it can be review again… and perhaps native apps start looking more viable.

BUT… as i said, these are my ideas only a few hours of research, so perhaps,
its a completely wacked idea? I’m re-inventing a (square) wheel?
thoughts?

also what do you recommend on the client side, vue/reactjs/something else?

( i installed webstorm by jetbrains and that offered about 20 different options :laughing: )

thanks for any pointers
Mark

mods: i think this is the right category, but feel free to move to development, if you think that’s more appropriate!?

#2

If you want lemur style ui component there’s: https://nexus-js.github.io/ui/

2 Likes
#3

Vue/react are pretty safe bets. Great idea regarding using ws for your data transport. Vue and react will pretty much only do your drawing and interactions (not server side rendering as I think you were alluding to?). I’d have a play with javascript Event Emitter before going too hard on libraries for your client side data model. You might be able to just throw some events around and call it a day.

1 Like
#4

nah, Im saying that the client side will be a bit like (virtual) hardware, fixed layout, say, like a push 2…

so a fixed canvas with a virtual screen, pots,encoders,buttons etc, which gets reused in different ways, based on context.

then the server (in C++) will send text/data to it (over ws) , so the client JS code, simply takes that data and stuffs it on to the virtual screen, or sets values on pots/buttons etc.
so the client JS is very simple.

it also means whilst orac is in development/flux the UI code can basically stay the same.
(the server code will be updated of course)

as I say, not as nice as a custom app which really reflects the workflow, ,
but I suspect that is better written (at a later date) as a native app anyway.

#5

If you do go the React route it may allow you to create a native version more easily in the future by using React Native. That way your business logic could be shared across different component definitions for each platform. Plus there’s always electron if you wanted to port it to a native desktop version too. If you do go React, I’d highly recommend using Redux to manage state. I’ve done a bit with it and Websockets via a custom middleware I wrote that basically expects the server’s response to be a stringified JSON object that would be the return value of a Redux action creator and the middle then fires that action when the request is fulfilled. Works really well for me so far.

1 Like
#6

Take a look at Kivy, I used it for light control on Android and Windows tablets with good results. It’s Python-based, but has a declarative language for laying out the UI and even some basic support for OSC.

1 Like
#7

I have some experience with sort of thing :slight_smile: See, for example, my browser based Sample manager for Elektron devices: crunch/elk-herd:

For this sort of thing I’d go with this architecture:

Small, simple web server on the Orac device:

  • It need to serve a small directory of static files, and accept a few simple JSON based REST APIs. If you want updates to the UI from changes on the device w/o polling, then also Server Side Event support, too.
  • You could build all this into your C++ code, but why bother? This server is about of 40 lines of Python, and can interact locally with Orac on the machine via OSC (which seems to be Orac’s preferred method).
  • I’d keep the API between server and client VERY high level - don’t try to serve or manage UI from the Orac machine - it’ll be very hard to get a good rich interaction that way. Instead, just serve very high-level things: Pass the Orac config file, and all the module descriptors (already .json, right?) - let the client app do all the work.

Client app written as an all-in-one-page web app that runs in the browser:

  • You could write this in JavaScript (or any variant) w/pick-current-cool framework(s)… But I wouldn’t. I’d write it in Elm, which will compile to JavaScript. Elm is far more productive, more safe (it really is very close to “if it compiles, it works”), and very very agile.
  • Use Bootstrap as the HTML/CSS framework - will get you responsive design for phones, tables, and desktops all in one easy go. Forget fancy CSS compilers etc… this just needs a small amount of extra static CSS. Keep this simple
  • crunch/elk-herd is written this way. A whole sample manage, with drag-n-drop, and instrument interaction over MIDI.

Now, Orac starts up the web server… and serves the app as static HTML/JS/CSS - So the user has nothing to install on any platform - just browse to the Orac machine and you’re good to go. And, as it is bundled with Orac, it is easy to keep this application in sync with Orac - making API and architecture changes easy - since both sides change together.

2 Likes
#8

Not sure if this is any help or not, but the server that runs on Volumio is very nice. just hit volumio.local and you are in business. I know it is written in node.js and is fully open source.

#9

my two cents and my two cents alone: write the gui in vanilla js, avoid view libraries like React and Vue if you’re just going to have a canvas on the screen. If I remember correctly nexus-ui supports responsive layout, so no need for css compilers or bootstrap (if I remember correctly!).

You should be able to make the frontend easily without any abstractions or extra compiler stages.

#10

Nexus UI looks pretty useful (albeit not responsive according to the documentation). But I’m wondering about the motivation for using a web browser as a controller interface. I guess personally I’d prefer to use physical controls and reserve the browser for configuration tasks, which would suggest a different approach.