same.
2 Likes
On your test pattern, delete all of the pattern pieces & see if it’s still running at 100%, please
all the pattern pieces or blocks in drafting?
1 Like
The pattern pieces
I’m completely stumped. I run on Windows 10 and I’m not getting the same problem. This why I keep asking you to do things. Although, I see that the CPU is running at over 50% for Seamly on my side, but when I delete things, it goes down to about 8%.
Looking through the older posts, I see that there’s sometimes a similar problem when one selects a curve and then a point that’s not attached to the curve in a pattern piece.
I can’t find the one where someone actually found the problem on a Mac, that I seem to recall. Let me think about it a bit more & search a bit more. I don’t want you to delete all your hard work 
Just one last thing for tonight… can you delete the sleeve cap curve on that pattern that I sent you? After deleting the pattern pieces on that file, it came down to 38% on my laptop & when I deleted the curve, it dropped to 0%
I found the issue that I was recognizing here: Crash on MaC - #34 by H.Naehmann
Perhaps you can check it out & see if it won’t help you.
1 Like
all the pattern pieces are already deleted from that file. do you mean in the draft?
1 Like
toggling off the curve handles works.
2 Likes
I am running a new Mac with sanoma 14.4.1 my cpu is running at 99.4 with seamly open with a simple t shirt pattern.
1 Like
try toggling off curve points.
1 Like
That does make the cpu drop by 50%
1 Like
That’s what I suggested 3 days ago. When the handles are toggled on it causes a loop in the paint routine() for some yet undetermined reason. I think it’s because the control points are telling the parent curve to refresh, and then the curve telling the control points to refresh… endlessly. Mac’s seem more suseptable to the high CPU usage - to the point where the machine can just lock up. Since I’m not a Mac user I don’t know why, and without a Mac I can’t test any changes. 
1 Like
it was crashing before without the handles toggled on but it’s definitely better with it off.
1 Like
The file loads fine.
The error is produced in the SaveDocument() routine which tests that each tool id is unique… which apparently was not the case when you tried to save. So the file was not saved. Which makes sense as the error is reporting the id=“688”… which is not in the file you attached.
My question is did you attempt to save the pattern? If not it could have happened while trying to make the autosave backup.
1 Like
i ended up having to delete the pattern piece and save and then reopen.
1 Like