CraftLie Demystified?

[catweasel]

I thought I’d move this from the contributions thread to the forum, unfortunately I wont be at node :(

23/06/2017 - 16:17

hi cat,

that is basically why you (and every other vvvv pro) should attend this:
https://17.nodeforum.org/events/vl-for-vvvv-users/

and this:
https://17.nodeforum.org/events/vl-concepts-and-patterns-1/

anyway here is a tip on how to read the DynamicUI example:

it basically follows the super classic game development pattern for mainloops. as a vvvv developer you live in that world and you only need to understand one addition to the normal ‘update’ processing. the mainloop is split, or sliced, into several steps in the main patch:

1. check if there are any new input events
2. process all input events and update the state/logic of all elements accordingly
3. do normal “animation updates” like you are used to in vvvv
4. output layer to output pins and render it

start over

step 2. is the new one for a vvvv developer and itself split into two steps, HitTest to check whether an element actually needs to process the input and ProcessEvents then does the actual logic and leaves the results for the Update stored in pads. so basically the pads connect the different mainloop slices by moving data/results from ProcessEvents to Update to animate/draw it…

so go into the patches and read them like this, someone from the outside is calling HitTest, if that returns true ProcessEvents will be called where the patch processes the UI logic. finally Update will be called to render animations and other stuff that was decided on ProcessEvents.

Ah but that looks so simple, however, when you look at the patch, and for example open the update patch you get

Invoke, whats that then, not in the greybook, can’t open it, so it does some ‘magic’ that has no graphic explanation with inputs that are virtually linked to some other patches, but you have no idea where they maybe.

So lets open the ProcessMouseEvent, ah more invokes and splits, what are they doing all floating in space like that…

So lets open the create section, not mentioned in your sketch and we GetUIElementFactory, and we see some things that might relate to something, but then we need to dig down another level to see that somethings going on, but all these thing open in the same window, so how do I as a novice, relate from this patch and the 6 input and outputs to its parents or to the areas of the rest of the graph where these inputs come from and magically sent like S and R nodes, that always lead to patch illegibility.
The main thing I’m getting at, is readability of the patches is almost none existent, you don’t know from looking at it where data is flowing, where you can find functional parts as opposed to ‘magic’ parts. You can’t open multiple views, so you can’t see what one section has named its inputs and copy the names over, there is no overview where you can trace the logic. You can open a patch that has several patches defined within it, so many that you have to scroll around so you can see them all. All in all, it feels like the only connection with vvvv is the colour scheme is mostly grey all other logic and best practice has been thrown away, reading through the grey book, you can’t connect a spread to a sequence without a tosequence etc, things that I would have expected an automatic conversion to be put in, they’re both lists, but suddenly they’re not lists.
I guess I should start with simpler things to take apart, but the feeling is much the same, I know that its not vvvv anymore, but it feels like the good things about having a graphic program and good idiosyncratic things about vvvv, have been thrown away, yes its all clean looking, but is it too clean, it doesn’t feel as informative as it should be. It feels like using quartz composer, without all the more helpful parts.
The solution explorer helps somewhat, but Uses, is Used By, is what the links were doing in vvvv, maybe we need some graphics representations in the patch to show these connections, whether by short cut or default, with flow direction? Or right click on one and you can open the patch where the data comes from/goes to.
In unreal there is a debug feature that allows you to see data flow as things are triggered, vl it seems to be you have to hover a mouse over an outlet to see anything, debugging is not visual.
I guess I’d like to be at Eno’s future of vvvv talkshop, but I’d have quite a list…!

[joreg]

@catweasel

I guess I should start with simpler things to take apart

absolutely. it is a pitty that you can’t make it to node, because my “vl for vvvv users” workshop is exactly targeted at you. we’ll start looking at all the things that are the same (or very similar) first. you’ll see that you can work with vl almost like with vvvv. but soon you’ll not want to work like vvvv anymore because you’ll learn a few new metaphors and understand how to apply them for your own satisfaction. and only then it would really make sense to try reading the craftlie patches. you’d not start to read a foreign language book without first getting into the language a bit, right?

anyway, after node i’ll put my workshop to video which i hope will help you get into it.

[catweasel]

I’m trying to learn this foreign language, but unfortunately the book hasn’t been written yet, and there is no real knowing how long that will be…
Added to that, the few things I’ve done with VL have tended to work out slower in performance than vvvv, this makes me worry, although this maybe me thinking in vvvv terms rather than VL
And while you say ‘you’ll not want to work like vvvv anymore’ how do you know that, as the language is still being developed. Maybe I like to use vvvv because of the way it works, that I can sketch out an idea as I go and not have to make a flow chart and work out all my references and methods in advance of needing them.
My worry is the things I like will be lost and the new things may take several more years to finish, and also that the help patches and documentation will not be made until they are. I’ve been here before, I remember there being little documentation when I first started using vvvv (I’ve still got the pdf, ‘in future versions you will be able to export an exe’ ;) ) its the boring and time consuming bits like documentation and help patches that are the most important for end users, especially when your changing the entire paradigm that we are used to working with.

[joreg]

@catweasel

‘you’ll not want to work like vvvv anymore’

no, of course you still will. the idea is that you’ll also appreciate the new metaphors, which i can say from the feedback we got so far. and understand that for certain tasks you’ll prefer either one and they can be used together quite well.

@catweasel

the few things I’ve done with VL have tended to work out slower in performance than vvvv

perfect, why not share those here in the forum and let us see if we can help you improve them and explain a few things along the way?

agreed, there isn’t enough documentation still. we understand good documentation to be crucial for people to adopt the new way and therefore have this on high priority.

[tonfilm]

@catweasel

Ah but that looks so simple, however, when you look at the patch, and for example open the update patch you get

Invoke, whats that then, not in the greybook, can’t open it, so it does some ‘magic’ that has no graphic explanation with inputs that are virtually linked to some other patches, but you have no idea where they maybe.

hi cat, yea you basically clicked into what is probably the most advanced patching pattern in VL that exists to date…

it is an abstraction layer made of Delegates and their counter part Invoke that connects the general UIElement type with the actual ui elements like WindowManager, Window, Animation, … this abstraction makes it possible to put the WindowManager into itself as content of a Window. If you dare, check the factory patch to see how they get connected.

But as joreg said, probably start a bit more basic… after node more video tutorials should appear.