This site relies heavily on Javascript. You should enable it if you want the full experience. Learn more.

VL Feature Voting

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.

/blog/vl-feature-voting?1|Type Browser?

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.

/blog/vl-feature-voting?2|Automatic Type Converters?

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...

/blog/vl-feature-voting?3|Custom Enum Types?

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.

/blog/vl-feature-voting?4|Foreach Component Region?

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.

/blog/vl-feature-voting?5|Dynamic Pin Counts?

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.

joreg, Sunday, Jun 14th 2015 Digg | Tweet | Delicious 12 comments

Gareth.Griffiths 03/06/2015 - 15:20

Love the flattr idea for votes.

hrovac 09/06/2015 - 14:26

this made me sign up to flattr, thank you!

tonfilm 09/06/2015 - 14:48

one person can now decide between type browser and dynamic pin counts... ;)

microdee 15/06/2015 - 00:58

where can i flattr the API? :P

joreg 15/06/2015 - 01:06

So it seems we have a winner, horray. Thanks a lot to every voter. I'm particularly happy to see 7! people who've newly registered with flattr since we started the voting. It is now on us again. Keep an eye on the devvvv blog to stay informed.

bo27 17/06/2015 - 15:31

tonfilm 22/06/2015 - 22:07

by the way, the first version of the TypeBrowser is now available in the alpha builds. feel free to test it...

sunep 22/06/2015 - 22:46

That was quick

hrovac 29/06/2015 - 21:07

i was one of the supporter of the dynamic-pin-count--thingie..
i really like the solution for *+-... sweet
so, i just wanted to tell you, that this would be perfect for cons,concat ...imo
..just saying

Elias 29/06/2015 - 21:26

Well it should be there for Concat. For now it gets applied to all nodes following the signature (Input, Input 2) -> (Output) and type of Output is a subtype of type of Input. If you build your operations the same way the dynamic pin count will be applied to those nodes too. The system internally simply replicates the node in question and connects the in- and outputs.
Cons doesn't follow that signature and therefor the feature can't get applied as it is right now.
Also note that the Enabled pin works in a similiar fashion, should a node follow the signature (Input, ...) -> (Output) the enabled pin will be added. Internally the node will be wrapped in an if region.

hrovac 29/06/2015 - 21:48

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..

microdee 30/06/2015 - 11:47

@hrovac: think with properties and objects, if you set a property of an object it will stay that way until you set it again so you don't need S+h

VL Feature Voting

Shoutbox