jstrecker's picture
jstrecker's picture
+0

Try this:

A couple of differences from your composition...

jstrecker's picture
@jstrecker commented on @dthietala's Question, “Node outdated or broken

In case you're still having problems, another thing to try is to delete Vuo's cached files. Go to Finder (e.g. click on the Desktop), then go to the Go menu and hold down the Option key, and select the Library option that appears. Go to Library > Caches > org.vuo, find the folder corresponding to the Vuo version you have (probably 1.1.1), and throw it in the trash. Or you can trash the whole org.vuo folder. It will be regenerated the next time you run Vuo Editor.

useful design's picture

Hi @bLackburst yes, good point. That was certainly one of the intentions of my window in window mock up show above.

I used to make QC layers for BonixTV/mimoLive and at a certain point you had to add all the protocol layer stuff and save the file and open it in BonixTV/mimoLIve to test it, but at least you could keep the file open in QC and keep saving it and just reload it in BTV. Much harder though not having live testing. That's part of what makes visual programming attractive after all.

If i can get a prototype working of the pan and zoom I'll do it. I attempted it back in 2011 and it was too hard for me in the end in QC at that time. I had simple panning and cursor states changing with modifier key states for pan and zoom in/out like with Adobe products and 3D apps. But when I added the zoom functionality into the prototype it got way messy and slow which defeated the purpose of showing how cool and slick it would be. Maybe I should attempt it in Vuo (or Origami Studio!) and see if performance and functionality improves? Anything involving prototyping maps with zoom that has to track object locations is hard work in QC/Origami… I've tried with several projects and I end up giving up. Nobody else has ever posted anything that has succeeded to Origami FB page either.

bLackburst's picture

It might be worth making mention of the fact that macro/group/collapsed nodes should be live-editable, unlike the current subcompositions. It's really time consuming atm to make changes to a subcomposition while there is no data coming into/out of it. Saving, re-opening etc to see changes effect.

useful design's picture

Also I've previewed a few of the UI improvements I'd like in these images, should I individually list them as FRs or is that not really something Kosada are focusing on ATM?

Eg 1. data splitter node on cable as a simple 'dot', 2. different line styles for cables of different data classes: event, data, lambda (could be expanded to include one for Lists of Lists datatype). These line types are common in working drawings in Architecture/engineering and in maps for a good reason, improves readability immeasurably. It's easy to distinguish lines from one another and filter out what you aren't looking for. Also good for Colour Impaired vision people where coloured cables aren't of so much use.

useful design's picture

Hi @Jaymie. Could we please change the title of this FR to more accurately indicate what some of us are after with this: a basic Marco in QC terminology node or "Group Node" as @Chris called it here.

Seems like there is a complex issue around events filtering on input ports that may apply differently in each of the three kinds of sub-composition concepts floating around now.

If i'm right in summarizing those three are:

  1. Current case of sub-composition where the Vuo file appears in the Node Library. When you edit the master file for the sub-comp it changes all the instances in other Vuo files that use it.
  2. New concept of sub-composition that also has edit in one instance and replicated throughout all instance but only in any given Vuo composition (local sub-comps).
  3. Group Node which is for reducing screen clutter and speeding up Editor redraws when a composition is open in Vuo Editor (this request).

As mentioned elsewhere, would need some kind of subtle UI indication of scope i.e. itself/local-composition/global. Suggestion:

  • Round corners ⇒ isolated "Group Node";
  • square corner ⇒ local sub-comp (appears in Node Library window under a "Local Nodes" heading);
  • chamfered corner (no difference in appearance to regular nodes in the UI schema in the illustration) ⇒ universal sub-comp (appears in node library and is available in all compositions).

If you have sub-graph editing in a window in window situation as I'm re-proposing (maybe that should be another FR for itself) then I think you'd need to have Vuo Editor notify users of external changes to the universal sub-graph when they open a new Vuo file that uses a universal sub-composition that has been changed since the Vuo file was last opened. I'm not sure how Vuo handles that situation at present.

useful design's picture

Excellent point. Maybe there could be a special published input port (event-only) that transmits an event if any published input port transmits an event.

I'm not sure why I made this input labeled ">" for sub-graphs and passed through also labeled ">" back in Sept 2011. But i figure now it was for passing events(?)… it could be used to not only pass events from the ">" Input, but any of the sub-composition inputs. So an event on Input 1, 2 or 3 would pass an event to ">" going to the event input of the Node shown inside the sub-graph. Being a subcomp there's plenty of room for an extra default input at the top.

For more details on how I envisaged sub-graphs of any of the kinds we're talking about opening and closing in the Editor rather than as separate files for editing see this thread where I FR for Macros/Group Nodes (1. Library node which is universal, 2. Local comp restricted subgraph that also can have many instances and possibly also appears in the Node Library perhaps under a "Local Sub-Graph Nodes" Heading and 3. Group Node which is stored in the owner Vuo file and has only its own instance).

useful design's picture
@useful design commented on @Kewl's Discussion, “CPU efficiency in Calculate node

This is probably one of the advantages of Vuo nodes being coded in C, closer to the metal. Correct me if I'm wrong, Jaymie but I always thought QC was too slow on iterating maths patches and screen draws for simple objects like GL Lines and that was why I looked forward for a C based implementation of nodes and modern GLSL implementation of rendering. Although now I don't do this kind of work much :-\

useful design's picture

Okay here's the FR: https://vuo.org/node/1723#comment-4221

Coming from this discussion around the local sub-comp FR, which is more of a virtual node kind of idea: https://vuo.org/node/1185

Pages

Welcome!

Vuo is more than nodes and cables, it's a community! Feel free to browse or add your voice.

Browse Discussions

Start a Discussion


Browse Questions and Answers

Ask a Question


Browse Feature Requests

Suggest a Feature


Browse the Composition Gallery

Share a Composition


How can I get notifications?

Learn more about the community

Learn more about Vuo

Vuo Announcements

Sign up for the Vuo announcements mailing list to get news and join the community.