Forum

Weird save behaviour

vvvv beta general
#1

Was just about to continue working on a patch where I left off yesterday but couldn’t find MidiReadTest2.v4p that i was looking for but instead in the dir there is MidiReadTest2~temp1.v4p to MidiReadTest2~temp4.v4p that seems to contain roughly what I had when I did a Save As command and added the “2” to the file name. One other odd thing is that some of the ioboxes that were showing grids of toggle values had been reset to all ‘0’ standard input mode (but with the correct slice count).

Anyone experienced anything similar? Since the patch was for testing my own plugin I guess there’s some chance that I might have brought this on myself but I don’t think so…

Windows vista beta21

#2

read this long thread.

*always use a Renderer (TTY)
*always make sure that the asterisk behind patchtitle in titlebar vanishes after saving this patch.

if not: immediately backup the patchname~.xml file!
because it contains the second last version of your patch.

often those problems are related to some “evil” nodes (dynamic texture, enumerations,…). delete suspicious nodes and try saving again. if not successful, try undoing (CTRL-Z) and delete the next node. maybe Renderer (TTY) gives you some hints about the problems.

#3

I’ve had the no save problem in previous versions but the asterisk did disappear so I thought I was safe, I’ll try to follow your advice on Renderer (TTY)

hmm dynamic texture check…

#4

hi,
i’ve also this problem…
so i try to find the “evil” nodes… and it was the
AudioIn/FFT/AudioRecordSelector combo pasted from an old patch

#5

AudioIn/FFT/AudioRecordSelector combo pasted from an old patch

ah, yes, and let me guess: the patches were created on different hardware?

in any case of using DirectShow-related nodes (also VideoIn,Scope,FFT,etc…) it is recommended to take special care.

i learned very early not to disconnect an FFT from the AudioIn without disabling before. had sudden crashes then.

this seems to be not an issue of vvvv but of DirectShow.

#6

I also copied and pasted from an old patch, no DirectShow nodes though think it was mostly very basic ones and the dynamictexture.

#7

only for curiosity:
was it DynamicTexture (EX9.Texture Color) ?

i only remember one time “bad save behaviour” using this one.

i have some (not yet posted…) modules using DynamicTexture (EX9.Texture Value) without problems.

moreoften i did notice
really strange, but sadly not reproduceable phenomenons
while playing around with the newer nodes of the category Enumerations (create, null,…). but for the lack of reproduceability my rantings are not from interest for the devvvvs. my personal advice:
avoid using those in ‘serious’ patches.

anyone else here wearing the same glasses??

#8

no, it was DynamicTexture (EX9.Texture Value)

#9

kalle, i finally can support your finding. we have one serious patch and the patcher used heavy numbers of enums in his patch. its “crashing” almost every 20 minutes, tty tells something about TMMenuItemFrame : Zugriffsverletzung. he can’t save, there are no temp files generated. he can’t even delete nodes in one subpatch.

i just told my friend to get rid of all enums. it seems stable now…hopefully.

#10

if you have a patch that cannot be saved please pop it up here so we can check…

#11

i would have posted one already, if just this bug is easy to reproduce. we’ll keep on looking…

© vvvv group