There are two main ways I think about a scriptable editor: scripts and rules/macros. This may need to be split into requests after a discussion but it makes sense to consider concurrently initially I think.
Scripts are routines run only when initiated by a user and are written in a high-level language like Applescript. A script might start with a key shortcut, do something (like tint all nodes to default Vuo colour set) and then end, or it might stay running, like to backup the current file by saving a copy of the file every n minutes to some backup folder then purge files at end of document editing session.
Rules or Macros would be executed in the Editor runtime loop every redraw/refresh cycle and might be as simple as a creating some rules using If This Then That logical choices from pulldown button lists in some kind of modal Preference interface: eg. if: “any” — “cable” is “connected to a node” — “title” is [“Fire At Start”] then set “cable” — “Appearance” to “Hide”. Similar to filtering a Finder Spotlight search. Choosing only from button options that the Vuo team have made available at this stage. My inspiration is from Tinderbox that has rules, agents and adornments that constantly update the visual appearance of notes (nodes in map view) according to note contents as the user edits it. Can also do summarising and counting type operations.
Scripts
We can currently script many OS X applications with Applescript/Javascript. Scripting Adobe apps opens worlds of creative possibilities and permits massive time saving utility that keep some professional Applescript/JS script writers employed full-time.
The main reason I ask for this is because i think it would allow the Vuo community to advance the Editor functionality and user experience much faster than will otherwise happen, while also creating opportunities for experimentation with the UI that might precede feature requests and incorporation into the canonical Vuo Editor.
This would free up our user requests and Vuo team hours for more important core Vuo functionality advances once indicated on the Roadmap including new and improved node sets for countless things and improved under the hood operations, more flexible and integrated local sub-comp interaction, sub-comp/viewer window GUI elements, compile to other systems e.g. iOS/NaCl/Windows/Linux, Windows/Linux Editor one day to get more users onboard.
I’d envisage that when a script is shared and appreciated by the Vuo community it gets a lot of the conceptualisation and implementation aspects debated and decided in a real way through prototyping and using it prior to the Vuo team accepting a feature request for integrating a particular script’s functionality as a core Vuo Editor functionality.
Existing feature requests that this feature could facilitate at the scriptable Editor level:
- Option to temporarily disable/turn off nodes
- Fire all Fire on Start nodes when the “q” key is pressed with either Editor or Vuo Viewer app in foreground. <— I just noticed this was included as Fire with Command + “T” (or something) in Vuo 1.0 (or something)
- Set default tints in the node library
- Option to temporarily disable/turn off nodes
- Possibly this if Applescripts could get node dragging evens then this one: Optionally preserve incoming cable connections when duplicating a node
- Insert event blocking nodes before cables into a selected node to disable it and undo. (Feature request to disable nodes). Even if this feature was added it may be hard to get the Vuo Editor to execute the function on a selection of nodes (i.e. >1 node at a time). Script could take care of that and recolour all the disabled nodes some colour.
[Will add more later.]
Other things I think it would be great to have a Scriptable Editor for:
- Arrange and distributed nodes (Left/Centre/Right align or distribute evenly) (Max has this in the Arrange Menu)
- Declare a default node colouring pattern set (think QC 3 with blue generators, green processors and red renderers) to be assigned for new nodes or replace existing node tints — especially with in case of 3rd party compositions and sub-comps
- Set user preferred set(s) of node colouring patterns to switch between or convert 3rd party sub-comps to for legibility.
- Insert a library item of commonly used nodes in a pre-wired configuration. (Precursor to a Library style (DTP apps) floating palette of often used nodes/sub-comps to get pasted in as pre-wired nodes at current level not as sub-comp) e.g. Window Renderer with properties like Title that is gets it’s property set to the composition file name (so when I have ten compositions running I know which is which).
- Find the Editor window for the Currently Selected Viewer window and bring it to the front, and find Viewer window for Current Comp.
- Assign a set of node tints to the function keys F1-F12 (have the OS X functions out of the way via Fn + Function Key in System Prefs)
- Update old 0.9 and earlier compositions by removing offending nodes and rewiring replacement nodes as per previous nodes.
- Find/Select/Replace Node instance(s) or some other text on canvas or in node inputs.
[will add more later]
What would need to happen:
I suppose the logical way to do it would be to make the application scriptable the way other apps do using the OS X framework for that.
- Nodes themselves would need to be able to be created, have properties get & set-able i.e. title, tint (i’d prefer open slather on colour choices once it became easy to revert all nodes to Vuo default tint set), graph position (x,y) and port connection destinations as a minimum.
- Scriptable messages to node input ports for getting and setting values and firing events.
- Simple Vuo document handling so for e.g. a selected set of nodes could be copied and pasted into a new document and then saved as a new version of the file or a sub-composition.
- Ability to detect interaction with composition in Editor or at least changes to composition
[will add more later]
Macros
As already stated I think the easiest way to execute useful macros would be pull-down lists for If This (Menu(s)) —> then That (Menu(s)). Another more complex way of doing macros comes from Tinderbox (but possibly less work for Vuo team to set-up). I won’t go into how they do it, but it involves comparing expressions using $attributes with string literals to invoke various actions. You can read more about agents here or in the Tinderbox Getting Started PDF available from the demo version Help menu.
Things I think it would be great to have a saveable list of Macros executing in the Editor for:
- Change node fonts faces and sizes, colours — essentially very basic node skinning rule system according to node metadata or typology or creator set. Could be used for easy switching between a universal and consistent VUO colour theme (canonical) and personal preference of auto colour/Font/line assignments for different programming modes. Also errant input value flagging in the Editor etc could be achieved with this.
- Highlight all nodes that accept certain datatypes (like my custom 3D Mesh object datatype say) in bright red with bigger fontsize on titles.
- Highlight all node that haven’t fired since composition started in flashing Amber colour (if runtime has even seconds set bright amber state if runtime seconds is even then set dim amber state)
- Draw event cables with dashed line while data cables in 2pt line. Cables carrying for example “3D vector list” or “complex number” datatypes in extra heavy red cable style.
- show all nodes and cables unchanged since last save in dimmed state
- Autosnap new nodes to grid
- Auto left-top-align new nodes to nearest neighbour
What would need to happen ‘behind the scenes’
- Node and cable rendering stuff in Editor having certain aspects of ‘state’ that is alterable in realtime each time Editor redraws or refreshes it’s view.
- Fonts and line weights and colours not hard wired but mutable
- Colours assignable to graph objects like nodes and cables not just the predetermined set of Vuo tints
- Node cartesian position get and set-able.
- Editor layout grid with user adjustable dimension (in Prefs) for snapping nodes
- Some kind of interface to set up rules or macros. Maybe like Mac Mail.app sets up rules as a minimum. Possibilities are extensive. Least effort implementation might be a box you can type an expression of code into would be easiest to implement for Vuo team. eg. Query: $node.class ==“vuo.math.*” Do: $node.color= “magenta”