Would you please port this to VL?

if i understand you correctly, you’re asking why IF doesn’t do the S+H automatically, right? you’re asking why do you have to create those 2 pads manually to achieve the S+H effect?!

the answer to this question:
because the IF doesn’t care. there are many cases where you just want the IF without it doing an S+H. in this case storing the last computed value makes sense, so you can do it using those two pads. or you can use an actual S+H if you prefer, like so:

@catweasel

we can do that in vl already. there is an example here: girlpower\VL_Experimental\Async please start a new thread with your usecase so we can have a look at it.

Not exactly. I’m asking why, without the two pads, which must have the same names, nothing is returned to “root” patch (or why I need to set and hold values).
The “result” outlet is just a graphical hint, with the only scope to create a pin usable in vvvv?

Edit: it may also seem everything really obvious to you, but that’s not the case for a few people, like me.

ah! the answer to that is:
removing the StringSpread pads still leaves you with the inputs and outputs ♦ on the IF region. and the input ♦ in that case, that then has nothing connected is responsible to return “nothing” in case the IF is not executed. see?

This is an output pin. it shows up in vvvv or other vl patches.

Would you please rephrase that? I can’t get everything. Thank you.

IF not executed? Mh… Why it should not be executed? Are we talking about async stuff? The whole pads ting, is about managing that?

my bad use of wording: the IF is indeed always executed of course (no async stuff, nono!). i mean basically the ELSE case. so if IF is true, the nodes inside the IF region are being executed, ELSE the input ♦ is passed through to the output ♦ unchanged.

some more on the IF region:

it took us 2 iterations to come up with the current design of the IF. the challenge here is to not optimize the region for one specific use case but for all possible use cases in the data flow context of VL.

for example, it needs to work in patches that cannot hold state, so giving the IF a data field to store something is not an option unless we would make two versions of it (hell no!). so consider this example:

no input/output needed at all.

or this:

automatic S+H would totally annoy you here, because you want to decide yourself what should be the output value in the ELSE case…

and regarding the diamonds, you only have to create one, the corresponding other will automatically created for you, easy. also, making a pad is only a shift+click after starting a link… so interaction wise also very fast. you just have to learn it once.

so as you can see, its the best and most general way to design an IF in a data flow context. only thing that is missing is patching the ELSE case. but we have ideas for that already.

bonus: you can also just patch your personal IF region with s+h inside on your own, if that is your 99% use case:

and use it like that:

if that doesn’t impress you… i don’t know what else would :)

@tonfilm
All of this is interesting, so I’ll keep annoying.

Let’s start from the end:

So this is clear, now.


(italic bold are mine) Eh, too many scenarios to figure out… Practical case? Something in girlpower?

This hold state concept… Ok. I removed pads from these vl examples posted here. If I link a true bool on top of IF, I get, indeed, the result out. From your POV it makes sense. I still don’t know why, tho.
I… it’s just that’s not present here in the usual patching flow, so I’m trying to figure out what problem would solve to me, or chances would open, for that matter.

Thank you.

Echoing what @catweasel and @h99 are saying, VL is a language that needs more visual references to learn from, and more example of how to do things…Some small, some big. And they need to be animated.

The videos were a good resource for picking these details up in the first off. The gifs in the dev blogs were useful to understand how to use the language too. I thing that for a visual language the text of The Graybook needs visual embelishing, preferably in gifs or tiny vids.

It may mean that a different form of documenting is needed from your typical microsoft database. What do the Devs have in mind? Something embedded like vvvv? Some easy way to make video clips built into VL and easy to propagate so users can help contribute? A keylogger style recorder of actions like macros to show how-tos interactively (Zbrush-style)?

You may need to do some sort of video lecture about the concept of data flow and how VL bridges this with respect to c# or f# programming patterns.

I’ll reserve my comments about the language/UI’s ease of use for more targeted observations because the infividual issues deserve their own threads.

Let me start off with appreciating your sentiments. VL is hard, confusing and sneakily expects a lot of code prowess to actually become useful. A gui that fragments the understanding of dataflow, the sorry state of ioboxes, the weird node browser and the lack of tutorials/help patches are not helping either.

If this sounds bad, it will get worse, even after you screamed wtf at your screen for the first time. Some core node libs are not homogenous (try replacing a Damper with a OneEuroFilter), and the general immutable approach will put extra pressure on you to always write back changes.

That is my standing with vl right now, after a hefty 5 week climb of its learning curve (@h99 don’t feel bad because other know more, I have had the pleasure of some vl testing as early as winter 2015, so never compare).

I am finding that vl is not finished yet. It will need a lot of work to be as productive as vvvv, because right now vl still makes fire with sticks. In a damp forrest, if you catch my drift.

