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):

@porres said:

that's gotta be really rare and only if the random chosen number is stupidly low... basically zero!

... not that rare depending on the phasor frequency and sample rate. for example: with a 3kHz phasor at 48kHz sample rate, the value of the phasor will increase by 0.0625 per sample (3000 / 48000). so in this case, for ~6% of the cycles, the value won't cross 1 (if the offset is below these 0.0625), since the phasor will already wrap when > 0.9375.

not sure if this is a good explanation and completely valid - i'll wait for others to confirm or correct me.

as far as i can see, all versions here potentially drop impulses? feels like this shouldn't be hard to solve - but i don't see how, i admit. and i probably also should check the previous versions in more detail to really understand them!

another simple approach is this, where i'm trying to detect the significant wrapping for each cycle. this also leads to some dropped impulses - but it also adds some ...

patch: velvet~.pd

@porres said:

[...] Haven't tested my patch like that, could you do that too @ben.wes?

... since it's based on the same logic of the randomly offset phasor crossing 1, it also sometimes misses impulses, yes (checked with ~3000Hz):

@seb-harmonik.ar said:

if the generated random phase is less than a sample increment and the phase wraps around, it will never be bumped to above 1

certainly true in my case, yes - there are missing impulses:

@seb-harmonik.ar said:

* is more efficient than /

yep, that's certainly true, thanks! - had measured this in the past as well (and commented above). i was just naively thinking that it might make a difference whether the argument is an int or float (which is the case for pow ... [pow 2] is faster than [pow 2.01] for example). but this thought doesn't make any sense here.

this doesn't add any new concepts and in case of a samphold~ value of 0, it will not cross 0 - so it's certainly missing a few impulses as stated by @manuels ... but besides that, i wonder if i'm missing anything with this simple approach?

(in this case with ELSE's zerocross~ for upward-crossing detection - but a vanilla option would also be possible with 3 more objects iirc)

EDIT: patch: velvet~.pd
EDIT2: ... and a noise value of 0 will not have a sign to copy in this case via x/abs(x), but result in a factor of 0 - so it will obviously prevent an impulse output. and if you know about the efficiency of (x+1)/2 vs. x*0.5+0.5, let me know.
EDIT3: i guess that the /~ 2 is not a good idea here ... i saw in the past that pow~ is quite a bit faster with integer arguments - but i also saw that *~ is faster than /~. and although i don't know much about the details going on there, i assume that float division won't profit much from an integer divisor ... anyway, this is getting a bit off-topic.

following up here if anyone else is curious about this:

while searching for more information on the hid "output report" structure of the dualsense controller, i stumbled upon a python library that implements all of this here: https://github.com/flok/pydualsense/blob/master/pydualsense/pydualsense.py#L445

based on that, i finally felt confident enough to give it a try with a short report that should only change the bytes for the big motors:

hidapitester --vidpid 054C:0CE6 -l 5 --open --send-output 2,255,87,80,160

... the last 2 bytes being the motor levels. aaaand ... it works!

turning them off again via:

hidapitester --vidpid 054C:0CE6 -l 5 --open --send-output 2,255,87,0,0

@oid thanks for pointing me to the option of using [command]! /proc/ is not available on macOS afaict - but in the [command] context, i might use a little tool i found here: https://github.com/todbot/hidapitester

... i admit that i'm a bit scared of destroying things with these low level hid commands. will try to understand of bit more before actually writing data!

i'm currently using the [hidraw] external on macOS to read inputs from a PS5 dualsense controller.

it's a wonderful external and works great for this - but it doesn't allow to output hid data to the controller (to control force feedback etc.). any ideas if there is a solution for this that i might be missing (on macOS)?

@jameslo said:

[...] In my (much less nice) version [...] I just used the final [s~] to get the resulting signal.

after reading this, i mainly get the impression that your version might have been much less complicated!

... it seems so obvious now to just continue the chain from the last s~ instead of "sending" to nirvana and adding a logic to achieve the correct outlet~ result. damn. thanks!