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!

so you're trying to run the current version 0.55-0?

i admit that i can't make sense of all the output you get here - but this "livecast" thing seems a bit weird to me. is that some kind of plugin? ... did you try running Pd without standard paths and custom paths? you should be able to do this by adding the startup flags -noprefs -nostdpath when running Pd (see https://msp.ucsd.edu/Pd_documentation/x3.htm).

adding one more detail ... with a little logic inside the cloned patch, it's not necessary to set the audible instance id with an additional parameter - the max id can also be derived like this for example:

@jameslo that's a very good point and i didn't consider it at all. thanks!

without checking, i assume that it's exactly as you say since the instances are created in ascending order and i certainly introduced 1-block-delays that way as described in the help of s~/r~:

You have to get the [send~] sorted before the [receive~] or else you'll potentially get a one block delay.

(i'm actually not sure why it would only "potentially" happen)

... attaching an updated patch that's actually quite fun to play around with (in this case, the clone needs a second argument for the audible instance): test-am-clone.zip

EDIT: checked and confirmed now (that the sender should be in the previous instance).

yet another option that may (or may not) pass efficiency police checks: send the result of each instance to previous (or next) instance ...

in this case, the signal is passed through starting from the last instance. since the last instance doesn't have a corresponding sender, the [s~ 3-instance] becomes necessary with a constant signal of 1 as a factor. it would work as well in the opposite direction, of course. the cloned instances are all muted except for instance 0, which is the result of all multiplications.

this is a quick hack - not sure if it does what it's supposed to do. if you want to check, here are the 2 patches: test-am-clone.zip

after 5 ms go to 0 in 20ms

... I'm pretty sure it's "after 20 ms go to 0 in 5 ms" in this case though? can't test on the phone here right now, but imho, a message consists of: target value, ramp time, delay time (which is also the inlet order).

@oid said:

[...] They are the same [...]

i didn't try to check the technical details there and i certainly don't say that this is wrong - but i'm surprised anyway when comparing the two. shouldn't these give the same result then?

this perf_meter is an abstraction i made to check control rate stuff by sending as many bangs as possible for ~1s and counting them (obviously the measurement itself skews the result). with this, i get:

[perf_meter]: send/receive
    bangs  time(ms)  bangs/ms
 12693566    1000.0  12693.57
 
[perf_meter]: connected
    bangs  time(ms)  bangs/ms
 13707334    1000.0  13707.33

... also attaching the abstraction - if you want to test or check if there is anything wrong with it: perf_meter.pd