Adding this here as well since I wasn't aware of it ... the download for the Pd64 version is also available from:
https://puredata.info/downloads/pure-data (experimental releases on the right)

This is probably not a valid solution - but you can already work with 64bit versions of Pd. Artifacts are generated here:

• https://git.iem.at/pd/pure-data/-/artifacts

I tested this with the macOS_pd64 installer and actually get this result:

In that case, integers up to 2^53-1 can still be represented (which equals 9_007_199_254_740_991).

The 64bit version explicitly states that it's still EXPERIMENTAL though. And if your patches rely on externals, these might possibly not be compiled for 64bit (yet) and therefore not be available through Deken (ELSE is not there for example).

Besides that, the onset option described in the help of [tabread4~] came to my mind. This should give you a larger range, too.

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

@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.

@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.

@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?

Joining a bit late here. But this discussion just reminded me of two abstractions that I created in the last days. Maybe they might be relevant (otherwise sorry for the noise).

This one will change the leading symbol or number of an incoming message to a sequential number starting from 0:
sequential_remessage.pd

The other one I used to create consistent numbers from a symbol to generate colors for symbols (using the checksum as seed) - I tried to recreate the adler-32 checksum algorithm here (same approach as @jameslo mentioned above with the hash):
checksum.pd

Thank you both for further adding to this discussion! Sorry for not mentioning a use case earlier - I was considering to describe it in the question, but then decided to be lazy since I thought that the question remains the same.

So I actually have 2 use cases: One is related to a simple "preset management" experiment that is made of a central object managing the presets and little preset plugins that are cross-connected (output->input, input->output) to sliders or other value controlling objects. The "manager" needs to communicate with these and also store their names and values, of course. I didn't want to give them all unique names and also didn't want to give the "manager" all their names though. So currently, all these objects (including the managing object) get the $0 of the parent and then all relevant names are created based on it. The stored names of these plugin objects are created based on the parent's $0 combined with the difference between their $0 and the parent's $0. It's a bit of a mess, but it actually works quite well. Not sure if I managed to describe it in some understandable way. But since everything is based on just the parent's $0, it would be nice to omit that in the parameters and just access it from inside the abstractions.

The other use case I had in the past is abstractions that use cloned abstractions inside of them like [clone foo 16 $0]. Then all clone instances can be connected to the main abstraction's sends/receives/arrays etc. without collisions.

In the second case, it's not a problem at all, since it works well and is reasonably understandable. What bothers me in the first case though is that a user actually needs to write the $0 as a parameter for every object which is rather annoying. But then again, it's not a serious preset manager anyway and there's better stuff available already (I mainly checked out else's preset system so far) with a completely different approach.

@oid thanks a lot for the quick response! i'm trying to stick with vanilla if possible - so i'll keep the $0 as parameter for now. but good to know that there is this solution available if i include iemguts!

Hi all, not sure if this is a reasonable idea - but I'll give it a try: is there any way to access a parent's id from inside an abstraction? I always forwarded the $0 value of the parent patch as an argument in my abstractions so far if needed - like [foo $0] for example ... but I wonder if I might be missing some other option to access it?