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…
*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.
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)
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.
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.
