A UI for storing and loading the state of running compositions

[Original title: PATCHbANK facility for compositions… like an eighties synth memory pretty much.]

This request involves having a facility for saving and recalling composition states at various special nodes in the composition (or if possible already with all Nodes then that would make it less work for users removing the need to put PATCHbANK nodes around the composition to capture and recall data states).

I got a decent way into the process of setting this up in QC as a QC tool that could broadcast to other compositions. I divided it up into a MVC kind of setup and wrote separate compositions for each of this ‘trinity’ of parts. The PATCHbANK patches that were to go in your comp talked to a separate Controller composition (see image) sending state data while also passing it through, and when receiving Patches recalled messages, changing the data to those messaged data states.

Never brought the whole thing together because the Controller became a monster time sink, it was kind of like a very miniature VDMX sort of thing I realised, with the advantage that generative states could also be recalled (not just published values), like a image you had painted Live using your mouse and composition effects for example.

The main motivation was that even with a single composition without changing patches but just modulating a whole bunch of input port values one could easily generate dozens of different looks for the one composition. Saving a file for each state seemed like a bit much, and if you improved the composition at all, even one new noodle, then you’d have to manually transpose all your saved patches to the new version. I much prefered the old Roland analogue synth (Jupiters and Junos) set up with a digital memory where you just hit a unit number (sometimes preceded by a Bank number to change patch) and to write a patch you just hit write and then the Bank and Unit keys.

I set this up so you could even use a midi music keyboard to change patches or write them, Black keys for BAnk, White keys for Unit. Hence the odd arrangement of buttons on the draft UI.

Anyhow if it’s of interest longer term to VUO please raid the memory bank. I have a semi-working QC app of the controller part, but it doesn’t actually talk to the the PATCHbANK nodes that do the work in your composition. I got the PATCHbANK inline Patches working also, with simple save to plist and recall but just as proof of concept for each data type including structures and images.

Will tidy and post a demo comp for the feelz.

Opened for voting.

I like this idea! But I’m not sure about the need for a UI to do it, more like interface nodes to facilitate it.

My entrance to node based programming was through NI Reaktor. There they have a “Snapshot” system for storing and recalling represented by a master control node, a snap value node that lets you specify single values (outside the UI elements) to store in a snapshot, and a snap value array to store arrays in.

The control node is interesting. While it is absolutely massive both in inputs and outputs, the core part of it is basically an A setting and a B setting and a morph control between the two. Standard UI elements are stored automatically, other modifiers need a snap value connected.

I’m then thinking that if there was a way to have a master control node of states/a snapshot, and a way to morph between the values in the different sets it could be a good place to start. Instead of UI elements, it could store the value of unpopulated ports with number/vector inputs as you then wouldn’t need any extra UI stuff to manage it. If you publish a port, it could have a state node connected to store the value coming from the host, and you could also publish the master nodes controls to manage states and morph between them from within a host.

1 Like