MultiDim.AssignFrom

[woei]

as the title says, there seems to be an issue with AssignFrom and MultiDimSpread (just tested with multidim) which got introduced with b35
in case of the demo this doesn’t work anymore:

ISpread<ISpread> Input;
ISpread<ISpread> Output;

Output.AssignFrom(Input);
…do something with output
while doing the copying with two loops from in to out works fine
setSlice.v4p (4.8 KB)

[Elias]

And this is also still present in current alpha build?

[woei]

si.
just checked with 0804ac58c1, same behaviour

[Elias]

Well turns out the SetSlice plugin was broken from the beginning. The FOutput.AssignFrom(FSpread) call at the beginning assigned the input spreads to the output, but it did not make a deep copy of those spreads. Later writes to the output did therefor overwrite the input.
The issue didn’t surface before because in older versions of vvvv (before beta34) the transform pins always reported that they’re changed so the input of the SetSlice plugin had fresh data every new frame.

I commited a new version of the SetSlice plugin which is written a little differently. Issue should be fixed now.

[woei]

hö, interesting.

i was aware, that it’s not a deep copy. however i thought that the shallow copy is executed every frame, and that vvvv would copy the delphi input to the .net input, which later gets overwritten by the plugin.
is there a behaviour now, which prevents copying from vvvv to the plugin if the input hasn’t changed? i always assumed, that inputs are always flushed by upstream…