Keen in WebUSB/WebHID support?

[jraoult]

Thanks for your work on Maschine MK3 support @asutherland. I'm glad I found this library because I was struggling to get it done in JS. My target is actually the web platform (Chromium likes for now). So I took your code and abstracted the USB (and HID) bits to use WebUSB and WebHID.

My first question is have you ever considered creating a PR to the upstream (https://github.com/met5678/node-traktor-f1) with your changes? This is for now the only version published to NPM and your work is a very nice addition. Alternatively what about publishing your fork which sees to be way more advanced?

Second, would you consider a PR with my changes. The idea is to enable the end user to switch the USB comms implementation so that the library can be used in Node or the web.

WDYT?

[asutherland]

My first question is have you ever considered creating a PR to the upstream (https://github.com/met5678/node-traktor-f1) with your changes?

My initial upstreaming cleanup at met5678#1 didn't receive any feedback, so I've haven't pursued additional upstreaming.

Alternatively what about publishing your fork which sees to be way more advanced?

I can certainly do that for visibility. Any naming suggestions?

Second, would you consider a PR with my changes.

Absolutely! While it doesn't seem likely that WebUSB/WebHID will get cross-browser support anytime soon, it's definitely a better runtime situation than what the node.js situation requires.

[jraoult]

I can certainly do that for visibility. Any naming suggestions?

I didn't think about it but you are right that the scope is broader than traktor now and will be for more than just the node runtime. Something like ni-controllers-lib? I know it is not glamorous but it would be easy to find and describes what it is.

Absolutely! While it doesn't seem likely that WebUSB/WebHID will get cross-browser support anytime soon, it's definitely a better runtime situation than what the node.js situation requires.

I'll obviously make sure than both runtime are fully handled.

Last question regarding the Maschine MK3. Am I right to think that you haven't handled the encoder wheel rotation yet (offset 11 here //https://github.com/Drachenkaetzchen/cabl/blob/develop/doc/hardware/maschine-mk3/MaschineMK3-HIDInput.md)?

[asutherland]

Last question regarding the Maschine MK3. Am I right to think that you haven't handled the encoder wheel rotation yet (offset 11 here //https://github.com/Drachenkaetzchen/cabl/blob/develop/doc/hardware/maschine-mk3/MaschineMK3-HIDInput.md)?

Correct. I suppose that counts as one of the "steppers" like the F1 already has support for.

In general I think it'd be great to provider nicer handling of the encoders/knobs. My only use-case has been a major hack to control the backlight brightness of a streamdeck from my mk3.

And in general, I'm not particularly invested in the eventing model used by this library right now. I use glue layers in https://github.com/asutherland/taskolio/blob/master/controller-webserver/src/controller/maschine3/controller_driver.js and https://github.com/asutherland/taskolio/blob/master/controller-webserver/src/controller/maschine3/mode_dispatcher.js to walk a stack of modes, directly invoking specially named handlers like onKnobTurned on the first mode that implements a handler.

[jraoult]

Correct. I suppose that counts as one of the "steppers" like the F1 already has support for.

I need to dig a little more but it looks like it goes cyclicly from 0 to 15 and then starts again to 0, so not really like stepper.

I'll start creating PR on your repo then. We can figure out naming/publishing down the line.

Last question before I commit to it. I actually converted the codebase to typescript. It helped me while browsing the source code because I could get auto-completion and type-checking. Is it something you would consider or you would rather stay with JS? Happy to strip down the types if you prefer.

[asutherland]

I need to dig a little more but it looks like it goes cyclicly from 0 to 15 and then starts again to 0, so not really like stepper.

The comment at the top of https://github.com/asutherland/node-traktor-f1/blob/maschine-mk3/lib/components/input/stepwheel.js claims it was expecting a 4-bit value (and then fails to handle wraparound unless I'm missing something.)

I'll start creating PR on your repo then. We can figure out naming/publishing down the line.

Sounds good!

Last question before I commit to it. I actually converted the codebase to typescript. It helped me while browsing the source code because I could get auto-completion and type-checking. Is it something you would consider or you would rather stay with JS? Happy to strip down the types if you prefer.

I'm fine to convert to typescript. Haven't had much experience with it in practice, but I'd be interested to experience the the fancy VSCode support and in general see if it seems like I should move my taskolio project to typescript or if I should (over a much longer process) migrate to Rust. (Edit: clarifying, the pure JS route hasn't been working out there for me and I want some type-system enforced rigor, which would also happen while cleaning up existing semantics that have evolved over time.)