A UI for storing and editing published input port values

Feature Requests
,
1

From user ddelcourt. Split the single feature request into separate requests.

  • A preset system, as in Max

This stores all values of the current GUI set. Reference: http://cycling74.com/docs/max6/dynamic/c74_docs.html#preset.

  • An easy Save/Load mechanism.

Could be tied to the preset system, should probably be. The Kineme save/load plugins where very useful, but re-injecting loaded values was a source of headache, not always easy. Vuo has a flow control though, so i tend to believe things would be a lot easier anyway. Reference: http://kineme.net/release/FileTools/11.

2

Hi,

1 - Could Anybody explain me the difference between this Request and Map controllers to published input ports in Vuo apps ?

Is this Request about a file bundled with the App that will store some preference Values and The Map Controllers to Published … about the possibility for the user to edit those Prefrences with a User Interface like a Preference Menu ?

2 - If Yes, will it also be possible for users to edit and save preferences via editable Values inside the app itself ? Thinking about values edited with User Interface UI Node Set

3

@bodysoulspirit, this feature request is about providing a Preferences-like UI for editing published port values. From the menu bar, you’d select “Edit Inputs” and it would pop up a window with (for example, if your composition has published ports of type Real) sliders you can drag with the mouse. You’d be able to save and load entire sets of published port values. This would all happen automatically by publishing ports; you wouldn’t need to connect any additional UI nodes.

The other feature request, https://community.vuo.org/t/-/4882, is about using external controllers (such as MIDI CC) to edit those published port values.

4

@Smokris

Ok got the difference between the 2 requests, thanks.

5

This FR sounds awesome!

6

On this Facebook thread, @George_Toledo also suggested:

Perhaps there could be some kind of index values involved with these nodes to create groupings of parameters, with ability to have more than one GUI window.

When you publish a Real port, you can right-click and select Edit Details — I’m thinking we could eventually add widget placement options (like George suggested) to that dialog.

1 Like
7

On presets, it’s almost a separate request entirely. for instance I spent quite a fortune of time in QC making an utility that would monitor any type of value on a noodle and have the ability to save it and restore it to one of 90 patches (0-89) using a bank/unit two button input for storing and and recalling ‘patches’. Basically i was trying to apply a Juno-60 memory bank to patches. 8 banks’ of patches, 10 patches per bank. It used spooky send and receive to all the ‘nodes’ it sampled data from.

It had the added feature that it could record a value that was generative (say an image of scene of drawing with your fingers and interacting with feedback for recall) that can not be represented with a published input port and this image (or whatever state that needed storing) could be recalled from the patch bank and the composition would continue to run from that unique ‘initialisation’.

In the Vuo Editor these nodes could be specially marked nodes and very discrete shapes sitting on cables wherever they are required. The Editor would then need to take responsibility for making saving and restoring values. I also had many channels so multiple “PATCHbANK” compositions could be assigned to different comps running. In the end I realised I was trying to build an extremely rudimentary VDMX for saving all those “moments” you get in very creative composition that have lots of directions the can move in. Also it saved having to publish all the values you wanted to record which can get messy in QC >20 ‘nodes’ and could get messy in Vuo to, especially for compiled apps.

