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.

Component: 

Notes from Team Vuo

Vuo Pro: 

Yes — requires a Vuo Pro license

Complexity: 

●●○○ — A few weeks of work

Team Vuo's vision for exported apps:

  • In the app, provide a UI for editing published input port values.
  • In the app, provide a window to store and manage presets.

Comments

A total yes :)

Bodysoulspirit's picture
Submitted by

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

@Bodysoulspirit, this feature

smokris's picture
Submitted by

@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://vuo.org/node/631, is about using external controllers (such as MIDI CC) to edit those published port values.

On this Facebook thread,

smokris's picture
Submitted by

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.

On presets, it's almost a

useful design's picture
Submitted by

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.

Alastair, being able to

jstrecker's picture
Submitted by

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.)

I need clarification of

bLackburst's picture
Submitted by

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.

@bLackburst, you may be

jstrecker's picture
Submitted by

@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.

Ok @Jaimie I could put up the

useful design's picture
Submitted by

Ok @Jaymie, 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.

Feature status

When we (Team Vuo) plan each release, we try to implement as many of the community's top-voted feature requests as we have time for. Vote your favorite features to the top! (How do Vuo feature requests work?)

  • Submitted to vuo.org
  • Reviewed by Team Vuo
  • Open for community voting
  • Chosen to be implemented
  • Released

Votes

22 votes so far!

Who voted?

balam's picture
seanradio's picture
Bodysoulspirit's picture
jersmi's picture