When you open dummyResource2.pd and drag the bottom of the window, the patch moves with it. Most patches are anchored to the top and left window border. I traced it to the last line in the patch, which is

#X coords 0 537 1 536 25 40 0;

If you delete it, the patch returns to the normal anchoring.

What does that line do, and how do you suppose it got there?

@jameslo https://puredata.info/docs/developer/PdFileFormat
It's a slightly flippant reply I know......
Maybe the reason is in the "remarks" for the #X coords entry but it needs further investigation.
I don't think it should be the last line....... there should be a "restore".
David.

@whale-av Not so flippant...it led me to my answer!

That patch I posted earlier started out life as an abstraction that was supposed to be included over and over again in some parent patch, and I had made it graph on parent. Later I got rid of the graph on parent when I reworked it to be used in [clone]. When I make an empty patch I get:

#N canvas 846 196 450 300 12;

(I think "restore" is only needed to close subpatch definitions) and when I add GoP I get:

#N canvas 846 196 450 300 12;
#X coords 0 -1 1 1 85 60 1 100 100;

But when I remove GoP, coords remains but its arguments change:

#N canvas 846 196 450 300 12;
#X coords 0 300 1 299 85 60 0;

So it's not quite the same as what I started with, although it seems like it ought to be.

@jameslo Interesting! I experienced this behaviour before and had no idea what was going on. I just ignored it then since I probably did not need to scale that specific patch vertically a lot. But thanks for pointing me to the reason here!

It's obviously simply caused by activating and deactivating GoP ... which to me feels like a bug actually. At least I don't see why the behaviour afterwards should differ, since I'm restoring the previous state from a user perspective (and would therefore expect identical behaviour). What do you think?

@ben.wes Of course I agree, but there are much worse things than that, things I can't even imagine how a language like this could address. Here's a dead horse I beat a while ago: s~r~NoLatency.pd
See how there's no latency in the s~/r~ pair? Now select [r~ next], cut it, paste it right back, and connect it back to [-~]. Voila! One audio block of latency and it looks exactly the same!

@jameslo haha, that's quite irritating! it's a case mentioned in ../3.audio.examples/G05.execution.order though. but what i wonder when testing it here now: how did you get a latency of 0 blocks in the first place?

this here would be the safe solution, i guess - but it also not very elegant with the hidden send/receive, i admit:
s-r-nolatency-subpatched.pd

EDIT: ... and sorry about drifting off-topic here now! but anyway: do you plan to report this coords leftover thingy? otherwise i'd create an issue for it if you want.

@ben.wes Your safe solution is what I poked fun at here: https://forum.pdpatchrepo.info/topic/13512/s-r-throw-catch-latency-and-object-creation-order. So to make a s~/r~ pair act like a plain audio connection, you have to use a subpatch idiom that employs an audio connection? Then forget the idiom and just use a plain audio connection! The upshot of that topic is that the audio chains are sorted in reverse order of the creation of their heads, so when you cut and repaste [r~ next] you are effectively making it run before [phasor~] and by extension before [s~ next]. But the opposite is true among cloned abstractions--those are sorted in creation order.

Yeah, I'm not going to report that GoP issue, you're welcome to if you want.

@jameslo oh, wow ... thank you for mentioning that thread and for the research - that's a nice rabbit hole! ... i didn't know about how exactly the creation order would affect the dsp chain. good to know for sure! although i will probably still not feel comfortable dealing with these invisible properties as you say (really feels like relying on the creation order of control connections). but yeah - at the same time, it's absolutely useless to use the s~/r~ at all then in the patch above.

i'll check tomorrow if related issues (to the coords topic here) were discussed and otherwise create one.

Just a short follow-up ... there is already an issue since a few months describing this:

• https://github.com/pure-data/pure-data/issues/1899