[Originally a bug report titled: Published inputs in subcompositions receive all events to any port]
Install Pianomatic.countSubcomposition.vuo node.
Open Subcomposition Event bug.vuo and run.
Observe the console window.
The Count Subcomposition node only has a Count node inside it, and so should output the same result as the composition’s Count node. Instead, It increments and decrements the count with every event, resulting in an overall increment of 2 (increment of 3 and decrement of 1) with each event, instead of alternating between incrementing by 3 and decrementing by 1.
The expected values are 3, 2, 5, 4, 7, 6, etc., but the actual values are 2, 4, 6, 8, 10, 12, etc.
Implement an “exploded” version of a subcomposition that requires sending events through specific paths within the subcomposition.
Philip, as you saw, the difference between the built-in Count node vs. the subcomposition is that only the Count node has the ability to distinguish events that came in through a specific input port (indicated by the little port action triangle). I’ve converted your bug report to a feature request to add this ability to subcompositions.
That an event into a subcomposition goes through all published inputs is intentional. The purpose is to make things less confusing from the perspective of the top-level composition (using the subcomposition as a node), though unfortunately it leads to some confusion from the perspective of inside the subcomposition.
Here’s an example to illustrate why the event goes through all published inputs. This composition overlays a checkerboard on a radial gradient:
The event into the Overlay Checkerboard node’s Background input port goes through both the Background and the Color published input port. If it didn’t, what would happen? Editing the Overlay Checkerboard node’s Color input port would have no effect. You’d have to do some extra work to avoid the problem, either in the subcomposition (connect an event-only cable from Background published input port to the Make Checkerboard Image node) or in the top-level composition (connect an event-only cable from Make Radial Gradient Image to the Overlay Checkerboard node’s input port. This would be a hassle for the person creating the subcomposition, and even more so for the person using the subcomposition because they’d have to look inside the subcomposition to understand what all ports need events fed in from the outside.
So generally it’s more convenient for the event to come in through all published input ports. However, there does need to be a way for it to come in through just one, to support port actions — hence this feature request. How we might implement this — maybe be able to right-click on a published input port to turn it into a port action, which would add a companion event-only published input port that outputs an event only when that specific input port got an event.
@jstrecker,
I understand that this behavior is intentional, but I also have a big problem with it. I think inability to change this behavior makes impossible to use subcompositions in some more advanced way… Let’s say: like functions/procedures/subprograms.
Your above example is good, but only for basic use of subcomp. BTW, If event would not go through Color port, we should only connect Background port to Refresh port of Make Checkerboard Image with event cable, am I right?
If so, it’d be more efficient way of using subcompositions – you wrote that it’d be more confusing from the top level. Yes, but I think price of this decision was greater: when we want to use subcomp. more like a macro or sub-program it becomes very complex cause we have to filter almost all events becoming to subcomp. on input (with Allow Changes and/or Allow First Value node - BTW, Allow First Value node was perfect shot - thanks for that :) When I try to build such subcomp. they become very
Maybe it’s a matter of philosophy, but I think more users are used to treat subcomp. as subprograms, which can take a lot of inputs (ports) and choose between them or/and mix not only values of them but also events. This would allow us to use subcomp. in more complex way.
Maybe I’m missing something, but honestly I’ve been waiting for Subcompositions a long time and when I started to use them and realized this all-ports-events behavior I bacame a bit dissapointed about that. Now we can use them only basic way.
BTW, I didn’t find any dicsussion/post about philosophy behind Subcompositions. Even in recent manual there is not a word about how to use them but only how to create them and remove them :) If I could suggest something, the “understanding subcompositions” chapter would be very helpful.
Please correct me if I’m wrong - once again: maybe I’m missing something :)
@dumski, thank you for bringing this up. Based on the numerous questions and comments we’ve gotten about published ports over the past several months, I have to agree with you that the current behavior is not very user-friendly.
For each published port, in different situations someone might want the option to:
transmit all events that come in through any published port (current behavior)
transmit only events that come in through that port
transmit only events where the data has changed
transmit no events (wall)
Maybe Vuo should offer all of these options?
If event would not go through Color port, we should only connect Background port to Refresh port of Make Checkerboard Image with event cable, am I right?
No, not with the current behavior of published ports, because an event is required to carry the data from the Color published port to the Upper Left Color input port of Make Checkerboard Image.
(With the “transmit no events” option I proposed above, I think the answer to your question would be yes. If the Color published port transmitted no events, and the Background published port transmitted only events that came in through that port, then the data would have to automatically transfer from the Color published port to the Upper Left Color input port — along the lines of the proposed detached constant flags or data-only cables.)
Even in recent manual there is not a word about how to use them but only how to create them and remove them :) If I could suggest something, the “understanding subcompositions” chapter would be very helpful.
Yes, unfortunately we don’t have much documentation on subcompositions yet, but plan to add more to the manual to help with understanding the concepts.
For each published port, in different situations someone might want the option to:
transmit all events that come in through any published port (current behavior)
transmit only events that come in through that port
transmit only events where the data has changed
transmit no events (wall)
Maybe Vuo should offer all of these options?
Yes, I think this idea is perfect. Especially that it merges cleanly with already implemented port event options (but currently not selectable by user). It gives us ability to control input events flow completely. And, of course, these options should be available for every port separately (and the defaults for this options might be the current behavior :).
With the “transmit no events” option I proposed above, I think the answer to your question would be yes.
Yes, I meant not current behavior but the “transmit no events” behavior :)
…along the lines of the proposed detached constant flags or data-only cables.
Hm. I think transmit events options would solve more problems, even data-only cables. With this feature we can build simple nodes turning current cables into data-cables (something like “allow changes” node does). Maybe it’s not necessary to make another category of cable but only make a bunch of nodes that handle, let’s say, conversions of cables.
When you have this situation:
—>data+event cable------ [allow changes] ---------- “data-only cable” ------- [hold node refreshed by next node] ---->…
We can achieve this, amright? (of course, this “data-only cable” is fake, but on the end holds a value without transmitting events :)
I think a good direction of development in many cases is to make decisions which give users more control on behavior of composition parts. This allows users to use nodes more creatively and finally achieve more solutions for theirs goals.
@jstrecker, could youplease please change the title of this feature request to something like “change subcomposition’s input port behavior”? It may be important for other users clearly see and can vote on it.
Could youplease please change the title of this feature request to something like “change subcomposition’s input port behavior”? It may be important for other users clearly see and can vote on it.
Thanks
Yep, I’ve never really understand what this FR is about ;)
Perhaps something like “Support all port types in sub-compositions (events too)” ?
Sorry for my long delay in responding to your previous message, @dumski. We (Team Vuo) have been working on a plan for making events into published input ports behave more intuitively. Before promising anything, I wanted to make sure there weren’t any “gotchas” that would make a plan impractical. Well, it looks doable, so I’m marking this “chosen to be implemented” (and have updated the title).
In discussing the various options for how published input ports could transmit events, really the biggest question was: Should an event into a published input port go through all published inputs (current behavior) or just that one published input? Each could be useful in different situations. Event-through-one seems to be the behavior that more people expect, and seems to make sense in more situations, than event-through-all (current behavior).
Above, I had floated the idea of offering both options. However, in discussing with my teammates, we realized it could be pretty confusing if one subcomposition could behave one way and another could behave a different way. We already get a lot of questions about events, and having different modes where events could behave differently could make Vuo harder to understand.
Instead, we’re thinking of universally changing the behavior from event-through-all to event-through-one.
If you were making a subcomposition and you did want an event into any input port to go through all published input ports, you’d be able to achieve that pretty straightforwardly by adding some event cables to the published input ports.
Well, the explanation is getting kinda long, so I’ll stop there. Let me know if you have questions.
It seems with the implementation you discussed, existing subcompositions are going to behave quite differently. If your goal is to avoid increasing the number of questions regarding events, I suspect this may not do the trick. Assuming this will be available with Vuo 1.3, I think there needs to be some way for us Vuo composers to tell, at a glance, which Vuo version(s) a subcomposition will work with. Is there, perhaps, something that could be inserted into the source code of a subcomposition starting with 1.3 that would allow 1.3 and onward to give a visible indication if it has pre or post 1.3 behaviour? Maybe it could go in the comments section at the top of a composition source code file? (As a connected thought, this could also be used to indicate whether there are nodes that have changed behaviour, or have been upgraded since a composition or subcomposition has been built.)
With events going only to a single published port at a time, what happens to the data? In the image below, if Value 1 receives an event (and some data) and maybe there’s some manually inputed data on the other ports, will the manual data still make it through? Or will Value 2 and Value 3 have null data? If the latter is the case, I have concerns again about the behaviour being what Vuo composers expect. It seems to me that the data should be available for the subcomposition to use, even if there hasn’t been an event sent into those ports.
If a subcomposer wants events to be sent along routes in addition to where the received event arrived, it could get a bit unwieldy to deal with. See the image below. Is it possible that there could be some mechanism built into the editor that would allow for an easier (and less messy) way to make this happen?
All this said, I’m looking forward to having finer control over event-flow into subcompositions. I’m working on some subcompositions now that, once the new behaviour is implemented, will all fit neatly into a single subcomposition. (A cause for celebration!)
Maybe I’m misunderstanding the context of the initial feature request but I think there are 2 distinct reasons for using “Sub-Compositions” and each has it’s own expectation for how events should flow.
To create a node set as a single node that can be added to the node library for repeated use in other compositions (transmit all events that come in through any published port)
To clean up and simplify a very busy or complex composition in the editor canvas (transmit only events that come in through that port) or maybe (transmit only events where the data has changed) so the nodes don’t change behaviour when grouped.
I think if they were 2 separate features…
Save Composition to Node Library (the current feature)
My main beef with the current sub composition behaviour is that on the outside, it looks like any other node, but it’s impossible to build a sub composition that has actions associated with event arrival at specific ports, which is very common among Vuo’s included nodes. The sub composition I submitted with the original (but report) post was a demonstration of this issue, using a Count node essentially inside a wrapper. Putting it inside a sub composition killed its functionality.
We need (or at the very least, I want) to be able to have better control and flexibility over events flowing into a sub composition, otherwise the ability to expand the functionality of Vuo will be limited only to people who want to program that functionality in C. That is a limitation I’m not willing to be stuck with, as it misses the point of being able to program completely in a visual environment.
The nice thing about the proposed change is that it will allow a composer to implement the old behaviour while allowing for far more complex functionality if desired.
Hello @cwilms-loyalist,
I agree that ability to group nodes and comment them would be VERY useful. But this request (in my opinion) is more for option 1) than 2).
Maybe it depends on how complex subcompositions you want to save for another use. From my experience current behavior cleans up some very simple reusable subcompositions. But it’s very inconvenient in some more complex situations. I build huge sets of nodes which take many options and produce some live image (for example drawing by mouse or tablet). In that case I have to filter almost ALL incoming ports for unneeded events (for options like thickness, opacity, color which change sometimes) because of ONE incoming port (mouse position which changes more than 100 times/sec). In that case there is hundreds of “fake” events generated due to current behavior of incoming ports. Performance is VERY poor.
So I think there is some third option you did not mentioned: reuse of node which takes params and produces results based on variously changing params :)
@jstrecker, sorry for such a long time of silence :)
Yes, I agree that changing to event-through-one behavior universally is good idea. In that case you can achieve event-through-all behavior more easily than in opposite direction (I’m curious if I wrote that in English :)
But, of course, ability to choose a behavior of ports for every subcomposition would be great.
It seems with the implementation you discussed, existing subcompositions are going to behave quite differently… I think there needs to be some way for us Vuo composers to tell, at a glance, which Vuo version(s) a subcomposition will work with.
@Pianomatic, we could add a “created in Vuo version” metadata that appears in the Node Library documentation area. We haven’t been storing that information in compositions so far, but if we added it in Vuo 1.3 then at least you could tell if a subcomposition was created before or after.
When making significant changes to the built-in nodes, we’ve been leaving the old node in Vuo but marked deprecated (it doesn’t show up in the Node Library) and adding a new version of the node. This avoids breaking old compositions.
With events going only to a single published port at a time, what happens to the data? … It seems to me that the data should be available for the subcomposition to use, even if there hasn’t been an event sent into those ports.
Agreed. The plan is that, when you edit a port’s value on a subcomposition node, the new value propagates immediately to the connected input ports inside the subcomposition. In your example, if you edited the port Value2, the new value would immediately show up in the Value port of the Value 2 node (but it wouldn’t cause the Value 2 node to execute).
If a subcomposer wants events to be sent along routes in addition to where the received event arrived, it could get a bit unwieldy to deal with… Is it possible that there could be some mechanism built into the editor that would allow for an easier (and less messy) way to make this happen?
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.
@jstrecker, It’s a little different than I was thinking, the Blender video link shows pretty much how I was thinking it could work. Functionally I guess the two methods might be the same. Will a composition-local sub composition like that also be precompiled the way a regular sub-composition is? If so, there is a potential performance improvement doing it your way over the way I was thinking.
I think my main concern with sub compositions stems from my experience so far with them. I’ve found they sometimes don’t work how I think they are going to work. For instance I will take a specific set of nodes out of a working composition, make them into a sub composition and publish all the inputs and outputs I need to use, place my newly created sub-composition back in my main composition and it won’t work anymore. However if I copy those same set of nodes and place them back in the main composition and reconnect them functionality returns. (Either I’m not understanding how they work or it may have something to do with how events flow… https://community.vuo.org/t/-/5416). I guess I was thinking that grouping a set of nodes the way Blender does it would be a simpler procedure than the process of making a sub composition and things would continue to work the way I expected them to.
Ideally the way I would LOVE to see it work would be to group them the way I was suggesting and once things are working correctly you could right click the group and save that as a sub-composition that could be also used in other projects. Maybe a right click menu with “Save Group as Sub-composition” and “Save and Replace Group as Sub-composition”.
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).
Changed subcompositions so each event enters only through the input ports that the event hit (instead of all input ports). Implemented in Vuo 2.0 beta. See more about this change on updating compositions to Vuo 2.0.
