contents of gen~ patchers disappearing!
hi all,
I'm re-working a large patch (Robert Henke's Granulator II) which contains many gen~ patchers--all "untitled" and thus saved with the main patch. Sometimes (too often now) after editing the contents of one gen~ patcher and saving, I find that the contents of other gen~ patchers have disappeared! I get about a dozen error messages, all saying "patchcord outlet out of range: deleting patchcord".
This is very frustrating, and it's happened many times. Any advice would be greatly appreciated. Thanks!
I can only support you by saying I've had this problem, too.
We saw this happening with named gen patchers and 7.0.2 included a fix for that, but we haven't been able to reproduce it for unnamed gen patchers. If you can find a patcher and a series of steps that always lead to this, it would be super helpful for us to debug it.
This happens often for me when I edit and save a gen~ patch that is inside an abstraction, inside a "main" patch.
I have an unnamed gen patch inside a patch (called pat-A).
This patch is used as an abstraction in a "main" patch.
When I work on the main patch and open the abstraction pat-A to edit it (Cmd-Alt-M), and edit the gen~ patch, after saving and reloading the main patch, I get a lot of "patchcord outlet out of range: deleting patchcord" errors, and the contents of the gen~ are gone.
When I open directly pat-A, not from inside the main patch, and edit gen~, I haven't experienced any gen patch lose.
I now, always keep a text backup for my gen patches, just before I save.
Unfortunately there is no series of steps that lead to this every time.
Hope this helps...
Nikolas
This is happening to me too and has been for the last few months. If I make a poly~ containing a unique gen~ object, trying to access the gen~ patch from the 'top' level down, as it were, generates the following errors:
can't load patcher: error -1 opening untitled
error loading untitled
egetfn (pclose): corrupt object
If I open just the sub-patch that my poly~ is referring to, however, the expected gen~ contents are there to see.
Max 6.1.9, Win7
Brendan
Thanks for responses. It happened again this morning, after I edited one gen~ patch, the contents of another big gen~ patch just disappeared. I forgot to mention that this is happening inside of a poly~.
Perhaps I should now name my gen~ patchers, with the new 7.02 fix? Nicolas, it sounds like the fix addressed named patchers, so maybe you are do not have to go through the procedure you outlined anymore.
I'll let y'all know if I figure anything out.
I also tried naming and saving the gen~ patcher (in a location known to Max) - the problem persists, however, despite this.
The gen~ patcher refuses to take the name; it saves okay, but stays named "untitled", and won't load if I try to access it from "above" - i.e. the main patch. It opens okay if I open the subpatch only, then the gen~ patcher.
Annoying
. . . unable to upgrade currently, so this is not an option. Should I downgrade perhaps ;)
The contents of my gen~ patchers disappeared again.
I was editing an untitled gen patcher (inside of a poly~), then I closed it. I located another untitled gen patcher (a healthy fellow, with 6 outlets and lots of patchcords coming out of it), and opened it, but upon opening it the contents were not there, and now instead of 6 patchcords coming out of it, there is just one.
I then checked on my other gen patchers in the poly~, and they all had all their outlets and patchcords coming out of them, but as soon as I clicked on them, the insides revealed they were empty, and the patchcords were deleted.
As you can imagine, this is frustrating/disturbing, like checking in on your precious sleeping child, only to find that under the covers are just pillows in the shape of a child, and then having even the pillows disappear before your eyes.
I can imagine, however I've not yet been able to reproduce the issue, making it infuriatingly difficult to debug!
Brendan, thank you for posting an example and the steps to follow; but when I do it nothing unexpected happens. (BTW, why can't you upgrade currently?)
I've also tried:
- create a new patch, save as 'pol', add gen~, edit to change [+] to [absdiff], save & close
- create a new patch, add [poly~ pol], dblclick to open, MRO, view inside gen~, everything is as expected
- edit gen~, save, close, reopen main patch, dblclick poly~, dblclick gen~, everything is as expected.
I've tried several variations of this, still no issues.
At least one indicator here is that all examples include a gen~ inside a poly~; this is helpful for us to narrow the circumstances.
Thank you for your attempts to debug Graham. I am watching what I do to my patch very carefully so if it happens again I can give more detailed steps for what is happening.
Hi Graham
bizarreness! I followed your method - which I don't think differs from mine - and the problem's gone. I'll try it with some older gen-based files and see if it recurs.
ps - can't upgrade right now as I'm in the middle of a big work project involving too many variables, so I'm sticking with 6.1.9 as it is otherwise very stable and familiar. Maybe later ;)
Brendan
How many of us with this issue are on Windows 7? Just a shot in the dark, but I think this only started happening (to me) after moving older gen-based patcher files around my system, zipping and unzipping etc. It appears not to happen with newly created patches. Clutching at straws here . . .
Hi Brendan; no problems with that patch here.
Thanks Graham
*update*
I opened the corrupt gen patcher, and copy/pasted from the "standalone" version of that sub patch, and while Max and that patch was open it allowed me to view the contents. It was only upon closing the patch that the debug window said:
egetfn(pclose): corrupt object.
I'll try to rebuild it, and save anew, see if that solves it.
Hi Brendan,
Thanks very much for working through this. But I still can't reproduce it, so could you explain the steps in more detail? It's still ambiguous. Start from "I start max" and describe every step. Please mention when/if audio is turned on or off, and please also open the About Max and copy the support info to send to me. Thanks!
For example, in trying to replicate your steps (and with some guesswork):
- I start max (about Max says 7.0.2, 32-bit mac)
- Open granary-sub.maxpat
- Double click to open gen~
- Unlock, select all, copy
- Create new max patcher
- Add a [gen~], cmd-double-click to open
- Unlock, select all, delete, paste in gen~ from clipboard
- Close granary-sub.maxpat (I don't see any error in the max console)
- Close the new patcher (save it to disk -- no errors either)
Is this right? Did I miss anything?
Hi Graham
thanks for taking the time to continue with this issue; I have some pre- 6.1.9 patches which use gen~.
1. I open Max (6.1.9 32-bit)
2. navigate to and open the main patch
3. open the poly~ part of that main patch
4. open the gen patcher within the poly~, and the contents will disappear
5. closing the patches, I get the above error messages.
However, if I:
1. navigate in Max to the folder containing the relevant patches
2. open the "sub" patch (addressed by poly~ in the main patch)
3. open the gen patcher therein; viola, contents uncorrupted.
4. closing these patches generates no errors.
A second however: your simple example from March 15 above also works fine.
When I get a moment I'll try to rebuild one of my patches and save anew, see if it persists. It's not a crushingly urgent issue Graham and I appreciate your input - the thing that is bothering me however is that in patches old OR new, I cannot save gen patchers, in the gendsp format. If I create a new patch, a new gen~ patcher, open it and edit it, then try to "save as" it appears to do so, but the gen patcher is still called Untitled (on the patcher title bar), even though it's there on my hard-drive with the name I give it, but it then refuses to open when I browse to it. That's worrying.
Brendan
I think a full Max reinstall might be in order - several months ago I did a full manual reformat of my hard drive, with associated software reinstalls, and ever since then things have been a bit, well, mehh. Do the technical team at C74 have any idea what "egetfn (pclose): corrupt object" suggests?
Brendan
Thanks Brendan for the detailed description. If I follow the selfsame steps, I get to step 4 and the patcher contents have not disappeared. Unfortunately it sounds like this is an issue in 6.1.9 that has been resolved in 7.0.2. We did have several patcher-disappearing bugs and addressed all that we could reproduce; the behaviour you are seeing in 6.1.9 is evidently one of them. More unfortunately, it is unlikely that we can back port this work to Max 6; a lot of work went into rewriting how genpatchers are handled, with nontrivial dependencies.
Regarding the second case you mention, it is expected behaviour. Saving a genpatcher as a .gendsp file does not automatically associate the gen~ with that file. You will also need to rename the gen~ to match. E.g., saving as foo.gendsp, you should rename your gen~ as [gen~ foo]. This is consistent with how poly~, pfft~ and abstractions work.
(BTW, the "egetfn (pclose)" is consistent with a gen patcher having disappeared prematurely -- it means gen~ was trying to close a window that no longer exists.)
Hi Graham
that's my "DOH" moment right there, regarding naming gen~ patchers, oops.
As for the remainder, it's a minor bug I can live with for the moment. Moving from Max 4 to 5, and from 5 to 6 for me was always instantaneous. I'm just going to bide my time with 6 to 7. Not ready to take the big leap yet,
Many thanks
Brendan
Saving and using named gendsp files prevents the disappearing issue.
:)
lol this is what i get trying to be organized.
just a note, maybe help to someone else, if you name a top level gen object, but don't explicitly save while inside that gen object as the name of the name of the gen object :) , when you close the top level patch after saving and reopening, gen patch = default input summing.
no way to get the contents back? :(
i have (had...) tons of different unique, unnamed gen objects - where does that get stored then, if not in the patch? maybe i have temp somewhere?
just going to use @t from now on...i can't really think of a good reason other than inside gen, where you have to use @gen to call named external gendsp. tbh, I'd rather not even do that...i'll have to look up If there is a way to call by title or something so i can keep the non unique abstractions/functions inside the gen object that's using them? keeping track of external dependencies is a drag.
dunno it's my own fault, but with pfft and poly you can't assign an unused name + open, nor edit, close the window without being asked to save. it had seemed more like p objects or sub gens, until I closed and reopened the patch they were in. :)
gotta try to remake those algos...
Hi all,
This bug (#8861) has been fixed internally and will be part of the next release update. (It just missed being in 7.0.3 by a couple of days).
In the meantime, all I can say is be careful to save your patcher if you gave the gen~ a name -- the "can't find subpatcher foo" error in the Max window might be a reminder. Sorry about that -- I know it is annoying (happens to me too).
BTW about "i’ll have to look up If there is a way to call by title or something" -- unfortunately there's currently no way to re-use content in gen without having external files (except perhaps conceptually similar is the re-use of functions within a codebox). A while ago I logged a feature request for a way to create multiple instances of an embedded subpatcher without duplicating patcher content, which I hope we can get into a future version of Gen.
Graham
Hi Graham, I've been experiencing this disappearance problem as well, though I have not been naming my gen~ patches. Saving them as separate gendsp files solves, but I would like to figure out what's going on. I don't have much more to offer at this point other than it seems to occur in abstractions, particularly after a crash as far as I can tell. Will post more if I can trace it better.
This is a mysterious, persistent, and unfriendly issue for me. Running 7.05. For the last few days, I have been opening a poly~ object and making edits to an unnamed gen~ patcher probably about 30 times a day. Now just the last time I did it, another completely untouched gen~ patcher in the same poly~ object disappears. The gen patch was massive, and now I must re-build it. How can I avoid this? Should I name my gen~ patchers and periodically back them up?
The Max window says my poly was unable to add just before I lost all my gen~ patchers, however it loads just fine, and all my other unnamed gen patchers are shipshape. Any ideas?
and now another untouched gen~ patcher (this one also very intricate, but without a backup...) is erased as soon as I rebuilt the last one....
I spent about 4 hours this evening building this last gen~ patch, and was had just finished doing extensive annotations on it, and now it's gone and unrecoverable. After spending about 45 minutes beginning to rebuild it, Max just spontaneously crashed--but thankfully this was just a good old fashioned M4L crash, nothing out of the ordinary (though I lost my rebuild efforts). Kids: take up woodwork.
This continues to happen to me every 4-5 hours on average, inexplicably. I now have to back up my work every 30 minutes or so, and have a worried feeling every time I save my patch (which is often), because every few hours I'll get the dreaded red "gen: patchcord out of range" message, and find the contents of my gen~ patch gone. It's just happened to me for the second time today. I am constantly on the lookout for things I do "differently" that may cause this, but it seems to be totally random and inexplicable. It makes working with Max feel like working with timebomb.
--My unnamed gen~ patches are inside a named/saved poly~ patcher. Based on what others have said, I think this is a key piece of evidence.
--I have two unnamed gen~ patches in this patcher, and sometimes one gets erased, sometimes the other. Usually not both.
Sorry to hear about your woes Jaren. Anecdotally, I thought this was fixed in Max 7; I am on Max 6.1.10 however, and the same issue still occurs. My solution is to save the gen patcher as a gendsp file and name it. I can open, edit and save the file without worry, but I still get "corrupt object" or something upon closing in the debug window, which I just ignore. Obviously I can't comment on Max 7, but this issue seems to be persistent.
HTH
Since i build a lot of stuff with gen~ and poly~ i also loose my gen~ files on random occasion, no matter if they are named or not.
To me it 'feels' like that poly~ doesn't re-assign the gen~ patchers correctly when recompiling it's dsp chain but that is just a poke in the very dark.
Most of the time i can retrieve my gen~ files from the project management folders but of not always…
-
I haven't found a reliable scenario to reproduce this annoyance yet.
Best,
c
I'm sorry to hear that this affects more folks than just me, though if pros like you are also experiencing this still then it means it's a legit bug and should be fixed in an update soon, which gives me hope! I'll keep trudging along, thanks for your kind resonance!
As soon as this can be reliable reproduced, a fix would be realistic.
Is there a backup folder I'm not aware of? I just had the above happen, chose the "recovery" option, and all my gen objects vanished. *Didn't* save, exited, and then re-opened. Every gen~ object I put together is gone. Couple days of metering, testing, and writing is shredded - I'm hoping I'm missing something. I saved plenty often earlier today and yesterday.
Thoughts?
Thanks,
-M
Any headway on this?
Is it possible to turn off the delete patchcord function?, so they are muted instead, or temporarily supplied with an acceptable signal?
For some reason I think it might have to do with graphics card gui interrupts, because I once had my card reboot on me when it happened.
The patch was using gen and msp, no jitter/gen jitter, and I was saving a small patcher that had some basic line~ and mtof stuff which was connected to a gen, both inside a bpatcher.
If I save a patch, wait a bit for gui to blink, click/window focus to it's parent, save its parent, repeat, all the way back to the main parent while leaving all the windows left open, it doesn't seem to ever happen, but that can become a bit tedious. Perhaps I sometimes get too excited and close windows before they are done saving. Or maybe saving a named patcher with duplicates within the same parent is involved?
I dunno, nans? Those damned nans i tells ya... Ghosts?
Dear maxers,
i just wanna announce, that i had also a problem with an empty gen patch last week.
The unnamed gen patch is located inside an abstraction. I think, it happened irregular after changing and saving the abstraction.
So, it seems the bug (#8861) is not fixed.
max 7.2.4
mac yosemite
I forgot to say, i opened max in 32-bit.
this happened to me too today.
gen patcher inside a poly~ v7.3.0 on windows 10 :(
This happened to me several times with 7.3.5 and 64-bit.
It's happened both with and without naming the gen~ objects while being used inside a bpatcher.
This is also happening to me, Max 6.1.
This is happening to me in max 8 on a Mac running High Sierra...multiple unnamed gen~ objects being used inside a poly~
This just happened to me in Max 7.3.3, 32-bit, on 10.14.1 .
The patch had two unnamed gen~ objects, and the contents of both were lost. I think that multiple copies of the patch were open simultaneously at one point, which is the only unusual circumstance as far as I can see.
Happening to me.. Windows 10 / Max 8.0.3 64-bit... Not sure what causes it but it seems to happen when deleting patch cords either inside or outside gen~. My mc.gen~ (unnamed) is in the top level of the patcher, and the gen~ window will suddenly close and when I re-open it's empty. I've also gotten error messages in the console saying that gen~ doesn't understand the message I'm sending to it for the parameter... When gen~ cuts out, I only get audio in one channel instead of both
Happening to me as well Mac OS 10.14.4/Max 8.0.4 64 bit. It's an mc.gen~ patch (unnamed) sitting on the top-level o the patcher. When i open the mc. gen~ it simply disappears
Still happening to me on Max 8.0.5 Mac OS 10.14.5...
happens to me since 8.0.8.... might be just be a coincidence thou... as it is happening on a new patch
Happened again to me, losing 150 lines of genexpr in codebox. Still on 7.3.3, although it sounds like this is occurring on 8, and the radio silence from C74 isn't encouraging.
when i‘ve had these problems it has been related to the sequencing of saving when i’m Working on a gen patch inside of a poly object.
I was Able to pinpoint an exact sequence of actions that led to the gen patcher being wiped, but I can’t quite remember It at the moment. I will post if it comes to me. I was able to , by avoiding this particular sequencing, mitigate the problem.
Encountered this again. Seems to have occurred after copying and pasting an unnamed gen~ patcher into a patch that included another unnamed gen~ patcher.
The issue persists. I attach a simple problematic patch
I save and explicitly name all gen objects and that never fails.
I had this problem many times, as well as unexplained crashes. The only reproducible crash I was able to find was when renaming a [gen] patcher to [gen~] or the other way around. I always use named [gen~] or [gen] patchers now, which avoids the issue of the internals of an unnamed gen~ patch disappearing, but doesn't prevent the crashes.
Incidentally, I'm getting a LOT of crashes when working with abstractions or bpatchers inside other patches, whether in the gen~ world or not; it seems related to the problem in this thread in that editing patches hosted inside other patches seems to make Max less reliable than normal. Has anyone else found this?
I was able to reproduce this by following these steps:
1) Have one saved patch with an unnamed gen~
2) Open a second instance of this patch (sometimes this needs to be done twice)
3) Copy and paste the gen~ object
4) Save this second instance of the Max patch
5) Go back to the first instance
6) Click on the gen~ object
I've passed this along to C74's support, and they've been able to reproduce it as well, so a bug report has been filed.
I'm also seeing this very frequently when I'm pasting my sub patches around. Was this ever root caused?
I started encountering this problem with mc.gen~ recently. It happened first when I tried to edit a large-ish unnamed 4 channel mc.gen~ patch, but it wasn't in a subpatcher or anything, and no copy/pasting. After it happened I closed everything out, loaded my previous save to make sure everything was ok and then left it alone. Then it started happening regularly with a new, very simple mc.gen~ patch. I was just playing around, testing the cpu load of different operators and eventually everything would just disappear when I tried opening the gen window to swap out operators. I tried giving it a title, but it kept happening.
I've been able to replicate the problem with the attached patch, but I've only been able to get it to happen if I patch it from scratch. It doesn't happen if I load it from a save or copy/paste the patch, or at least it hasn't happened yet. I started building my cpu-tester patch operator by operator until the problem popped up (I was testing different ways to get integers from the noise operator). I only got up to three operators before the patch disappears when I try to open it. It doesn't happen with a normal, single channel gen~ patch, or with lower numbers of channels. I get the following messages (9 times) in the console -
"gen_domain: dsp.gen: [string "gen2.PatcherToExpr.max"]:45: attempt to index local 'patcher' (a userdata value)
gen~: failed to compile patcher"
The patch -
edit- oh I'm on macOS Monterey 12.6.8 and Max version 8.5.6.