I had a controller all built in QC that had various modes for recalling patches, writing patches, write protect modes and so on. It was to send messages to the virtual patches in other compositions to get/set values and save all the collected data to files. Was partly implemented but QC was a terrible coding environment to attempt something like this. I enjoyed making the controller with blinking button LEDs and Patch Number LEDs that was an operational state machine. I could draw up something similar for a Vuo patch bank or memory bank. I had in mind that it would be driven by MIDI messages also from a music keyboard (black keys for changing patch banks and white keys for changing patches following a ‘mode’ command or any controller surface device like the Behringer BCF2000.

mvc-blueprint-ii.jpg
mvc-blueprint-ii.jpg1484×1057 871 KB

8

Alastair, being able to capture “moments” in an entire composition sounds like a separate feature request, since this feature request is specifically about published inputs.

(Internally Vuo actually does capture and restore the entire state of the composition upon each live-coding reload, so this is doable.)

1 Like
9

I need clarification of whether this request covers what I’m thinking about. I need an exported app that holds its input data, such as dropped or input movie paths and serial strings to be sent. As in, a movie path and serial commands that a user has specified, that will keep these settings the next time the app is launched. This strays from the “preset” discussion here, but maybe it’s terminology. I also wouldn’t want a generic “edit inputs” preferences dialog, but rather saving things that are entered in the programmed UI. For example a composition whose main window is input fields for a path/strings/vals/whatever which are held for every launch of the app until changed. Of course this would require users to create their own dialog or input fields but would avoid the obviously (and distastefully) generic input dialog. Perhaps if the “preferences”-style dialog was highly customisable in terms of wording and appearance then it would achieve the same thing, but I don’t want to vote for something that doesn’t reflect what I’m after.

10

@bLackburst, you may be asking for something different.

My understanding is that you want the ability for an exported app to remember its settings across launches. If you run the app, drop in a movie file, quit, and relaunch, then the movie you last dropped in should still be there. If you drop in a different movie, that one replaces the previous movie. Quit and relaunch and you see the most recently dropped movie.

The idea of “presets”, based on the Max reference from @ddelcourt, involves multiple presets (sets of settings) that you can switch between.

What you’re talking about sounds more like the ability to save preferences of an app.

You may be able to accomplish what you need using the Save Data and Fetch Data nodes to save and load preferences. The attached composition demonstrates.

A refinement (possible separate feature request, if you want to create it) would be to use the macOS preferences system. This would save the information in a special location and format determined by the operating system, rather than ad hoc as in the attached composition.

These feature requests may also be relevant to what you’re asking for, and are already chosen to be implemented: Load structured data (XML, JSON, CSV, TXT) and User interface (UI) node set.

movieplayer.vuo (5.17 KB)

11

Ok @jstrecker, I have put up the feature request, but I’m not sure how relevant to VUO workflow this is. In QC i used to find that one reasonably complex visualiser could be tweaked to generate hundreds of different looks just by controlling say ten different value inputs, but it wasn’t practical to publish everything to the root level, because there’s a practical limit tpo how many published ports can be displayed in the Viewer window in QC . Also you’d keep finding other inputs to adjust. And publishing and unpublishing inputs to root is is a chore.

This was my attempt to ‘manage’ all that info over time and restore a composition ‘state’ very easily and effortlessly without even having to think about what to call and where to save the file.  

12

Will this be supported in exported screensavers too (by clicking options in the screensaver preference panel), or should I create a separate Feature Request ?

1 Like
13

Um… separate please. While I’m hopeful that we can share a lot of the code between published inputs in exported apps and in screensavers, it will take some extra effort (how much we don’t know yet) to actually get it working for screensavers.

1 Like
14

So it seems from @smorkis’s comment that this isn’t just a FR for storing and restoring publish input values, it’s also a FR for the ability for these published inputs to be exposed through a window in the first place. I want to vote for the later but not so much the former (though it doesn’t seem like a lot of extra implementation once the later is done). Should this be split into two FRs?

15

Hmm, it does seem as though Steve suggests having GUI interface elements selectable when publishing…which really does sound very straightforward, nice approach.

Personally, I just think that straightforward, easy for the team to code in a robust way, and basic to start with…is a good path for any of this. You have a small amount of GUI elements, and then more user feedback happens. Knob, slider, color picker, string entry, maybe file drop, etc. Maybe not even all of that initially, I don’t know what would be reasonable.

Less potential of creating a very involved system out of attempting to handle every single scenario, but then having to work backwards for some reason later.

Given recent discussion, and coincidentally - thought I was having about VUO in past days - maybe it would be time well spent to document using a VUO graph within an xcode based app, and using Interface Builder to setup a GUI to send data to published ports.

I was just looking at the VUO docs about this, but hadn’t dug in…the last time I tried setting up the SDK on a new system, I just couldn’t get it working as I had previously. Hopefully this time will workout.

—

The Max/MSP preset storage system is pretty useful. I may be wrong, but one distinction I see in the discussion is that the Max thing works through a node on the editor surface that stores all values. Whereas this would seem to be proposed to work via publishing first and then the GUI interface widget presumably rendering somehow somewhere…which is a whole other ball of wax.

It may be the best approach. Sometimes!

There have been several workflow discussions about GUI in past days, and I think that there are a handful of somewhat different “solutions” to the “problem”. Quotes emphasizsd! Because I think the perception of best route can be highly personal, and what seems like the best route can also be very context dependent even for the same user.

I find there to be very valid use cases for the differing perspectives people have had about how to approach this issue in general. Sometimes it is just best to be able to approach things multiple ways.

There’s a use case for a class of GUI elements on the editor, for GUI element approaches in the render windows, to be able to code GUI elements in VUO language to use within VUO, to have really fleshed out Xcode examples of how to work with Interface Builder and published ports, and I’m sure some other approaches I am missing.

I think a slider and a knob on the editor could be very low hanging fruit things to accomplish, as some sort of editor gui widget class. Starting slow on that seems good, and it would immediately be helpful in many settings. Maybe a color picker or something.

Having robust GUI widget selection within the app exporter seems like another great approach.

The ideas of having GUI made in VUO nodes render in a separate window, you make your hit tests and sliders in VUO language…I think much of that can be done from scratch now. I’m unsure what the biggest weak links would be on that type of approach. I think that you can even do file drops and stuff given the stock nodes, but I don’t remember for sure.

I think some of the ideas of various GUI functionality seems really time consuming to code, though I am unsure, it depends on many factors. Whereas some things seem like they could have a very basic initial implementation in a few hours, with a few day window after to polish it up.

Anyway, just some thoughts to cast into the void :-)  

