dir people interested in our nextbigthing that is VL,
we’ve taken a bit of rest after node15 and are getting back into our business of creating serious visual programming experiences…
Feedback regarding VL so far has been cautiously positive and some of you already encountered the most pressing features that are still missing. On our road ahead we want to ask you to help us identify the best order in which we implement things. So of our long list of features that we’re definitely going to implement, we’ve extracted 5 for you to vote on.
Regarding the selection: Those features are only the top five results of our internal voting. Also they only include features we thought we can clearly communicate. Of course there are many other issues we’ll address independently anyway.
Think shortterm: Which of the following features could your patching most benefit from?
- Type Browser: At the moment you still have to know the exact spelling of possible types by heart. The type browser will assist you when annotating the type of a pad by providing an auto completion list with all types valid in the current scope.
- Automatic Type Converters: At the moment some links (like Float64->Float32) can not simply be made without manually placing a converter node (like: ToFloat32) in between. We’ll introduce special links which convert a value from one type to another and will directly allow you to make such connections saving you quite some clicks.
- Custom Enum Types: At the moment you cannot define your own enum types. You need this in order to be able to create operations like “Map” that can switch between different modes, like Wrap, Float, Mirror…
- ForEach Component Region: At the moment when you want an operation to be applied to all components of a vector at the same time you’ll have to split and then join it again. We’ll introduce a new region especially made for vectors which executes its body for each component of a vector. This allows you to use nodes working with scalar values on vectors without doing the splits and joins manually.
- Dynamic pin counts: At the moment nodes always have a hard-coded amout of pins. Nodes with potentially dynamic pin counts (Cons, Group, …) will automatically get a pin added when the mouse is close and a pin removed when a link gets deleted. This means no more changing the pin count in the inspector.
Voting ends on June 14th.
Why Flattr? This excludes a large number of people who can vote?! Well, first, anyone can easily sign up to Flattr here, and on the other hand it specifically invites those who probably take this a bit more seriously. So this is an experiment. Looking at the list of vvvv flattr users it seems that we have a potential of 27 votess in total at the moment. Lets see how this goes..
Still not sure about that flattr thing? Read the rationale again: Flattr on vvvv.org.
Very much looking forward to your votes, devvvvs.
Comments:
Comments are no longer accepted for this post.
true concat works already, cool,
btw the enable pin has always the first input as default, thats a bit strange but maybe just a point of getting used to it. it would be cool to use the enable-pin as a sample+hold-button? like: when disabled the output will not change, now the output still changes when disabled..
by the way, the first version of the TypeBrowser is now available in the alpha builds. feel free to test it…