would it be too much to ask for vvvv to detect wether a possible connection would result in a spread feeding back into itself, e.g. adding slices from itself, concatenating itself to itself etc. - as seen in the ‘about feedback’-screenshots? i’ve been accidentally doing that for some time now while trying to build spreadable modules, and it results in ugly bluescreens-of-death telling of irq handles if you don’t kill the frozen vvvv-window immediately.
would be a very nice feature if vvvv would just not let me do that, just as it does with feeding back values into themselves in the same frame :)
Dear Diki,
I´m really sorry, but today I get the first view on VVVV…
With the best regards
Antonius
hi,
would it be too much to ask for vvvv to detect wether a possible connection would result in a spread feeding back into itself, e.g. adding slices from itself, concatenating itself to itself etc. - as seen in the ‘about feedback’-screenshots? i’ve been accidentally doing that for some time now while trying to build spreadable modules, and it results in ugly bluescreens-of-death telling of irq handles if you don’t kill the frozen vvvv-window immediately.
would be a very nice feature if vvvv would just not let me do that, just as it does with feeding back values into themselves in the same frame :)
i think it would be hard to implment this in a way that you still can do everything you want, but with the limitations you describe.
There so many ways to blow up a spread or to reduce it again that it seems to be implossible to not allow special nodes in framedlayed loops. And how should vvvv detect, that there is a clever patch, which will reduce the spread in another 20 frames. I think it would be hard to not allow such connections. However: you are right - there shouldn’t be bluescreen…
