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