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.