With that assessment up front, I can assure you that most of your actual concerns are temporary.
The Pads with equally named Inputs/Outputs are your datatype definition, like a Formular for Messgae (if you are familar with that). At first glance they seemed awefully odd, but because they are very visual and quick to make (Ctrl and Shift are your friends), they grew on me quite quickly. The pattern is clear, and it will make click.

The state is a whole different issue. It has been a vvvv issue all the time, even if you didn’t know, and in effect a vvvv user was forced to keep a steady spreadcount if things were to run smoothly. This limitation was inconsequential for most visual experiments, but it was always a brick wall, when trying to patch a more flexible thing according to professional requirements (like multitouch, or something involving game elements). and it seems certain that vl needs more of the high-level nodes again to mimick the easy vvvv flow.

VL is a language rather then a replacement of vvvv, So it will take some years till all appropriate libraries will be brained out (hopefully with help patches). Please mind that it took 4 years of the devvvvs life to brew the language (and the gui, and the parser, and the IL compiler, and the error reporting, and the importer, etc…), and my humble opinion is that its concepts are epic. Epic enough for me to torture myself with it. What’s under the hood of this thing is an enourmous achievement.

But don’t let yourself be fooled by the confident answers of @tonfilm and @joreg. I am sure they are struggling with finding useful patterns, best practises and practical explanations just as you are. If you need a joke: Devvvv’s been so much under the hood of their vehicle, they must have missed out to drive it ;)

When I started vvvv (beta12 or so) doing projects was like making fire with some loose branches, in a damp forrest. There was not even a node browser, and spreads were just that, there was no Bin Size anywhere except on the GetSlice. But vvvv grew, and its versatility. Community input, contributions and new features from relentless devvvvs made it better. Standard patching patterns and avoiding the pitholes made patching experience more fluid, and less frustrating. Learning about dark secrets of vvvv (like state, binsize, limits of s+r, dangers of framedelay) made patching less error prone.

Of course, there was nothing more versatile to compare it to (unlike vl now), so accepting faults was much easier back then (for me personally, accepting that was not an option, so I started grinding the sdk, but that is another story).

But give VL some time, and your openness. Do it like you did it with vvvv: read girlpowers, and try to understand. Tinker. Learn keyboard shortcuts from the grey book. And keep your stuff in vl as much as possible, avoid making a family of vvvv nodes for your project, even if tempted.

It will take bright minds to build up vl to the state where vvvv is. The “easy” nodes of vl might look very different from the easy nodes in vvvv, but they will come. The current state of vl is neither a chicken nor an egg, but it definitely has the power to eventually fulfil its promise.

It will take concious patchers, that put in extra effort to highlight bugs, and share their experience (both the frustrating and the godspeed ones).

It will take great effort of the devvvvs to manage a friendly ecosphere and help with tools, advise and stellar open source attitude to add well-patched community code as quick as feasible.

And it will take a lot of teachers, who are ready to rationalize their own understanding so others can partake.

So to close this non-answer: learing vl is hard, and the current state of it makes it sometimes brutal. Own mis-conceptions about the nature of a patch clashing with the reality of regions will leave you confused and even frustrated. I can tell you that some will vanish (because regions are awesome, especially the foreach). Some other things might not, because they are not as well designed as they could. Both sides need to be valued here.

I am still confused about vl concepts myself, and dissatisfied by the lack of many essential nodes, but I am sure with enough curious minds we can eradicate those for future generations of patchers.

Please continue threads like this. We need more talk about shortcomings and user stories, if we want VL to progress: At this stage we should discuss visions and preferences, as much as small design details and frustrations. It will be a way to become better patchers ourselves, and make vl better for future patches.

Because eventually, every knowing hand helps.

5 Likes

Boom!
Fair play Sir, as fine an answer as I could expect!
I started beta 3 or 4 I think, we didn’t even have sticks, or groups anyway ;)
I think that maybe part of my worry is, that I can’t take another winter (or 5 winters) without fire, I might die of hyperthermia!

Wow, thanks @velcrome for your deep insights. Very appreciated.

What I read here is mostly the lack of missing documentation and explanation of concepts. The latter seems to be the more important one and until now there is virtually nothing in that direction online. This is a big problem for non-programmers indeed. How can you learn how everything works together and how does it help you with your patching problems? The solution might even look different for every person, some just want to explore examples, others might want to look at info graphics and a third one only needs a push into the right direction… So until we have extensive documentation please continue to ask questions, we are happy to answer them.

What I personally like was how you pointed out the importance of the community participation. I also think that feedback from as many people as possible will improve VL tremendously. So if anyone finds that a certain feature could work better or different, if you are missing nodes or anything else sticks out, make notes while patching an start threads about it.

Needless to say, we are constantly working on all fronts and all will improve over time. Late gratification is the real gratification!

