Would you please port this to VL?

vvvv beta question
6

@joreg thank you for tagging the thread. Still doing it the old way: if it’s in title, no need to tag it with it.

@guest Soooo… Do you know that I now understand why a patch it’s not so much of use? Because actually, unlike with vvvv, you can’t get any sort of hint and tips right\double\smash clicking nodes. But you need to understand this, feel it under your skin, while blank-staring at the full moon because your beer doesn’t taste as it any longer and reevaluating life choices, by doing it yourself for the very first time.
Anyway, leaving some stuff to fix as the starting index for the step spread, gives newbies chances to understand better, as one might think, where should I put a +. OMG. You can add pins by [CTRL,+]. OMG.
(As I saw that 4, I thought, “Here we go. Now we also get arrays starting at 1… Very good choice devvvvs, very good choice…” I was already in panic!)

VL, patching wise, does not work like regular vvvv, which is far more “relaxed”. In vvvv you can “take care of stuff later”, not in VL. This is good, because you must know what you want to do in advance, you’re not going to patch your way out of the issue along the road. Like a real adult.
Let me have a lollipop, before I can go on.
I wrote, iirc, gregsn to keep VL playful; his answer was a very elegant version of “that’s not going to happen” (I discovered today).
I already need another one, sigh.

Anyway, in the patch you gave us, there a couple more thingies I wasn’t able to fully understand (because the rest, instead…). That stringSpread: Spread <String> which is kind of a recursive stuff, since top and bottom holds the same value. @all, what’s that?

EDIT:
That step spread way that you found needs more operations. See picture (in which I think I replicated the logic in your patch: just try to change start position). Starts from 2 and keeps adding 7. Am I missing something?

7

no good, because then we cannot filter for it. if you tag it, we get this nice list: Topics tagged vl

8

@joreg
Yup, just updated my routines.

Also could you please explain why I need those stringSpread n and out the if to actually make the vl bit to work? The if surrounds the picture above from guest.

9

If its not playful, not easier, and requires you to learn all the concepts of code design, should we just learn to code rather than learn a specific unfinished, undocumented tool? Maybe thats a little harsh, but you are asking us to invest a lot of time in learning an unproven tool created to fix some issues in the original design of vvvv. So far, the idea of importing dll’s easily does sound good, but so far, I would have preferred a way to separate sub patches to run unsynced in a separate thread without having to run multiple vvvv instances. Or integrated media playback on multiple outputs out of the box, you know given thats it a multimedia tool kit…
Dev’s you really need to start on the help patches with description of why things do what in the patches, explain and reexplain everytime what the various code-y concepts that you use are (because patchers aren’t necessarily coders, and there is some leet language involved)

10

PortMe2.zip (6.8 KB)
attached is a slightly simplified version of the splitting. please compare…

regarding the StringSpread: it acts as a kind of S+H. read:

  • If any of the inputs is changed, the IF region is executed. its output is stored in the StringSpread pad (the lower one).
  • If the IF region is not executed, the last spread that was stored in StringSpread will be returned unchanged. ie the upper StringSpread pad is read, bypassing the IF region, and again stored in the lower pad.
11

@catweasel
It seems I raised quite the carpet.
What follows can’t be but my 0.000000002 cents.
What I read (because of my ineptitude, for starters) that VL is capable of, is something that was absolutely needed in vvvv. I remember this thread in which a very specific operation couldn’ t be achieved if not via c#; no way to do that with existing nodes. With vl that could be instead done, inside a graphical environment.

That said, a whole new coding language (because this is what vl is), it’s quite the target.
If you read above, an IF statement, needs a sort of S+H in order to output something. No pads, no party (quite the opposite of what would commonly happen in real life); no output, no anything.
Now either that’s a sort of a default value, or anything deeply bound to bones of vl, users honestly shouldn’t manually create these elements, not like this. It makes little to no sense. This goes in the opposite direction of what vvvv has always done (facing you with your poor coding choices immediately), adds two mandatory operations, it visually adds up to the actual outlet.
Now, I’m not asking for a way so that the IF understands if it’s managing an int or a string, and manages to create automatically these elements (this seems to me the “problem”), but it wouldn’t be bad that they would at least have a different symbol they refer to. In other words, the top pad sits alone (literally two linked points), the bottom one shares a diamond with outlet and proceeds toward its twin pad. Why?
It’s actually quite difficult to understand such a design (for me). They are both required, they must be manually created, they must have the same name, they seem to be part of a single operation, yet they sit in two different contexts, they don’t explain the user what really is going on, doing a thing that’s not that immediate to get, if you want to further process data you can use IF outlet, …
Is there any example from any other language in which is required to pass, twice, (what at all effects are) its own results to an IF, in order to have it to return data?
Isn’t this a bit overconstructed? It’s like low level and high level stuff coexist on the same plane, it’s a bit weird.

Just trying to give positive critics.

A fully operating vl it’s an immensely powerful tool. So keep on: I’ll post another snippet in the future to see it ported to vl.

12

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:

13

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

14

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.

15

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.

16

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?

17

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.

18

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 :)

19

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

20

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.

21

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
22

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!

23

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!

24

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
25

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.