to overcome this issue, you have to order your slices correctly. all spread counts must be the same. insert new slices only to the end or insert them everywhere in the same frame to the same index and if you delete slices delete them everywhere in the same frame.
but do you remember the node13 keynode? hope is on the horizon…
I had investigated this (briefly) when dealing with the emission of particles so I am aware that everything must match everything (The patch above is somewhat an exaggeration). In the current case, the insertion of spreads is not exactly arbitrary - I have their order as an important function within the patch, it’s just that somewhere else they’re not written and given along in that order which, uhm, is also an important function ;?
And how to fix this while not breaking everything ( this,](https://vvvv.org/node/109311">this,) mainly) is slowly making my head explode… So I thought, as this can’t be an outlandish thing someone might want to have, vvvv could have ways unknown to me to help me bring order into it…
What exactly is “hope”? :) I had a look around but with no success - is there a documentation of you guys’ presentation?
Your example patch, some things that cause your quads to jump, you make the spread count of the linearspread grow, so that will introduce jumpy stuff, but than you use that new spread to generate another spread so every second, every slice gets a totally new value. So don’t touch your source spread.
Also, you keep on changing the order of the spread, but don’t do the same for the randomspreads, so it jumps there too.
If you have a limited amount of quads (lets say 1000) better just use a setslice or get slice, and turn the rest off. My old flower lead patch does that: westfunpatching#leaf trail generator
Of you can use a framedelay and grow your spread, one new value at a time. I attached something like that for you.