Building Web UI's for OSC

I’ve just about put together one of my first decent projects since investing in VDMX, been working hard with deforum to create custom animations and added some interactive masks using processing. My next task is to build out a custom web interface so I can allow people on the local network to control it. I have the built in web interface working fine but it also exposes other controls I don’t people to have.
Is it possible to disable/remove control surfaces from the default web interface or should I just build a custom web UI. I have never used OSC before and this is my first project, however I am decent with html/JS so could potentially build something, Just need 2 sliders and a button really.
Does anyone have any good resources for creating custom OSC interfaces?

1 Like

Are you referring to the OSCQuery web interface?

A few thoughts here. What device do you want people to change these parameters on? (and ipad, iphone, android, etc?)

You could use TouchOSC to make a custom interface that only controls specific OSC parameters.

To the best of my knowledge, the OSCQuery Browser, makes a Web UI based on all the OSC ports that are open. OSCQuery itself is meant to be a faster way to setup and interface with various aspects of VDMX without individually right clicking on every single button or slider, so in it’s default form, it should populate the web interface with all that it can.

You could make some sort of website or page that only triggers what you want (and use OSCQuery in the backend)!?

But I would look into TouchOSC, Lemur OSC, Osculator (if you want to port values around or use various HID controllers), Chataigne, etc.

Hope this helps.

2 Likes

Yes this helps, I’m thinking a web interface, mobile mostly.
Lets say I have a local web server running and a wifi hotspot ppl can join with a QR code.
Once they join they can access the url/webpage and there they have an interface.
That interface sends OSC messages back to VDMX which in turn forwards them to Processing and does some sketch changes which are sent back to VDMX via syphon.
The OSCQuery browser is what inspired the idea however as you mentioned it exposes all the controls of my control surface interface but for the public facing web UI I only want 2 sliders and a button at most.

1 Like

If anyone is interested I figured this out.
In order to create a web UI I tried using an OSC.js library but quickly learnt it did not communicate on the same protocols that processing uses. Not a problem, since it uses websockets I was able to bypass the OSC system and instead just send websocket strings to processing.
I can then relay from processing to VDMX using OSC and vice versa.

I have VDMX to Processing on OSC and Syphon, and have a web UI using websockets to processing.
The websocket to processing are just string values I then parse in processing and do whatever I need. If I needed to also control VDMX from Web UI I could use the websocket and create custom strings that could send OSC messages essentially using processing as a middle ware. In this case I only want to control my sketch in processing. So I control the sketch and then send the sketch into VDMX using syphon. I can also control the sketch from VDMX using OSC.
Viola!
I will be writing a blog post on the whole process with a video hopefully this month! I will share it when it is ready!

1 Like

Sounds like you have a solution but osc.js might be worth looking at. It works in both Node.js and in a web browser.

https://www.npmjs.com/package/osc
https://github.com/colinbdclark/osc.js

Also how will you deal with multiple clients?

1 Like

Ran some local tests and it seems to handle multiple clients okay, (had 3 phones running the webUI)
Each phone was able to draw on the screen at same time as the other. Maybe it will break with more but for now I’m happy.
I have been thinking about ways I could create a queue system that keeps incoming requests to a certain limit.
Something like,
arrayOfIncomingRequests = []
request => arraayOfIncomingRequests.push(request)

dripFeed(0.2sec) => arrayOfIncomingRequests.get(last)

I’m not sure yet though, would need to write tests and get more granular into websockets which I’m not prepared to do just yet…