I found big problems opening old and new patches with the beta 21.
In most of the patches with framedelay cycles inside there’s a problem on the opening of the patch: the number of slices of the spread of the cycle start to increase and then the application stops.
i don’t have your problems, because i’m already used to ‘force’ my spreadcounts since a while.
use XMLmarker or any texteditor to find the framedelays in your patch and break their links. then you should be able to start up your patch and add modifications similar to the above mentioned.
Hi Kalle!!! :)
yes, i was invisible for long…
tnx for the reply, i just found the solution:
-i used the get spread to force the spreadcount as you told me.
but this was not enought:
i had to reset all the framedelay cicles and also all the s+h nodes for more than the initial bang (on open). i used a framedelay to have a bang also in the second frame. everything seems to work then.
but i think this behaviour is not normal: seems like vvvv doesn’t initialize all the nodes and subpatches at the same time. Has never been like this in previous betas… has not to be considered a bug?
could you please make an example of this ‘forcing’, i have similar problems with older patches and i dont really get the problem, resetting everything in the patch in the first n frames wont help, tank you
I am also struggling with Framedelay and its initial values.
The fact is, I don’t really understand what the order is in which things are ‘initalized’, but since I made a loop, I can’t connect the ‘count’ to the getspread, because the count comes from the previous cycle.
Any other ideas? And what exactly are the rules when a patch is started? what is done in which order?
For example a ‘change’ node. Will it bang on creation?