1 Like
16

agree that the possibilities are endless but the “minimal viable product” to get this happening for in Vuo use and separately for in Export app use are the two most appropriate ways to go as first steps @George_Toledo. Maybe the two use cases overlap a lot for the most elementary implementation by @teamvuo.

The implementations for Editor and exported apps may have a lot of overlap, just like published values to root level in QC viewer window and ⌘3 Published ports did with Quartz Builder compiled apps Edit Input Values floating palette (near identical in appearance and UX) or they might be completely separate approaches.

I have a FR for nodes that store and restore values of all native data types according to a master “patch” select/save/restore node.

I build a controller prototype for something this idea in QC a decade ago and the UI still works last time I checked on macOS ~10.15 Catelina with a fancy UI that has several states and lashing lights etc etc.

I also had the patches (JS patches with only 10-20 lines of code) that did the storing and restoring of datatypes using Spooky patches to connect with a primitive JS patch with no UI (all the objects that a JS patch could recognise including complete “Object” types could be stored and restored).

I never quite got the fancy pants GUI controller and the canvas patches talking. I’ll find it and post the controller here for anybody interested for nostalgia’s sack. I don’t think i ever showed it to anybody except @cwright back in the day.

One of the nice things about doing it this way rather than as a published port value saver/getter is that it can save composition states that are much more complex than primative types. For example you draw a picture on the screen using any or all of the composition UI tools, mouse and webcamera, that drawing itself could be saved and restored as a base state for the composition and you could keep working from there.

I used to find that some QC compoistions had the potential for hundreds of intersting “look and feels” just adjusting everything at the left had side of the composition and it was difficult to publish all the ports you’d might want to save even if there was a tool for that. The only way to save versions effectively in QC was to save another version of the file, and i’d end up with dozens which wasn’t so easy to recall, and certainly not within the same window running a QC comp without a composition loader which had it’s own issues.