I absolutely agree: in eight words, you laid down my post.
Now, I understand that new solutions must be found.
But I also think that my post has been mistaken for laziness. Well,

It’s a matter of design, VL does not represent visually a dataflow, as it is right now. That two of them pads, makes impossible to get what’s going on without further knowledge of concepts that are exclusive to VL in the vast ocean of coding languages and dialects. There’s nothing bad in this, but one the following must be chosen, and only one:

  1. concepts are made clear (via helppatches describing “real” problems, or any other teaching method)
  2. concepts are represented in GUI in a different way (one of 'em, like the concept of passing an argument to a function)
  3. concepts are not represented in GUI at all.

Please have a look at this thread: there is a problem that fits perfectly your words; yesterday I wrote that this state thing it was not something present in the usual workflow: well, I was damn wrong, it took a few hours of sleep to get it right.


That’s out of question. I already stated that VL is a language

and that it’s great

Although I can’t add one to one in VL, I already got where it’s headed. Mostly because I trust devvvvs.


This is a german developing and prototyping environment. Everyone here needs jokes, tons of them.
But indeed, taking the metaphor out, getting some rest and some beer, giving yourself the chance to look at things in a different way, shouldn’t hurt too much.


I feel the need to clarify that I’m all supportive.
I’m trying to get more vvvvers into VL, posting simple snippets of common problems that could help people understand how to VL. It’s not fearing to appear a noob while asking questions that will help things to improve. If you fear that, you’re a noob willing to remain it.

This, as expected, also brought up a nice discussion about VL.

But also another thing must be made clear. It’s not that if one discusses about what s\he thinks it’s an issue, that s\he destructively criticizing devvvvs work. Instead, it most likely shows an interest and the will to help.
I’d be much more worried about the (actual, real) silence about VL from the community in general.


Definitely.

1 Like

So, I was working a project, which has many aspects taken care by python.
One of the operation was to download some zip files, and to wait some time before starting the loop again and dl another file.

Today, with latest alpha I managed to use System.Net to create a DownloadFile node. Something was going wrong, red nodes and so on, so I killed vvvv, deleted the vl folder, delved a little deeper into the methods and so on. Unfortunately I was never again able to create the node. It said something about the need of unique names for vl (indeed it even didn’t let me to clone the template, until I put up the latest alpha).
The following pseudo code should be self explanatory.

int i = 0 int a = 2 for i < 10 { //this could be also a while loop or a do ... while a = pow(a,2) wait(10) //this could be seconds, but also frames i += 1 }

So as specified in the “comments”, also while loop is of interest, and of course frames other than seconds.

In vvvv I’d wait to get a positive return from some node (file is saved), feed a bang to a delay, then to a framedelay, then I’ll have to patch something to stop iteration so to cut off the framedelay from the flow.

I hope this makes some sense.

while loop will freeze your main thread untill it finished so it’s a really bad idea to use while + wait
not sure i understand what is your code doing spcially why you iterate using “i”

normally i would use something like:
{
if(star evaluation)
{
bool evaluate = true;
time = 0;
}

if (evaluate)
{
time += this frame time - last frame time;
if (time > wait time)
{
evaluate = false;
do whatever
}}
lastframe time = this frame time;
}

@antokhio
The pseudo code is there to help people with little to no coding background to understand what’s going on, as the for loop is probably the first thing you face after variables declaration in a coding tutorial, and very often has the infamous i that will increase a predefined amount of times.
As a matter of fact I wrote that simple example so that it would be immediately familiar to almost anyone with a minimum programming knowledge.
This thread is indeed by a noob, for noobs, guided by the experienced. But also should help grasp concepts to translate python to vl (why not).

Moreover, it is important for the example code to be independent or self resolving: with this I mean that one should not need to think of what happens outside the code fragment and how this influences the code itself.

It is also important to stress out how this is a “please port this to vl”: while I understand your code (you manage to execute something only when a predefined amount of time has passed, with the limit that the first time it would be executed with an initial delay equal to waitTime; also, lastFrameTime = thisFrameTime should be one level deeper, IMO) it does not answer to my question, also it is not in vl (not directly, at least).

The question should also open an interesting, general, conversation about time in vl (which I hope it will be an easy one, with some bit of depth here and there).

P.S. the backtick, or `, is made with Alt + NumPad 96. This should be keyboard layout independent.

@h99 please don’t maintain such generic topic threads that can never be closed and will not be very searchable and thus not very meaningful for other users. instead please start individual threads with proper topics for each question.

Believe it or not, I was thinking the very same thing when I opened the browser. Probably the best thing would be to make a documentation page with links to relative threads pages.

this is fixed in latest alphas, you can now enjoy replacing Damper, Oscillator, Filter and OneEuroFilter with each other…

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.