Forum

Vector size pin

#1

imho some nodes could need a vector size pin additional to the bin size pin to save a lot of performance using swapdim and count and swap back to do the necessary calculations:
*all spectral nodes (+, *,mean, rootmeansquare,…)
*CAR, CDR, differential, integral
*resample
(*b-spline)

e.g: a spread with 15 slices could be treated as 5 3dvectors. and you could easily calculate with binsize 2 and 3. making modules for this creates a huge nodecount.

furthermore a vector (join) and vector (split) with vectorsize would also make patching life more convenient. e.g passing position, scaling, and id of an object as 7D vector.

just a thought, just a wish

#2

now as you say that, yes we need it, smart idea!!!

#3

great idea! +1! all hail woei :-)

#4

+1… no text …

#5

I remember I asked for a Vector (nD) node, for the very same thing, and the answer I got was: Stallone is a vector (nD) node.
(but a stallone always requires some xtra nodes to do that) so:

+1

#6

+1 yessss… no text …

#7

nerds :)

+1

#8

hi woei, can you post a patch/mockup showing what you mean exactly? i’m not sure i can follow …

#9

here a little mockup, might not be the best example to demonstrate that it can get really complicated though

VectorSizeMockup.v4p (12.3 kB)

#10

i see… most nodes deal with spreads like 1-dimensional entities. as soon as you want to interpret spreads differently, difficulties arise. i wonder if the usability/understanding would suffer if the nodes in question had a vector size pin - it would definitely be useful in certain cases, but in most of those cases the concept of spreads leaves the intuitive grounds that make it so enticing in the first place… i’m sure the devs have been tinkering with this problem from the start :)

+1 for even more thoughts about it

© vvvv group