Need your smartest tricks for my Wiki

I did request ctl-8 to be save enabled, as I couldnt fullscreen a renderer with 2 threads and have another renderer active at the same time…
Devvvv’s?

had the same issue with the two renderers and solved it with (kinda) this one.
set focus with sendmessage (windows)
and send keystrokes ctrl+8 with keyboard(global)

and set the renderer to the wanted position with my SetRenderer module woei.modules

no_border.v4p (7.0 kB)

wow.

:( no helpfile for SendMessage (Windows)

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.