update: this is kind of solved (or at least clarified) - it's actually a bug in pd. so no more need to investigate further here.

@whale-av adding to my previous comment: my assumption is that this might be a bug due to the novelty of this feature. at least i don't see how the type of outlets (multichannel or separate channels) could cause different output when they're transporting identical data.

i made a simpler test patch here now which i'll add to an issue report ...
compare-1sampleblock_mc-outlet.pd

no, snake~ is actually vanilla since the release of pd0.54 with multichannel features.

i was about to report an issue on the pd github - but since i really don't know what's going on, i thought i'd share this here first and maybe someone has an explanation for it ....

i've been experimenting with a simple patch for random-walking the surface of a sphere. the current algorithm is not very elegant since it uses random steps that don't have equally distributed distances (but rather form the shape of a cube). i use 1-sample-send~/receive~ to feed back the current position for the calculation of the next position. the weird thing is that it works perfectly well if i output my coordinates with 3 outlet~s ... but the result looks different for the exact same algorithm if i output it via 1 multichannel outlet.

so it seems like the outlets are affecting what's happening inside the subpatch?!?

here are 2 screenshots for these 2 cases - with 3 outlets:

with multichannel outlet (the coordinates are no longer on the surface of the sphere, but start to blur into a cubic shape):

and here's the patch for testing (vanilla besides requiring Gem ... and the relevant part is in the 2 subpatches obviously):
spherical_randomwalk_1sampleblock_mc-outlet.pd

Thanks for your responses! now that's interesting about the s/r performance - in this case, i get the following results (repeatedly tested again):

[perf_meter]: pd_nop
    bangs  time(ms)  bangs/ms
  9603563    1000.0   9603.55
 
[perf_meter]: t_f
    bangs  time(ms)  bangs/ms
  9987069    1000.0   9987.06
 
[perf_meter]: send_receive
    bangs  time(ms)  bangs/ms
 10147908    1000.0  10147.90
 
[perf_meter]: connected
    bangs  time(ms)  bangs/ms
 10711894    1000.0  10711.88

Here's the patch if you want to check these on your side: test-performance-nop.pd

I updated perf_meter.pd with this additional newline for clarity - but as I said, I'm also not completely sure if this is a valid way of checking performance.

Not sure if this should be its own topic - but I also felt that it might be off-topic as a comment. I followed the interesting discussion/posts and inspiring patches in https://forum.pdpatchrepo.info/topic/14556/recursive-count-up-down yesterday. In the solution by @seb-harmonik.ar I was surprised by the [pd nop] usage since I would probably have used [t f] in cases where I want to visually structure or bundle float connections (this might also be a misunderstanding on my side in this case btw).

On second thought, I assumed that the former option might be faster though since it's just a "prolonged" connection through inlet->outlet and doesn't need to check types or so like [trigger] might possibly do (I didn't check Pd's code here - which I would most likely not understand - and this is probably also a rather naive technical perspective).

I sometimes test the performance of control rate solutions in my own patches with a little abstraction I created for this purpose: perf_meter.pd (this just repeatedly bangs a patch branch for 1s and counts the bangs) ... so I tried to compare the two with a simple counter - and to my surprise, the trigger seems to be faster (very slightly - but I get results like this repeatedly):

Now there are several questions:

• does my [perf_meter] abstraction make sense at all?
• if so - is there an easy explanation to this?
• did I understand the purpose of your [pd nop]s at all, @seb-harmonik.ar?

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?

Oh! I just saw that there's another issue linked to this one where you can find a url to a compiled version of pdnext that should work:
https://github.com/sebshader/pdnext/issues/25

M2 works great from my experience. The problem is most likely that you have MacOS Sonoma running on your machine?

I don't know what changed there, but it's obviously not yet working well with the current version of Pd unfortunately (and which is why I did not yet update my system).

It was reported here with some maybe helpful info in the discussion: https://github.com/pure-data/pure-data/issues/2105 ... I don't know if it's easily possible to compile a version with an updated tk/tcl though.

I was quite fascinated by @manuels' patch (thanks for sharing!) and tried to understand what was going on, which led me to rebuilding and documenting the algorithm (possibly needlessly more complicated).

This doesn't add anything to the solution here - but maybe it can be insightful for someone else stumbling upon this thread ...

subsets_documented.pd

@Muology: Just answering to the second part for now ... for generating all combinations of 2 elements, this here will do (subpatch pd iterate_list is on the right. should probably be an abstraction ... and the result is not logically ordered).

if you want to create all combinations with arbitrary lengths, it can certainly be done in a similar manner and I'm pretty confident that one could find an abstraction (or external) for this somewhere. I didn't find one yet though and I'd need a little more time and focus to build it, I'm afraid.

list2pairs.pd