Getslice spreaded bin

vvvv beta general
1

not really a bug, but maybe something to rethink the design:

if a getslice receives a spread of bin sizes and the index pins slices are not consecutive, the different bin sizes except for the last are ignored.

Bin Size: 2|3
Index: 1|2
→ returns 5 slices

Bin Size: 2|3
Index: 1|3
→ returns 6 slices

since the first query can be solved with a non spreaded GetSpread, a suggestion for the second case:

each index gets the slices form the sliceindex Index*BinSize
that would allow overlaping results like:
Bin Size: 3|2
Index: 1|2:
→ first returns index 3 to 5
→ second returns index 4 to 5

just a thought

2

lill example

3

lill example

feelsStrange.v4p (10.7 kB)

4

sry, my fault, just got my brain around it…
and kinda repost, i think i asked something similar already.

binsize 2|3 divides the incoming spread repeatedly into bins of 2 and 3
index 0: binsize 2
index 1: binsize 3
index 2: binsize 2
index 3: binsize 3
etc

thats why index 0|2 will result in a spread of 4 slices
and 1|3 in 6 slices…

5

but can anybody explain this to me???

6

but can anybody explain this to me???

SetSliceBinMadness.v4p (3.9 kB)

7

hi woei,

what would you expect to happen? i would say it works like it should.

the binsizes are for structuring the incoming spread (pin “Spread”!). so the incoming spread looks like:
(0, 1), (2, 3, 4), (5, 6), (7, 8, 9)
now you want to change the bins 0 and 2. so bin 0 will get (-1, -2) and bin 2 will get (-3, -4). since there is still a superflous value (-5) which needs to be set, bin 0 will get overwritten and (-1, -2) gets (-5, -1). setslice works on whole bins. that’s why -1 is taken.
now all slices are set and the result is
(-5, -1), (2, 3, 4), (-3, -4), (7, 8, 9)

you probably thought that the binsize would structure your input spread (“Input”). but then the question would be how the orginal spread is structured and where would bin 2 start in the original spread?

would you expect:
(-1, -2), (2, 3, 4, 5, 6), (-3, -4, -5)
or
(-1, -2), (2), (-3, -4, -5), (6, 7, 8), (9)

8

after some sleep i figured out what you described above. the confusing thing was the repeating of the superflous value. i expected it clamped.

on the other hand binsizing the input would also make sense, since that way you can predict how many values you are inserting by each index.
a way to handle the spread would then be to increment each index * its binsize from the beginning of the slice:

so binsize 2 and index 3
(0,1),(2,3),(-4,-5)

and binsize 3 and index 2 would be
(0,1,2),(-3,-4,-5)

of course there are cases where different indices with different bins would affect the same slices. but one would also have the freedom to get quite arbitrary slices without calculating the binsizes, which have to be inserted for the bins inbetween the selection. e.g:
binsize (2,5) index (1,1):
(0,1) , (-2,-3) , (4), (-5,-6,-7,-8,-9)

9

hey woei

i think the problem would then be:

you can’t change the second bin of spread (1), (2, 3), (4). at least not with support through the binsize feature.

with binsize 2 and index 0 you would change (1), (2.
with binsize 2 and index 1 you would change 3), (4).

we arbitrarily wanted to cover those cases.
however your suggestion also would make perfect sense. it is just another way of thinking of the same thing…