for the sake of completeness (and thanks to @manuels' inspiring patch), i'm adding the "efficient" version here (not well tested neither):

dynamicsmooth-efficient~.pd

... i really like this approach and i will create an external for it as well.

really cool stuff - had fun playing around with this! now i didn't understand the whole patch (which is insane) ... but it looks like you're checking the closest "pixels" only for each mass? seems like a great optimisation so that you don't need to check against every pixel. did i get that correctly?

oh ... i didn't see the discussion here ... just built a little (and certainly dirty) patch for this after the discussion on facebook:
patch_n_bitmaps.zip

it obviously becomes very slow with lots of canvases (and i'm already omitting the white pixels):
2024-09-21 22-46-18.mp4

... plugdata on the other hand can deal with these quite easily - i creates rounded cnv rectangles though.
2024-09-21 22-58-59.mp4

(i scale them in that video - so this is not a glitch, but many wide rectangles)

EDIT: this patch only works with a specific 3x8bit bmp format. so it would certainly look a bit funny with other formats.

you can check the help patch of this simplex~ external here (it's also on deken) - it includes very basic vanilla 2d and 3d oscilloscopes: https://github.com/ben-wes/pd-simplex

i realized that i obviously didn't follow all categories on this forum - so i missed your post and this response comes a little late. anyway: thanks for sharing! it reminded me of my approach for a vanilla pitch tracker. i now also realized that i didn't need a [block 1] for a 1-sample delay (which was there until today), but could use [rzero~] instead:

patch: zc_pitchtrack~.pd

@manuels said:

Could certainly be optimized in some ways (especially using ELSE objects). But does it even work? I don't have a good method to test it, unfortunately.

nice! - i like this counter for samples per phase:

... from what i tested: it behaves perfectly well up to nyquist - although also in this range, there are sometimes consecutive non-zero samples (which i'm still not 100% sure if valid. see the 1, 1 in the middle below. the blue graph is the scaled offset per phase).

here's a completely vanilla version of the delay variant avoiding [expr~] (with some rather ugly hacks to achieve exact values of -1, 0 and 1). it works for all frequency input < nyquist (for nyquist, the > 0.5 check fails):

velvet-delay-vanilla~.pd

EDIT: seeing now that this doesn't really add anything to @ddw_music's approach at https://forum.pdpatchrepo.info/topic/13317/looking-for-velvet-noise-generator/52 - except for my failed try to achieve non-interpolated values with delread4~.

@whale-av said:

So...? please check this but [print~] produces output consistent with the rules as I understand them.....

i think, you built a version at nyquist frequency!

probably, i should read more into it (no time right now unfortunately) ... i'm not sure if velvet noise needs to meet the requirement of the random position of the impulses in each cycle. obviously, that's not possible anymore when a cycle is just 2 samples.

the idea in the version mostly discussed above is exactly that though: there's one impulse per cycle and this impulse should be placed at a random position in its cycle with random polarity. and the cycles can be of any length (samplerate / frequency).

this graph in https://acris.aalto.fi/ws/portalfiles/portal/13412521/applsci_07_00483_v2.pdf (page 4) is showing that quite well:

EDIT: this brings up an important question though (which is also probably answered in the papers): are consecutive values of 1, 1, 1, -1, -1, -1 or -1, 1 allowed? not sure ... but these wouldn't be actual impulses anymore then, right?

@porres said:

I can't feel any perceptual difference with just positive impulses, for instance....

not sure if i understand correctly ... you mean you don't hear a difference between the mixed impulses and just positive ones?
in that case, you might need to check higher frequencies and tune it louder.

spectrograph~ (with db and log display) for both versions at ~3kHz:

"balanced":

positive only (missing some lower frequencies):

about the purpose: https://acris.aalto.fi/ws/portalfiles/portal/13412521/applsci_07_00483_v2.pdf talks about an application for late reverberation. i didn't completely read it, i admit - but i assume, for that purpose, the impulses should have both polarities.

@manuels said:

@ben.wes Did you do the testing with non-integer fractions of your sampling frequency? You mentioned 3kHz at 48kHz SR as an example, which shouldn't make problems ....

sorry for the confusion! - it weren't exactly 3kHz, since I'm setting the frequency with a logarithmic slider. tested once more with 3026.2Hz here now (which was probably also the value yesterday). i'm displaying the last 3 outlets here that i added to your patch (additionally offsetting the phasor for visual clarity):