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

@ben.wes Is [snake~ out 3] your abstraction, and is it also blocked to a single sample?
David.

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

@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

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.