Need your smartest tricks for my Wiki

oops, forgot the OnOpen node…

anyway.
here’s a file with some SendMessage codes. no guarantee if they’re correct or not.
the hex values have to be converted into decimal.

no_border_right.v4p (7.3 kB)

codes here:

sendmsgcodes.txt (7.0 kB)

hey thx woei!

i couldn’t withstand to make a module of it.

to honor you i cited your unique “dense patching style”…

i think this one has to go on woei.modules

KillBorder (VVVV).zip (2.5 kB)

hello again.

tnx for critics west, i am on a learning curve and it takes some time to figure out things…

it helped me to optimize my patches, so tnx again.


since i am working with vertex buffers a lot - thus producing large spreads, i figured out that some nodes on non changing data lines are consuming a lot of CPU.

for example, i usualy decompose vertex data with GetSlice, Resample and Select nodes and compose it back with SetSlice, ApplyTransform and all Transform nodes. Even if the data spreads are not changing, these nodes tend to consume huge CPU juice.

the solution i started to use is conecting S+H (Sample and Hold) nodes right after all those hungry nodes while trying to find logic for set pin somewhere far before in my patches. In some setups the difference is up to 200 times less CPU usage.

br

o_0

did i say 200 times? well it can be much more…

see the example: s&h_optimize.v4p (15.18 Kb)

actually you could save even more performance by temporary deleting a connection + the s&h node. in this case between mesh and vertexbuffer.

i’m just trying to figure out a way to do this :)

woei: i remember that @eno once made a patch with setpatch+getpatch called sth like “real switch” where he connected ioboxes via scripting.
but i can’t find it…

example here

edit: @kalle. jop, i know. but as far as i remember he “just” replaced the srcnodeid. for the switch it was not necessary to delete a link.

s&h_optimize_v2.v4p (26.5 kB)

yes woei!! i had on mind that ‘hard wire’ solution from the first moment i touched vvvv.

your patch is so simillar to what i was building… darn!

OK nevermind. this is what the wiki is for, right?

the soulution i am pursuing, and it could be implemented in all subpatches, is: to include woei’s way ON/OFF pin that connects and disconnects output nodes inside the patch. it doesn’t have to seek for hidden links, but to have it ‘hard wired’ inside a subpatch.

think how many CPU ticks we could save…

i figured out that some nodes on non changing data lines are consuming a lot of CPU.

thats right, all nodes are evaluated in every frame. there is not much efford in the code to check if the data from the last frame is the same, just some special cases are checked. but since vvvv is a realtime and live performance software at first, its a design decision to ensure that all processing power is used to calculate the functions instead of doing administrative performance optimizations. so one can say, vvvv even tries to run always in the worst case situation to give you an accurate performance estimate of your project.

the best way to save performance is a disconnect, because the graph gets calculated from the leaves to the roots. if the data of a leave is not used, no calculation starts there.

this gives me the idea to make a node that just stops the calculation… dont know if thats possible… gregsn?

… and why do some ideas come up in the same time on different places?

was thinking about doing such a subpatch some time ago, but it doesn’t seem so simple… in some cases the values stay stored inside the disconnected pin.
in this case a complete structure would have to be temporarly deleted - which on recovering cost quite a “long frame”.

and note that the patched thingy requires one more frame than the mere s+h solution. so it’s not usable in all cases…

… and why do some ideas come up in the same time on different places?

because this is the way it is. vvvv, like all other living entities in evolution, is pushing his own way through.


the important problem i am experiencing is about subpatches. just because subpatches need to have output IO boxes, nodes inside sometimes consume much more attention from CPU. this is not such a serious case with IO box (node) output types, but with IO box (Value Advanced) type it is.

@woei: i would always go for ‘hard wire’ soulution. even when nodes store the values - the CPU load difference is significant.

let’s find this solution.

see you all monday.

br

o_0

well, you can try this out with GetSlice (3D Vector) subpatch. If you copy-paste the subpatch nodes (like i did in the example above) nodes consume much less CPU (with large spreads) then the whole subpatch itself. and this is just because of output IO box. try it.

hehe,
was just trying the ‘hard-wire’ solution inside a subpatch. works. but due to the necessary it consumes more performance (not much but still). and sometimes the subpatch generates peaks on reconnecting…
so, not sure, which one is the better solution…

and the thing with ioboxes for subpatches… avoiding subpatches tend to create quite a jungle on big patches :D

Interuptor.v4p (11.9 kB)

yes, hmmm…

we need HardWire (VVVV) node in code. any input type to output. and one fire-brigade axe. just in case. ;)

i was really about to go to bed. gotta travel tomorrow.
any cure for vvvv addiction out there? west would have to put it as No1 on tricks list.

… and why do some ideas come up in the same time on different places?

i am pretty sure that this was already discussed years ago.

The only problems with set patch is that it tends to use quite a few ticks when not actually setting the patch (a button like the only render onsave with the dx writer?) So if there are a few within the patch, i’ve currently got about 4 in one of my patches. Maybe I could get organised and use one and more thought! Also I’ve kiiled a few patches while experimenting with set patch, use with care!
The other main problem is the tick when you switch, which was always a problem in the presets patch (kalle did?) a while back, even though the changes were quite minor, I presume this is from disk reads? Which makes me wonder if you create a patch dynamically which doesnt actually exist on disk whether this would be faster?
Setpatch is definatley one of the most confusing and powerful nodes out there!
@MajorTom, there is no cure, we’ll have to set up vvvv addicts self help group I think!

ok. an elegant way to bypass rarely changing parts of patches or subpatches:

switch inputs to ‘no data’ if there is no change and use S+H to hold last ‘real’ state of calculation:

same calculation on left and right.

left one is optimized.

if there is a change on input S+H will keep new result, but in very next frame the whole calculation will idle - because of ‘nothing to output’ from I node.

quickest way of coping a value from one pin to another:
don’t know if its a bug of a feature but there ist a very fast way of copying values from one pin to another:

a. input a value to a pin
b. double right click to the same pin
c. right click to another pin (must be the same type)
= you copied the value

sadly that feature doesn’t work with more than one pin, it’s not possible to distribute the value to several inputs.