@Peter
v0.1.1 is up on deken: https://deken.puredata.info/results.html?name=hidraw
on v0.1.0 the subsequent mouseweel scroll (more precisely all the
message) was interrupted because it was the same as the previous
message. Now on v0.1.1 the message gets transmitted but is the same as
the previous. Nothing gets transmitted if the second outlet does not
output 2 (read Ok).
--
Mensaje telepatico asistido por maquinas.
On 17/04/2024 00:06, Lucas Cordiviola wrote:
@Peter,
yes, there's a bug. [hidraw] should not have an internal change
mechanism.
i had used your mouseweel example to debug.
I should fix this soon with a new version and also upgrade to hidapi
0.14.0
thanks,
:)
--
Mensaje telepatico asistido por maquinas.
On 16/04/2024 20:31, Lucas Cordiviola wrote:
there could be a bug in [hidraw]'s internal change mechanism.
(missing some change?)
not sure when i'll try to debug.
I had created an issue at https://github.com/Lucarda/pd-hidraw/issues/4
--
Mensaje telepatico asistido por maquinas.
On 16/04/2024 06:55, Peter P. wrote:
Hi list,
I am using [hidraw] to read events from a mouse. I understand that
hidraw in fact reports the entire state of the device rather whenever
some event happens. Interestingly, moving the scroll wheel down by one
step is reported, but moving it down another step afterwards is not
reported unless a different event (say, moving the mouse a pixel) is
done.
It makes somehow sense if I think of the mouse wheel as a state device,
where a repeated "wheel down" is not considered as a change of state.
Nevertheless it seems impossible to parse repeated wheel down actions.
Does anyone have an idea (besides using [hid] instead)?
Thanks!
Peter
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
