- Prefers to be called
- Uses pronoun
- Perth Australia
- 8 years 1 month ago
- Last seen
- 1 week 5 days ago
Bodysoulspirit instead of thin and thick I suggested dashed or dot-dash-dot-dash like architectural/engineering drawings use. But yes, @keithland, the concept of events, triggering and event flow is not as straight forward for novice users as one might hope. It's inherently a little bit complicated, I can't see any way to simply it, other than build a pull evaluation Vuo mode on top of the existing one (which was talked about in the early days). Push-evaluation gives more discrete control of performance optimisations, and was chosen for that reason. Sometimes you don't want a node firing off every time the screen refreshes (say 30 or 60 Hz) — if it takes 0.1 seconds or more to execute there goes your screen refresh rate.
100% about lots of little behaviours. Even two browsers on macOS implement text fields differently. Eg Safari has macOS text substitution (something I miss a lot making comments on science related websites when I’m in Firefox), macOS system spelling correction engine and user dictionary, word/phrase meaning dictionary “lookup” (helpfully always top item in the contextual menu when you right-click), user programable “Services” and more. While Firefox implements it’s own spell-checker, it’s own user dictionary, and none of those other things I mentioned.
I’m wondering, given that Vuo already uses the ‘Qt’ cross platform UI framework, wouldn’t it be useful in this context? It’s made for this kind of situation and extremely versatile and powerful from what I can tell.
Or would there be too many licensing issues? It’s used in all manner of platforms including embedded systems even, so if the popular FR for Vuo on Rassberry Pi ever wins selection to implement then Qt will go the distance, no problems I’d have thought.
Qt do have a free community licence for non-commercial app builds which might apply to people making app for self use. And if selling their apps then the pro version of Vuo could implement the royalties/licensing fees perhaps?
ps I just spent five minutes trying to find the Vuo code base dependencies/licence. I know there’s a page on this site somewhere where they are all listed but I couldn’t find it even doing google searches of the Vuo.org site and naming various dependencies I thought I could remember the names of. I ended up on GitHub and confirmed you are using Qt already in seconds on GitHub.
Can I ask that the 3rd party framework/licence listing page be moved into the FAQ because this is not the first time I haven’t been able to find it on this site?
bLackburst and Chris when a websocket plugin was made available for QC i had an low-latency interface with a self hosted (same Mac) GUI that was used to drive giant video screens in front of audiences of 100,000+ people. I built the GUI i wanted with drop down lists etc and push button preview and live states in a few hours. If you want to be dismissive of such solutions, bLackburst then i think that's more on you than anything else. I'm only suggesting that this is a low-effort implementation for Team Vuo, given that they seem to be running into significant hurdles on the UI element nodes.
Chris I can understand why you want stock VUO tools to do it. It's a shame it's so hard to make them using Vuo itself (I haven't ever tried but I'd have thought someone would have by now b/c they are so essential for production tools if you aren't using VDMX or similar). Many people made such things for QC over the journey. I made an advanced GUI inside QC using JS and it had 30 or so buttons and several modes of operation, flashing LED animations when moving between modes and two digital readouts for numbers (it wasn't any improvement on latency than Websocket though).
There's a VUO node for loading an HTML page that could be embedded in your app. VUO may even get an HTML server node one day since Kineme built one for QC, in which case it could be all bundled inside the app.
It really is kinda hard coming from QC to Vuo in my experience, and I let go at a certain point. Not due to the challenges of the Vuo paradigm or it's Editor but the nature of my work moved away from fun stuff to climate action activism in the last few years. I look forward to getting back to it though and it's great to see some introductory tutes getting made (hat tip Magneson) that ease people into the performance issues they're bound to run into. The thing about QC is you could start from scratch and say plug an LFO into a Sphere patch Y-position and have a bouncing sphere with two nodes, no events to worry about, no windows and conversion of objects and scenes to images to worry about. And that instant gratification QC offer urged us to try more, animating it's colour and other attributes within seconds.
The event paradigm is very powerful though, and while it's unavoidable in Vuo and creates lots of headaches for new users, it is worth the power it unlocks to use control logic to optimise performance as shown in the simple example above. As for Touch Designer, I've never tried it but i know some QC users who switched to it for professional work many years ago because it had so many advantages c.f. QC.
I'll say it more simply, bLackburst!
Team Vuo clearly has a capacity issue in delivering FRs and updates for what many consider to be core-need Vuo features. Therefore we need to make it as easy as possible for Team Vuo in terms of development hours and integration complexity with the existing Vuo codebase and code roadmap. Not to mention bug fixing down the track.
UI tools are inherently behind the times because expectations are always moving on to the next big thing. In my experience using QC, it takes a long time to smooth all the rough edges and corners making generalised tools that work for any window size and play nice with resizable windows etc etc.
In my view deploying the websocket API offers the most bang for buck for @teamVuo's effort to provide a workable UI solution. All they need to do is build a bridge using the tried and true websocket framework. All the UI tools are already there in internet-land. Anybody who can teach themselves VUO can learn to make a few buttons, radio buttons, sliders and drop down lists and arrange them on an HTML/CSS page with other text and images. And i can guarantee you whatever UI tools Team Vuo can release in the next year, some people will find them lacking compared to what they're used to in other apps.
One down side is that it will be outside of a compiled Vuo app that we might want to distribute to other people, but a browser based UI will still be able to talk to the Vuo app via websocket and we might even be able bundle the HTML/CSS/JS files and to script the webpage to launch?
If Team Vuo think that they can do a set of custom UI features with less time invested in dev and polishing than it takes to make a websocket API implementation inside Vuo then go for it but I'm, extremely doubtful. Remember that a Vuo UI feature set will require all the logic processing nodes to do the view/controller/data back-end of the screen elements also. To me, websocket is the best option for step one down this path.
Also i found this thing Mozilla developed called HumbleNet: A cross-platform networking library that works in the browser. It consists of a C wrapper around WebSockets and WebRTC that abstracts away cross-browser differences, facilitating the creation of multi-user networking functionality for games and other apps. It might be a shortcut for Team Vuo to get websockets and the WebRTC low-latency protocol happening ASAP, although I'm not sure how much it allows for websocket exclusive use, seems ot be used just for the authorisation phase of the connection.