To Pd dev -
Are there any more crasher bugs to fix? I think I want to leave cosmetic issues like ghost i/o-lets on GOPs for later to avoid causing any more serious problems.
cheers Miller
Are there any more crasher bugs to fix?
these are the ones tagged in the repository
https://github.com/pure-data/pure-data/issues?q=is%3Aissue%20state%3Aopen%20...
cheers
Aaaand... the current master is totally unusable... don't bother trying it til I can debug it.
On 10/30/25 12:39 PM, Alexandre Torres Porres wrote:
Are there any more crasher bugs to fix?
these are the ones tagged in the repository
https://github.com/pure-data/pure-data/issues?q=is%3Aissue%20state%3Aopen%20... https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues?q=is*3Aissue*20state*3Aopen*20label*3Aseverity*3Acrash__;JSUlJSUl!!Mih3wA!Gf1H-yZHp98hFSLreK0PdW3Fm3r2CZ8izSsHCEelcq0SLNmBjb1ZFd8a5s7iyqY4a78IC3mGNg$
cheers
Cool... as far as I can tell, the two audio settings crashes are fixed and the others aren't new with 0.56. That graph~ undo bug is potentially serious (undos causing loadbangs that edito patches while the undo is underway) - but I don't think there's any way to clean up all those situations.
cheers Miller
On 10/30/25 12:39 PM, Alexandre Torres Porres wrote:
Are there any more crasher bugs to fix?
these are the ones tagged in the repository
https://github.com/pure-data/pure-data/issues?q=is%3Aissue%20state%3Aopen%20... https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues?q=is*3Aissue*20state*3Aopen*20label*3Aseverity*3Acrash__;JSUlJSUl!!Mih3wA!Gf1H-yZHp98hFSLreK0PdW3Fm3r2CZ8izSsHCEelcq0SLNmBjb1ZFd8a5s7iyqY4a78IC3mGNg$
cheers
Hey
It's not only ghost inlets/outlets. Some patches using GOP features ('coords' ?) can look pretty messed up in current master (b8763947). This wasn't the case in 0.56-0. Looks like a regression.
Roman
On Thu, 2025-10-30 at 12:27 +0100, Miller Puckette via Pd-dev wrote:
To Pd dev -
Are there any more crasher bugs to fix? I think I want to leave cosmetic issues like ghost i/o-lets on GOPs for later to avoid causing any more serious problems.
cheers Miller
--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/JNDWHMHRFPT...
Hmm... yeah, now I see the github issue...
cheers Miller
On 10/30/25 2:45 PM, Roman Haefeli wrote:
Hey
It's not only ghost inlets/outlets. Some patches using GOP features ('coords' ?) can look pretty messed up in current master (b8763947). This wasn't the case in 0.56-0. Looks like a regression.
Roman
On Thu, 2025-10-30 at 12:27 +0100, Miller Puckette via Pd-dev wrote:
To Pd dev -
Are there any more crasher bugs to fix? I think I want to leave cosmetic issues like ghost i/o-lets on GOPs for later to avoid causing any more serious problems.
cheers Miller
--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/JNDWHMHRFPT...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/5MQUYKKCBFK...
BTW: This fix by ben-wes works well for me:
https://github.com/pure-data/pure-data/pull/2788
On Thu, 2025-10-30 at 20:18 +0100, Miller Puckette via Pd-dev wrote:
Hmm... yeah, now I see the github issue...
cheers Miller
On 10/30/25 2:45 PM, Roman Haefeli wrote:
Hey
It's not only ghost inlets/outlets. Some patches using GOP features ('coords' ?) can look pretty messed up in current master (b8763947). This wasn't the case in 0.56-0. Looks like a regression.
Roman
On Thu, 2025-10-30 at 12:27 +0100, Miller Puckette via Pd-dev wrote:
To Pd dev -
Are there any more crasher bugs to fix? I think I want to leave cosmetic issues like ghost i/o-lets on GOPs for later to avoid causing any more serious problems.
cheers Miller
--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/JNDWHMHRFPT...
--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/5MQUYKKCBFK...
--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/3NQOAVGM5JQ...
OK... I've merged 1 of the two commits (e47c2d517) so far which I hope fixes things - the second commit seems to be an improvement but not crucial (and I really want to get 0.56-2 out to fix a couple of crasher bugs)
Let me know if there's actually an urgent need for that second commit (a356e00da4)
On 10/31/25 10:38 AM, Roman Haefeli wrote:
BTW: This fix by ben-wes works well for me:
https://github.com/pure-data/pure-data/pull/2788
On Thu, 2025-10-30 at 20:18 +0100, Miller Puckette via Pd-dev wrote:
Hmm... yeah, now I see the github issue...
cheers Miller
On 10/30/25 2:45 PM, Roman Haefeli wrote:
Hey
It's not only ghost inlets/outlets. Some patches using GOP features ('coords' ?) can look pretty messed up in current master (b8763947). This wasn't the case in 0.56-0. Looks like a regression.
Roman
On Thu, 2025-10-30 at 12:27 +0100, Miller Puckette via Pd-dev wrote:
To Pd dev -
Are there any more crasher bugs to fix? I think I want to leave cosmetic issues like ghost i/o-lets on GOPs for later to avoid causing any more serious problems.
cheers Miller
--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/JNDWHMHRFPT...
--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/5MQUYKKCBFK...
--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/3NQOAVGM5JQ...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/5ZCBCN3LIKY...
On Fri, 2025-10-31 at 10:58 +0100, Miller Puckette via Pd-dev wrote:
OK... I've merged 1 of the two commits (e47c2d517) so far which I hope fixes things - the second commit seems to be an improvement but not crucial (and I really want to get 0.56-2 out to fix a couple of crasher bugs)
Let me know if there's actually an urgent need for that second commit (a356e00da4)
I'm not really sure. Things have improved twice with recent commits. With master of the time of your mail, ghost objects were gone. But interactive GOPs using 'coords' felt a bit sluggish. Now, with current master (09598037) 'coords' updates happen quickly. I can't spot any regressions compared to 0.56-0.
Thanks to all contributors for addressing GOP topics.
Roman
On Sun, 2025-11-02 at 21:31 +0100, Roman Haefeli wrote:
On Fri, 2025-10-31 at 10:58 +0100, Miller Puckette via Pd-dev wrote:
OK... I've merged 1 of the two commits (e47c2d517) so far which I hope fixes things - the second commit seems to be an improvement but not crucial (and I really want to get 0.56-2 out to fix a couple of crasher bugs)
Let me know if there's actually an urgent need for that second commit (a356e00da4)
I'm not really sure. Things have improved twice with recent commits. With master of the time of your mail, ghost objects were gone. But interactive GOPs using 'coords' felt a bit sluggish. Now, with current master (09598037) 'coords' updates happen quickly. I can't spot any regressions compared to 0.56-0.
'coords' updates are slow again.
Also, there seem to be some debug messages left in. I get a lot of those in the Pd console:
y1 a = -1.000000, arraybox = 1 y1 a = -1.000000, arraybox = 1 y1 a = -1.000000, arraybox = 1 y1 a = -1.000000, arraybox = 1 y1 a = -1.000000, arraybox = 1 y1 a = -1.000000, arraybox = 1
Roman
On Mon, 2025-11-03 at 17:36 +0100, Roman Haefeli wrote:
Also, there seem to be some debug messages left in. I get a lot of those in the Pd console:
y1 a = -1.000000, arraybox = 1 y1 a = -1.000000, arraybox = 1 y1 a = -1.000000, arraybox = 1 y1 a = -1.000000, arraybox = 1 y1 a = -1.000000, arraybox = 1 y1 a = -1.000000, arraybox = 1
Correction: those are not printed to the Pd console, but to the terminal.
Rooman
On Mon, 2025-11-03 at 17:54 +0100, Roman Haefeli wrote:
On Mon, 2025-11-03 at 17:36 +0100, Roman Haefeli wrote:
Also, there seem to be some debug messages left in. I get a lot of those in the Pd console:
y1 a = -1.000000, arraybox = 1 y1 a = -1.000000, arraybox = 1 y1 a = -1.000000, arraybox = 1 y1 a = -1.000000, arraybox = 1 y1 a = -1.000000, arraybox = 1 y1 a = -1.000000, arraybox = 1
Correction: those are not printed to the Pd console, but to the terminal.
Line 592 in g_canvas.c
Roman
On Sun, 2025-11-02 at 21:31 +0100, Roman Haefeli wrote:
On Fri, 2025-10-31 at 10:58 +0100, Miller Puckette via Pd-dev wrote:
OK... I've merged 1 of the two commits (e47c2d517) so far which I hope fixes things - the second commit seems to be an improvement but not crucial (and I really want to get 0.56-2 out to fix a couple of crasher bugs)
Let me know if there's actually an urgent need for that second commit (a356e00da4)
I'm not really sure. Things have improved twice with recent commits. With master of the time of your mail, ghost objects were gone. But interactive GOPs using 'coords' felt a bit sluggish. Now, with current master (09598037) 'coords' updates happen quickly. I can't spot any regressions compared to 0.56-0.
Some GUI updates are really slow now. The lag seems proportional to the number of GOP abstraction in the canvas. Maybe this is related to redrawing the parent on certain actions? Anyway, I tried to capture the difference in screencasts that compare 0.56-0 (quick) to current master (slow):
https://netpd.org/~roman/tmp/gop-performance/
It seems that in 0.56-0 updating a GOP is not affected by the amount of other GOPs on the canvas (or it is so quick that I don't notice it).
Roman
Well, I tried to fix this but can't figure out how yet. The commit a356e00da4 seems to be necessary to address the problem in issue #2758 (sorry, I can't figure out how to make these citations look like links as the rest of you seem to be able to :) But that PR redraws the entire owning window - and if you've got 100s of objects getting resized this makes 100s of redraws. There should probably be a way to defer these redraws (as there is for dragging as in delay_move() ) but this could create all sorts of subtle problems with objects getting deleted and then modified afterward.
I also tried replacing the redraw (commented as "redraw parent to remove "ghost objects") with gobj_vis(..., 0) and gobj_vis(..., 1) but that somehow did nothing. So unless someone can come up with a better fix I think we should just leave this and try to improve it for 0.57.
here's a smaller patch that I'm fighting with:
#N canvas 374 278 777 417 12; #N canvas 850 145 788 454 $0-goprect 0; #X text 182 12 comment1; #X text 128 37 comment2; #X obj 19 284 outlet; #X obj 73 284 outlet; #X obj 261 222 s pd-$0-goprect; #X obj 261 122 tgl 19 0 empty empty empty 0 -10 0 12 #fcfcfc #000000 #000000 0 1 ; #X obj 261 146 * 100; #X obj 261 170 + 100; #X msg 261 195 goprect 10 10 $1 50; #X obj 370 81 tgl 19 0 empty empty empty 0 -10 0 12 #fcfcfc #000000 #000000 0 1; #X obj 370 105 * 100, f 6; #X obj 370 129 + 100; #X msg 370 153 donecanvasdialog 1 -1 1 0 -1 1 1 $1 50 10 10; #X obj 474 40 tgl 19 0 empty empty empty 0 -10 0 12 #fcfcfc #000000 #000000 0 1; #X obj 474 64 * 100, f 6; #X obj 474 88 + 100; #X msg 474 112 coords 0 -1 1 1 $1 50 1 10 10; #X floatatom 131 18 5 0 0 0 - - - 0; #X connect 5 0 6 0; #X connect 6 0 7 0; #X connect 7 0 8 0; #X connect 8 0 4 0; #X connect 9 0 10 0; #X connect 10 0 11 0; #X connect 11 0 12 0; #X connect 12 0 4 0; #X connect 13 0 14 0; #X connect 14 0 15 0; #X connect 15 0 16 0; #X connect 16 0 4 0; #X coords 0 -1 1 1 100 50 1 10 10; #X restore 53 51 pd $0-goprect; #X obj 424 188 s pd-$0-goprect; #X obj 53 205 f; #X obj 430 80 tgl 19 0 empty empty empty 0 -10 0 12 #fcfcfc #000000 #000000 0 1; #X obj 430 104 * 100, f 6; #X obj 430 128 + 100; #X msg 431 151 coords 0 -1 1 1 $1 50 1 10 10; #X connect 0 0 2 0; #X connect 0 1 2 1; #X connect 3 0 4 0; #X connect 4 0 5 0; #X connect 5 0 6 0; #X connect 6 0 1 0;
On 11/4/25 9:27 AM, Roman Haefeli wrote:
On Sun, 2025-11-02 at 21:31 +0100, Roman Haefeli wrote:
On Fri, 2025-10-31 at 10:58 +0100, Miller Puckette via Pd-dev wrote:
OK... I've merged 1 of the two commits (e47c2d517) so far which I hope fixes things - the second commit seems to be an improvement but not crucial (and I really want to get 0.56-2 out to fix a couple of crasher bugs)
Let me know if there's actually an urgent need for that second commit (a356e00da4)
I'm not really sure. Things have improved twice with recent commits. With master of the time of your mail, ghost objects were gone. But interactive GOPs using 'coords' felt a bit sluggish. Now, with current master (09598037) 'coords' updates happen quickly. I can't spot any regressions compared to 0.56-0.
Some GUI updates are really slow now. The lag seems proportional to the number of GOP abstraction in the canvas. Maybe this is related to redrawing the parent on certain actions? Anyway, I tried to capture the difference in screencasts that compare 0.56-0 (quick) to current master (slow):
https://netpd.org/~roman/tmp/gop-performance/
It seems that in 0.56-0 updating a GOP is not affected by the amount of other GOPs on the canvas (or it is so quick that I don't notice it).
Roman
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/WNOJ6FNESEY...
On Tue, 2025-11-04 at 11:23 +0100, Miller Puckette via Pd-dev wrote:
here's a smaller patch that I'm fighting with:
That's a good test patch. I'm not sure I understand what you're fighting with. It seems to work well with current master (a6cbfff0). When I shrink the GOP, the number box disappears.
I just had another finding. I get the 0.56-0 responsiveness back when I revert 36d7be0e on current master (it's the commit that adds the redraw on parent). Interestingly, even without the redraw, there are no left- over objects in my patches. However, it doesn't work for your test patch. The number box stays when shrinking the GOP area.
Roman
Yep, that's what's happening to me as well - I can revert 36d7be0e but then the test patch misbehaves.
cheers M
On 11/4/25 1:44 PM, Roman Haefeli wrote:
On Tue, 2025-11-04 at 11:23 +0100, Miller Puckette via Pd-dev wrote:
here's a smaller patch that I'm fighting with:
That's a good test patch. I'm not sure I understand what you're fighting with. It seems to work well with current master (a6cbfff0). When I shrink the GOP, the number box disappears.
I just had another finding. I get the 0.56-0 responsiveness back when I revert 36d7be0e on current master (it's the commit that adds the redraw on parent). Interestingly, even without the redraw, there are no left- over objects in my patches. However, it doesn't work for your test patch. The number box stays when shrinking the GOP area.
Roman
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/JGVXFPES5L2...
On Tue, 2025-11-04 at 13:47 +0100, Miller Puckette via Pd-dev wrote:
Yep, that's what's happening to me as well - I can revert 36d7be0e but then the test patch misbehaves.
I now also checked 0.56-0, 0.55-0, 0.54-0 and the patch misbehaves in the same way.
As I see it:
* 36d7be0e fixes an issue - that is old and certainly not a regression of 0.56 - at huge performance penalty
* All the GOP related regressions introduced since 0.56-0 are fixed in current master and are not relying on 36d7be0e
By principle of least surprise I'd vote for leaving 36d7be0e out in the upcoming minor release.
Roman
OK, I'm convinced -- reverting 36d7be0e :)
M
On 11/4/25 2:16 PM, Roman Haefeli wrote:
On Tue, 2025-11-04 at 13:47 +0100, Miller Puckette via Pd-dev wrote:
Yep, that's what's happening to me as well - I can revert 36d7be0e but then the test patch misbehaves.
I now also checked 0.56-0, 0.55-0, 0.54-0 and the patch misbehaves in the same way.
As I see it:
36d7be0e fixes an issue - that is old and certainly not a regression of 0.56 - at huge performance penalty
All the GOP related regressions introduced since 0.56-0 are fixed in current master and are not relying on 36d7be0e
By principle of least surprise I'd vote for leaving 36d7be0e out in the upcoming minor release.
Roman
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/XZN5CLH27Y3...
sounds right to me, too, for sure. if it doesn't even fix a regression, it's certainly better not to hurt performance. thanks for the tests on this! so it better remains a challenge for 0.57.
cheers, ben
On Tue, Nov 4, 2025, 14:26 Miller Puckette via Pd-dev pd-dev@lists.iem.at wrote:
OK, I'm convinced -- reverting 36d7be0e :)
M
On 11/4/25 2:16 PM, Roman Haefeli wrote:
On Tue, 2025-11-04 at 13:47 +0100, Miller Puckette via Pd-dev wrote:
Yep, that's what's happening to me as well - I can revert 36d7be0e but then the test patch misbehaves.
I now also checked 0.56-0, 0.55-0, 0.54-0 and the patch misbehaves in the same way.
As I see it:
36d7be0e fixes an issue - that is old and certainly not a regression of 0.56 - at huge performance penalty
All the GOP related regressions introduced since 0.56-0 are fixed in current master and are not relying on 36d7be0e
By principle of least surprise I'd vote for leaving 36d7be0e out in the upcoming minor release.
Roman
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/XZN5CLH27Y3...
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/SEUQYM3SC5G...
seems we're ready to go, here's a small set of updates for the doc branch
https://github.com/pure-data/pure-data/pull/2769
I just merged with master and also updated the manual version to 0.56-2
Em ter., 4 de nov. de 2025 às 11:00, Benjamin Wesch < benjamin.wesch@gmail.com> escreveu:
sounds right to me, too, for sure. if it doesn't even fix a regression, it's certainly better not to hurt performance. thanks for the tests on this! so it better remains a challenge for 0.57.
cheers, ben
On Tue, Nov 4, 2025, 14:26 Miller Puckette via Pd-dev pd-dev@lists.iem.at wrote:
OK, I'm convinced -- reverting 36d7be0e :)
M
On 11/4/25 2:16 PM, Roman Haefeli wrote:
On Tue, 2025-11-04 at 13:47 +0100, Miller Puckette via Pd-dev wrote:
Yep, that's what's happening to me as well - I can revert 36d7be0e but then the test patch misbehaves.
I now also checked 0.56-0, 0.55-0, 0.54-0 and the patch misbehaves in the same way.
As I see it:
36d7be0e fixes an issue - that is old and certainly not a regression of 0.56 - at huge performance penalty
All the GOP related regressions introduced since 0.56-0 are fixed in current master and are not relying on 36d7be0e
By principle of least surprise I'd vote for leaving 36d7be0e out in the upcoming minor release.
Roman
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/XZN5CLH27Y3...
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/SEUQYM3SC5G...
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/4JUO7GS5UOP...