Once the UI nodes feature is implemented would would text and number input boxes retain any data entered into them or would they go back to default the next time the composition is loaded? I can think of a lot of scenarios in my compositions where I would want the data retained between composition runs.
Chris,
You can use the Save Data and Fetch Data nodes, optionally in conjunction with the Tree nodes, to retain the state of the UI nodes.
From CSV issues : don’t find the good setup it’s obvious one can’t at the moment make a long list of action buttons (and other UI elements I guess).
So I’m wondering about 2 things :
A - Generally spoken, for the Action Button I guess an output event on press is good, but for several needs it requires to create another list with other nodes to map the specific events (for example a Select Latest List of URL’s that receive an event).
If for example the make action button also had a Value input & output that would fire on click (for example text with an URL, (but generic would be better)), one could directly make a list of Select Latest (with variable amount of inputs would be cool here) with those output values, and send the latest in an Open in Browser for example.
That would be already easier for a small amount of buttons, but for the example case linked on top, you would already need to make too many instances of that node.
B - You can’t process buttons either in a build list, nor with Copy Layer.
I don’t know if Iteration: Turn most nodes into iterators by allowing single-value ports to accept lists will be possible.
So I wonder.
If Make Action Button had an Input port, that it could be iterated with Lists on Ports, and that it could be fed a Select Latest with variable amount of ports, that would be the best I guess.
But if Iteration would not be possible with Lists on Ports, I guess a Make Action Button List would be something.
For inputs, beside the other required elements (theme, window, …) one could have :
• VuoList of labels input,
• VuoList of Values input,
And for outputs,
• a button layer list of course,
• an event output, or maybe rather an index Integer fired from the last clicked button,
• and the Value output of the last clicked button (the labels could technically be used, but if you have an URL, the URL as the label won’t do it).
Without a Value input & output, if this hypothetical list fired an index of the clicked button, it would allow to map events, but would still be more work to map the events.
PS : I have tried to modify the Make Action Button to add Value inputs & outputs, I have the ports, it outputs the text Value, but it fires events on mouse moves for example at 80 FPS so I’m missing something (joined).
Make Button With Value.zip (4.65 KB)
Is there any timeline for when we might see a text input UI node? Quickly installed 2.0.1 … nope. Urgently need this one. :-)
Paul,
We are interested in knowing how you would use a text input UI node. As a workaround, perhaps a TouchOSC implementation might work (as in Simple TouchOSC Typewriter). Once we know what you need, we could give you an estimate on commissioning it.
For my current use case I have realtime graphics being created by Vuo on a secondary screen that is projected, this is what the audience sees. I wanted the operator (teacher) to be able to feed text questions into the realtime graphics.
I too would like to see a text/number input UI node. This would be very helpful for the ‘lighting visualizers’ I create in VUO. These would not need to be complex, just a graphic box that accepts either text or numbers when highlighted, and fires when ‘enter’ is hit.
Not a super high priority, but very helpful for interactive compositions.
William
Paul, William,
Perhaps you could use Display Console Window as a workaround for now. As the node documentation says, “Typed Line — When a linebreak is typed in the window, this port fires an event with the line just completed.” So you can enter a line of text in the Console Window and output it.
@jmcc The user interface IS the product sometimes, displaying a console window is not a workaround. It’s clearly a sought after and useful thing, presumably not that difficult(?). It’s a six year old feature request now that was chosen to be implemented 4 years ago. Should we give up hope?
1 Like
I agree with @bLackburst. Console window is not a viable workaround from real-time operation of anything.
Years ago I spend countless hours making a multi-bank switcher in QC for QC that used spooky patches along with some pretty simple JS to sample data at any point of the composition and record that value (bool, int, real, string, array or complex object) and then save that to a patch like an old analogue synthesiser (think Roland synths like the Juno 60). Then at any time you could restore any of these patches and those data values, including objects would replace the value on the noodle coming out of it. If you changed the value coming into the patchbank node then it would change the value again just like moving a slider on an old analogue synth would edit the current patch. The JS code for the controller app was hundreds of lines long and became too much of a headache for me when i realised I needed to refactor it using an improved coding style to get the bugs out (I was teaching myself JS along the way!)
Anyhow, I put in a feature request to put the framework for that concept into Vuo. Basically the ability to sniff state and write state. Either in dedicated Vuo nodes or as a new API interface for all new Vuo nodes.
But another work-around is another thing I requested. A websocket node. Websockets allow two way binding between web pages and other programming tools. there was a 3rd part websocket tool i used with QC that allowed for reasonably sophisticated UIs to be built competitively effortlessly with HTML & CSS and a tiny bit of JS just to implement the websocket binding for each button, slider, enumerated list etc.
EDIT> FR links added
Lost me, but it feels the spirit was there somewhere.
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.
Not to be an donkey, but text input has been available for some time. See my post here to get a primer.
You should also search for “vuo.ui”, “vuo.mouse” and “receive” in the sidebar. Most of what’s asked for in this thread is available through the nodes listed there. Some will have to be built more from scratch than others - but I had working sliders from those nodes in 1.1 or 1.2 iirc.
2 Likes
If you guys want to spend time coding websocket guis and Rube Goldberg typing machines knock yourselves out. Vuo needs a text field gui element.
I for one don’t believe a web socket GUI solution would work well for me. I currently use the existing GUI buttons along with live video feeds and live graphics in a couple of my projects with almost 0 latency which is important to how I use VUO. I also have a number of ideas for future projects and applications that will require a built-in GUI as part of the exported app and so really want these as non-websocket controls.
So I am very interested in these new GUI features that will eventually be coming out and believe they will be worth waiting for, I would also be really disappointed in a websocket only implementation. I’m not saying websockets can’t be useful but I don’t want to see it as the only solution to this feature request.
1 Like
@MartinusMagneson! This is awesome! Thanks for providing not only a working example of text input, but also a tutorial on how you built it.
Until there’s a textfield node built in to Vuo, people can reuse your composition in their own compositions. At the end of your tutorial, I like how you explain how to turn it into a subcomposition for easier reuse.
@bLackburst, please keep in mind the community agreement, specifically about generalized negative statement. Ideas about alternative ways to accomplish a task in Vuo are always welcome on this forum. Criticisms are also welcome, but they need to focus on specific points that could be improved.
To all who’ve asked about a textfield node — We’re still planning to add one. We actually started work on a textfield node while developing the Vuo 2.0 release. I would not have guessed this, but it is surprisingly, fiendishly difficult to make a textfield with customizable appearance that behaves like a proper macOS textfield. After a lot of hours spent, we decided that it wasn’t worth holding up the release for this, and we would come back to it as soon as we could. Right now our focus is on getting Vuo ready for the macOS 11 release and Apple’s ARM processors. Once those are under control, we plan to pick up where we left off with the textfield node (which, based on the comments on this issue, is resoundingly the most wanted of the remaining potential UI nodes).
@bLackburst Well, thank you for the insult I guess. Mr Goldberg did some pretty nifty drawings. When that is said, I hardly think 7 nodes qualifies for a Golberg-esque typing machine, especially when it comes to text input. I do understand that there are different views on how node based systems should work, and that we probably are on different sides of the table there though.
Instead of sitting around waiting for a feature for years, I would advocate trying out what’s possible with the current nodes, finding roadblocks there, and suggest improvements to the existing nodes to achieve results. This could for instance be a “text buffer” output in the “Receive Keyboard Typing” node, which would reduce the amount of required nodes to 2 for this application - and would probably be a lot less work-intensive task than making a fully themed UI textbox.
If you read my post I also provided a downloadable composition along with an explanation of what’s what in it, and how to scrap useless parts and save it as a user library node. With a MIT license. This means you can store it, have one node do what you want, and claim it as your own without having to neither pay for it or acknowledge my existence in any way. No Goldberging needed on your part, only a tiny bit of effort!
Also applicable XKCD (which pretty much sums up all of Team Vuo’s comments in this thread):
(Also, also, thank you for the kind words @jstrecker! Nice to be of help!)
3 Likes
Thanks Martinus for the compositions and the reversed queue node !
I got a bit lost between the different subcombs and how to use them, but thanks to you, I was able to tweak your original composition to match my needs, use some buttons as some text fields (clicking a text field resets the field however) (see joined composition below).
One thing I wonder though reading Jaymie’s comment about the work needed for an UI text input, is I wonder if under the hood some changes could not be made to Vuo to make these kind of things easier to implement.
Is it because of the push only system it’s so hard to code ?
I’m no code expert at all, but UI text fiels are basically everywhere, internet, apps etc, do under the hood they all have major code ?
I was thinking about this also because you can’t create lists of buttons since they need the window port, and this isn’t supported within process list loops.
I wonder if it will be possible with the “Allow single ports to accept lists” feature request to create a list of buttons on the fly, with each of them be clickable and editable.
UI Text Fields.zip (60.1 KB)
Would another workaround until implementation of the text UI field also be using some applescript to prompt a text field and retrieve it into Vuo ?
Joined is some composition with some code I grabbed from internet to test.
Works for me, but not sure how that would work for distribution on recent macOS versions due to security restrictions ?
PS : for now the code retrieves an error when canceled.
PS2 : It’s also possible to use Applescript to retrieve files and folder paths, for example to load an image, but you have to modify the Execute Shell Command node to allow the access for the user folder, by default it’s forbidden for security reasons.
Applescript Prompt.vuo (4.89 KB)
3 Likes
@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.