jstrecker's picture
Jaymie commented on Philip's Feature Request, “More type conversions

Philip, OK, I see how that could be helpful for debugging.

Opened for voting.

jstrecker's picture
Jaymie commented on Philip's Feature Request, “Nodes to convert from Text to most other types

Philip, good point. I've updated the "Notes from Team Vuo".

Opened for voting.

jstrecker's picture
Jaymie commented on Philip's Feature Request, “Allow more data types in Calculate node

Opened for voting.

jstrecker's picture

The first option, disabling the standard shortcuts when they're overridden, sounds good. Opened for voting.

cwilms-loyalist's picture

It probably does make sense for all of these device nodes to behave the same way.

unicode's picture

Here's an example composition which demonstrates the issue.

dumski's picture

Hello Chris, 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 :)

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

Cheers, Teo

Pianomatic's picture

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.

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 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. We post about once per month.