🤖│community_dev

[quick bough]

Meh, morse code is not as nice as uwu code

I learned to type in uwu code within a few hours

and can now type at 14 WPM

I still barely remember morse code after multiple days of obsession with it (in the past)

[quick bough]

Called it tho

[floral crane]

I think someone needs a stenographer keyboard

[quick bough]

Wooting Steno™ when?

I mean if I wanted to type fast, the UwU would definitely not be it

Dvorak seems interesting for typing faster, too, but I cba to learn a new keyboard layout

I just barely adjusted to the switch from QWERTZ to QWERTY

[floral crane]

I tried dvorak but the shortcuts being different stopped that

[quick bough]

Wdym?

[floral crane]

xcv are in different locations, I need copy/paste/cut to be in the same locations

ctrl s, ctrl z, y, etc

typing is one thing but shortcuts are another to re-learn

[quiet root]

dvorak has been proven to not be all too much better

[quick bough]

Could make ctrl key into a new FN layer in the wootility and bind the keys as you would have them on qwerty?

[floral crane]

💀

[quick bough]

I love novel input methods like that 😄

[mossy spruce]

is there a keylogger that lets u record keys for a unique rgb output

[grand flax]

Sorry what would u want it to do?

[mossy spruce]

whatever sequence u press the rgb also lights up in that sequence

idk if that even makes sense

[floral crane]

there's an effect like that

[faint slate]

How to develope wooting

[quiet root]

theres a link in the channel description

[faint slate]

ah thanks

[spark canyon]

hey does anyone know why wootverlay shows the wrong keys for me?

like

i set it up to be W and E and the overlay still shows WASD, Caps, Ctrl and the Spacebar

[grand flax]

Is this for twitch? @spark canyon

OBS uses it's own browser, so the config doesn't sync between if you were testing it on your browser before using there, so after adding it on OBS you'll have to repeat your customisation by right clicking on the widget and hitting inspect

[spark canyon]

yeah i figured that out eventually

still appreciate the help tho o/

[acoustic karma]

.

[shadow drift]

.

[atomic hearth]

wooting double moovement is ban in fortnite

in chapter 5?

[bleak raft]

It's now included inside of the game, so I don't think you would be ban for using it ? 😅

[dawn quarry]

Is there a way to do more detailed customization than wootility, e.g. by writing code directly?

[quiet root]

wootility exposes all the configuration the firmware allows

if you need more you will need to write custom wrappers/tooling translating analog to keystrokes or sending rgb by using our SDKs

[dawn quarry]

I see. thank you!

[faint slate]

😭

[paper jolt]

can anyone tell me why when i go to view my order i get an error

[quiet root]

first wrong channel. this channel is for (as the channel description says) people programming things around the keybaords SDKs. #1019755933959733258 if where you wanna ask @stark vault

[stark vault]

ohh my bad i'm sorry, thanks for the info

[karmic forum]

Random questions what is the wooting v2 interface and how could I ask the device for its firmware version my best guess is the wooting_usb_send_feature_with_response function, but im not sure what arguments to give it

[strong siren]

Check pinned messages

[karmic forum]

i see that now thank you

[quiet root]

For an updated commands list https://gist.github.com/BigBrainAFK/0ba454a1efb43f7cb6301cda8838f432

[quiet root]

also v1/v2 has to do with how rgb data was sent to the keyboard and you should be able to safely assume all keyboards use a v2 interface now

the only keyboards that would ever not do this are severely out of date wooting ones and twos close to when they were initially shipped

[karmic forum]

I see ok so it should really effect anything

[quiet root]

outside of rgb no. although the usb commands may not be available in older firmware versions

Rockys list would be wooting firmware v1.x while the list i gave you is for 2.x (there is a revision list with dates on github)

[karmic forum]

Thank you

is there anything documenting the returns of these commands

[quiet root]

not documented no

[karmic forum]

ok

I found out some things

[quiet root]

most of the commands are about wootility configuring

[karmic forum]

but its a lot of trial and error from what i see

[quiet root]

and theres no real need to document these as wootility doesnt hide anything that would be exposed here

[karmic forum]

yeah

[quiet root]

you could of course unasar the installed wootility's code and unminify it by hand to see how we handle certain commands

then youd basically know whats returned and how to interpret the data

[karmic forum]

well im not needing many of these commands most what I need is provided with the rgb stuff

[quiet root]

in terms of rgb if i recall right most is just arrays of colors basically

if you check our rgb sdk you can see its quite simplistic

[karmic forum]

yeah its not that complicated

[grand flax]

If anyone would like to try out an audio vis, here it is :)

https://github.com/DjCrqss/Woot-vis > Click on released on the right hand side and Woot-Vis 1.0

[karmic forum]

Oh if we can post our projects here then here is mine https://github.com/MrEnder0/wootili-view
Stars on the Github repository would be appreciated.

[quiet root]

thats the whole point of the channel yes. posting cool third party apps made by the community

[grand flax]

This is cool!

[strong siren]

sadly this doesnt run on my windows machine. how is the performance? looks cool!

[placid ledge]

@strong siren You wanna take this for a quick spin? https://github.com/WootingKb/wooting-rgb-sdk/pull/67

I was about to release this as 'stable' https://github.com/WootingKb/wooting-rgb-sdk/releases/tag/v1.6.2
but then I noticed the issue you made and that is defo a blocker for a 'stable' build

[strong siren]

ah nice! ye wil ltest

i dont remember the context for that issue, im pretty sure artemis works around it

[placid ledge]

You can workaround it by selecting all the devices and resetting them first before closing, but that shouldn't be necessary

It's what my test code for the Wooting.NET library was doing, which is why I never noticed it myself

[strong siren]

yeah, artemis will probably do that anyway since we dispose devices individually but that new behavior definitely makes more sense

@placid ledge seems good

[placid ledge]

Awesome, tyty

[karmic forum]

thanks 🙂

[placid ledge]

https://github.com/WootingKb/wooting-rgb-sdk/releases/tag/v1.6.3

[worn oak]

It won't let me confirm my address for it to order to ship

[jagged echo]

Wrong channel, ask either in #💬│general or in #1019755933959733258

[worn oak]

thank you

[karmic forum]

@placid ledge I made some changes to the pr and clairified somethings that you said were unclear, let me know if any other changes are needed! 🙂

Also what specifically are you working on using egui with the wooting sdk that you mentioned.

[quiet root]

what pr

[karmic forum]

this

[placid ledge]

I've been building a little tool using the plotting from egui to visualise the analog signal history and key press/releases to help debug analog signal issues, mainly for the beta firmware

[karmic forum]

Oh yeah I remember seeing this in #📰│wootility_updates, yes it looks pretty cool. 👍

[grand flax]

Hey does anyone know how to read the analog buffer in a way that each key pressed is not the symbol but the row/col? :)

[quick bough]

Is that not the way the analog buffer is reported by default?

Been a hot minute since I looked at it, gotta reacquaint myself

Oh right, yeah, it reports only a scancode that may be converted to a keycode

They would have to add something to the firmware to report it in a different way

Related issue: https://github.com/WootingKb/wooting-analog-sdk/issues/12

[grand flax]

That would be great as it will pave the way for creating pressure sensitive rgb effects

[strong siren]

you can sort of do it already but it's very annoying

[grand flax]

Ooh what way do you do it currently?

[strong siren]

the long way. grab inputs separately and map them to the analog scancodes

artemis has this

[grand flax]

Does that not get affected by remapping or other layouts?

[strong siren]

Yes, artemis lets you edit the layout to make it match up. Of course having the analog sdk actually give you coords would be nice :p

[grand flax]

Ahh right makes sense thanks

[karmic forum]

wait so if someone has a custom layout there wouldent be a way to detect what row and collum is being pressed?

[strong siren]

on the artemis side, if you change the mapping on the keyboard, artemis would require a remapping of that key<->led pair. I'm not 100% because I don't remap anything on my keyboards :p

[quick bough]

Yeah, I've also done something like this already: https://github.com/Sainan/keyboard-jelly-effect

No user remapping, because it works on my machine

[quiet root]

correct. as far as im aware you wouldnt be able to distinguish which is sort of the goal as it means games etc wouldnt know you modified the keymap on the keyboard

[regal raptor]

I finally got my 60HE yesterday. and I am wondering about some features that would be nice to have if possible. Would there be a possibility for macros and double tap in the future ?

double tap would work almost like mod tap but instead of holding down the button you do a quick double for the secondary input

Macros would be pretty much the same as how macros has always worked

I always used macros on my old Logitech keyboard and would like to use that on my wooting

[karmic forum]

https://wooting.io/wootomation

a simple google search

[regal raptor]

yea found it, playing around with it right now

[karmic forum]

Hello im trying to have github actions build and release binaries for my rust app and I get the following error in the actions outpit

error: failed to run custom build command for `wooting-rgb-sys v0.3.0`

Caused by:
  process didn't exit successfully: `/home/runner/work/wootili-view/wootili-view/target/release/build/wooting-rgb-sys-514f195cb47379e0/build-script-build` (exit status: 101)
  --- stderr
  fatal: not a git repository (or any of the parent directories): .git
  /usr/include/stdint.h:26:10: fatal error: 'bits/libc-header-start.h' file not found
  thread 'main' panicked at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wooting-rgb-sys-0.3.0/build.rs:32:10:
  Unable to generate bindings for the Wooting RGB SDK: ClangDiagnostic("/usr/include/stdint.h:26:10: fatal error: 'bits/libc-header-start.h' file not found\n")
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
Error: Process completed with exit code 101.

Do I need the wooting sdk installed on the github actions machine to build binaries that use the wooting sdk? Or is this just some other issue when compiling the wooting sdk on Ubuntu

[quick bough]

I thought Cargo solved all the dependency management stuff? 🤣

but looks like it's trying to compile the C library there and failing due to some libc issues

in my experience, Rust building C stuff is pretty fickle... it tried using a Linux-only compiler on my Windows machine once because I apparently "installed it wrong" 😄

[quiet root]

would help to see the actions setup yaml

[karmic forum]

I figured it out its some weird issue where I the c dependency wouldn’t compile for windows from Ubuntu so I just changed the runner host to windows

[quick bough]

lmfao, yeah, you can't cross-compile like that

[sinful ermine]

Hey was wondering if the pcb files are opensource for any of the wooting keyboards

I'm looking to make like a generalized nxn keyboard using hall effect keyswitches, but I want to see how you guys deal with n-key rollover with these type of switches

So far I've found this article: https://telcontar.net/KBK/tech/Hall_effect#scanning

[sweet peak]

I believe they are running through multiplexers

[quiet root]

correct

[sinful ermine]

So it uses matrix scanning by iteration each time and for each hall sensor it is either 0 (not pressed) or there is some voltage (pressed, actuated at a certain percentage) from the sensor, which is then passed to the chip? Does someone have a clean pic of the PCB?

[placid ledge]

https://github.com/WootingKb/wooting-rgb-sdk/releases/tag/v1.6.4

[quiet root]

😮

signed DLLs

wait we didnt sign them before?

[quick bough]

Not really a point in doing so

[quiet root]

well it verifies you get an unmodified dll from us

[quick bough]

Maybe it's useful for like anti-virus heuristics

[placid ledge]

I signed them on request

👁️

[quick bough]

Now this is my kind of software

Perfectly harmless but tripping all the heuristics

[quiet root]

imo signing windows stuff is always helpful if you already have the certs for it

[quick bough]

Pay to win smh

[placid ledge]

No harm in it, but it's a PITA atm because our new signing key is EV and can only be used with the hardware usb 😭

[quick bough]

That's all the software certs now afaik

[placid ledge]

Yeah, june last year that changed it

Here I go setting up a custom CI runner 😢

[quick bough]

You'd need access to the physical machine to plug in the USB for that, right?

Sounds like a huge PITA lmfao

Not sure if it's worth the effort

Like no offense but the software has bigger problems than code tampering

[placid ledge]

Yeah, it's annoying, although it's not my machine and I'm connecting to it via parsec, so it's not too bad

ahaha, yeah, rgb sdk has plenty of issues, but I did it on the request of Codemasters 👀

I can't wait to have completely replaced the RGB SDK

then I don't have to feel the pain of entering that code base

[quiet root]

🦀

[quick bough]

For the next rewrite, use a mature language like C++ 😛

[quiet root]

itll be rust

[quick bough]

Yeah, I fear as much

[placid ledge]

It's much better for us to stick with a language we're already using than one that we aren't

[quiet root]

i personally dont even think c++ is better than rust necessarily

[placid ledge]

Even though we're using C for the firmware, it's a different beast than using C in the RGB SDK context

[quick bough]

Not too late to rewrite the analogue sdk in C++

[placid ledge]

Time to start the inverted "rewrite it in Rust" trend 😛

[quick bough]

but I guess now I already did a lot of effort to fix the Rust codebase

Just eventually you'll need to drop the Rust ABI anyway because it's not stable

[placid ledge]

Yeah, Rust ABI should be dropped, as it's a bit of a pain atm having to rely on fixed versioning. Either it needs to use the stable abi stuff like this: https://docs.rs/abi_stable/latest/abi_stable/ or just drop it in favour of more monolithic strat

Given that it's open source anyway, the need for plugins is less, and providing we keep the C plugin interface, I imagine most 3rd parties that want to have integration but not open source, would likely be using that anyway

[quick bough]

If the damn thing didn't crash trying to read device info from a C plugin :^)

[placid ledge]

The SDK is so coupled with our 'analog-plugin' anyway, that it doesn't really add much value to have them split. I mainly did it originally so that I had more passive testing of the interface as it would be constantly used

[placid ledge]

I just gotta get around to wrapping up that general cleanup of the c plugin interface

soonTM

[quick bough]

It's fine, I'm running custom compiled versions of the analogue sdk and plugin lol

Don't even need my C++ plugin anymore

welp, seems my custom compiled SDK doesn't have the C ABI fix, so MIDI still crashes on startup, oh well

[placid ledge]

😁 I've been using custom compiled versions so much that I hadn't noticed that the release version is near unusable on apple silicon macs 😢

[placid ledge]

rip

[quick bough]

Mac doesn't recognise Wooting keyboards, it asks me every time to set it up

Although it's pretty genious how they ask you to press the key to the right of lshift so they can tell you have an ANSI or ISO without asking you directly

[placid ledge]

Like the ANSI/ISO setup?

[quick bough]

Yeah

[placid ledge]

Oh, I haven't had that issue really

Although the odd time I have had it ask me again for one I did before

[quick bough]

Actually might have been due to KVM switch, not sure

I don't boot up a Mac device that often

Can't get used to the fact that the ctrl key doesn't do what it's supposed to

gotta press meta key instead

[placid ledge]

You mean Option/Cmd (Meta/Alt)? It is pretty annoying, but I use Mac most of the time, so I just swapped them in remap and have it normal in profile 1

I would imagine they'd use the device serial to track the setup, so maybe if you've changed gamepad modes or there's one firmware update where the formatting of the serial changed slightly

[quick bough]

I wouldn't think serial is that reliable since many (most?) HID devices don't report it (at least not in-spec)

[placid ledge]

The serial is what is used by WebHID to track if permission has been given or not

If it isn't present, it doesn't preserve the permissions

[quick bough]

That makes sense, but I mean Wooting devices are like a few of the HIDs I know that actually properly provide a serial over the proper HID interface for it

[placid ledge]

The serial isn't really related to HID, it's just one of the USB string descriptors

[quiet root]

i havent had this issue except for when macos upgrades it asks once

but switching with kvm or disconnecting otherwise my mac knows what i set

[quick bough]

Well, there's not too much interesting stuff plugged into my PC right now, but for example, my mouse is not reporting a serial

[quiet root]

i wouldnt be surprised if razer devices dont have a serial burned into their rom in general

[quick bough]

hmm

[quiet root]

it basically just adds an extra step to the process where they need to match the serial in rom to the sticker

[quick bough]

I mean, if an indie company like Wooting can do it...

[quick bough]

I should've added it to my own code back then haha

I guess now also works

[balmy iron]

I think RGB SDK should be dropped entirely in favor of supporting HID LampArray

[quick bough]

Is there already good existing libraries for HID LampArray tho?

[placid ledge]

We are planning on supporting the HID LampArray, but haven't had the time for it yet

[quick bough]

I am most curious what you do all day. Like, this is a 9-5 kinda job for you, right?

[balmy iron]

I don't think just yet, but I think it's worth supporting since that means in the future it'll "just work" in modern operating systems, without needing any special support in softwares

[placid ledge]

Yeah, it is 9-5 for me

I do everything lol

but less than everything now that we have more software devs

So I don't have to spend as much time on website/backend stuff these days

[quick bough]

I just mean because it seems like several months go by without any updates on the SDKs

I guess there's more closed-source stuff going on tho

[quiet root]

i think simon sinks most of his time into wootility/firmware

[quick bough]

That's fair

It is most unfortunate that analogue keyboards are not being supported natively in games, and I don't know what the limiting factor is

[quiet root]

the limiting factor is standardization and native OS interfaces

theres no real analog keyboard HID standard as far as i understand

[quick bough]

Wooting Analog SDK could be the standard with its plugins :^)

[quiet root]

well its sort of missing the 1 thing that all standards have... a good whitepaper/documentation

[karmic forum]

well... rust basically documents itself with rustdoc

[quiet root]

not the kind of documentation i mean. something like ana analog interface needs defined behaviours for scenarios. what data to return. in what format. and a lot more questions need to be answered. just read the USB documentation and you know what i mean. or any RFC really

[quick bough]

I guess one problem is that it's a bit of a PITA to use the Analog SDK in a standalone kind of environment.

Like, I know there's the wrapper that you're supposed to ship and then dynamically link against, but sometimes you just want a static link lib at most.

[quick bough]

I managed to get analogue input support into Teardown, and I didn't even have to write a single line of assembly :^)

[quick bough]

Put it on Github, if there is any interest: https://github.com/Sainan/AnalogSense/tree/senpai/steaminput

The code is very beautiful

[placid ledge]

You can static link the wrapper lib as well, I bundle in those artifacts as well IIRC

[quick bough]

This is still a bit confusing. On Windows, .lib is used for both static & dynamic link libraries. If the .lib is for static link, how is one to link against the DLL?

[placid ledge]

That lib is a staticlib artifact

https://github.com/WootingKb/wooting-analog-sdk/blob/develop/wooting-analog-wrapper/Cargo.toml#L16-L17

[quick bough]

I mean this one. This is useless without a respective .lib file.

[quiet root]

no?

[placid ledge]

[quiet root]

im confused how a dll is useless without a lib file

and dll literally means dynamic link library

[quick bough]

If I wanted the dynamic linker to link against this, I'd need to tell my linker to put it into the import table.

That's what the .lib is for.

Or in the case of a static library, the .lib is just a collection of compilation units that can be added to my DATA section and linked against statically.

[placid ledge]

How is the wrapper.dll useless then? The .lib file just makes using it simpler, but it doesn't stop you from using it

Manually linking to .dll's is not that weird

[quick bough]

If I wanted to manually link to a DLL, I'd just do this.

But then I also don't need the wrapper.dll

[placid ledge]

The rust artifacts give a .dll.lib file, should that be included in the tar then?

[quick bough]

Yes

[quick bough]

Huh, this is probably related to the analog plugin

Pretty consistent repro by just closing the game prematurely

[quick bough]

Aww man, 32-bit apps can't load 64-bit DLLs

No Wooting analog support for Portal 2 I guess

[quiet root]

build it as 32bit

[quick bough]

Build the Wooting Analog SDK and Wooting Analog Plugin as 32-bit?

[quiet root]

yeah should be able to do that

i wouldnt see what would stop it tbh

dont recall anything that absolutely needs to be 64bit in there

[quick bough]

And then I tell the users just to install the Rust toolchain for 32-bit Windows, compile the whole ecosystem from scratch, add it to their path (with conflicting names to the 64-bit binaries?), then finally they can have a benefit they won't even notice? 😄

[quiet root]

provide the dlls

[quick bough]

That goes against the point of the Wooting Analog SDK in my opinion

[quiet root]

it does yes but theres no other solution for windows

the same would go if it was a 64bit game trying to load a 32bit dll

[quick bough]

Yeah, I can understand it, it's a shitty problem, especially with plugins

Easy fix, just move the plugin ecosystem to something more portable like Lua then you can easily load the same plugins on both 32-bit and 64-bit builds

[quick bough]

Beautiful

FWIW, it seems to be this wlock call

Possibly not your fault, probably just a certified Rust ecosystem moment

[karmic forum]

tried it in a few games

works:
rainworld
cyberpunk

does not work:
counter strike 2
lethal company

[quick bough]

Uhh, you tried my SteamInput approach?

I would reckon it would get you VAC banned in CS lol

[karmic forum]

now that I think of it competitve games are prob the not of best ideas

i mean it crashes before the game window even opens

[quick bough]

It is somewhat unfortunate I own cyberpunk on GOG and not Steam

[karmic forum]

:/

[grand flax]

Might just be me using the uwu as a media macropad but here's a volume vis that only appears when u change your volume!

[quick bough]

Also, what do you mean by 'works'? Like, it 'works' with Cyberpunk, but it doesn't even seem to use SteamInput at all.

Would certainly be nice to have analogue input in this game because of driving vehicles, but seems like very few games implement support Steam Input natively

[quiet root]

so just map controller stuff and use it

it works

[quick bough]

My approach for GTA V was quite elegant, since their input system is analogue to begin with, I just had to write some assembly on the part where they read keyboard keys and give it a value between 0.0 and 1.0 instead of 0.0 or 1.0.

For other games, I think it can work, if you can tell apart "on foot" and "in vehicle" — which is where Steam Input is really useful because the game will inform Steam Input which "context" is active.

but the problem with mapping controller stuff is that if you want 'W' to be "move forward on foot" and "throttle in vehicle" you have a problem because one is LSTICK UP, and the other is RT. 😄

It's a nice idea, but for me, it's no good unless games natively support it (or I can hack that support into the games)

I guess I could try the most basic approach: Prodding around with cheat engine, until I find some magic number that indicates which input context is active, then somehow inform the keyboard that it should format inputs in a specific way... but that would be very hardware-specific.

[karmic forum]

Is that so, sorry I might not have known exactly what the purpose of this was then. I thought this was supposed to allow you to use analog keyboards in hames that did not support them.

What i mean by it works is I put the dll in the respective place and renamed the old one and launched the game. I was able to walk at different speeds depending on how much I press the key.

[quick bough]

Yeah, I tried that, and that did not happen

and also don't see how that would happen because the game doesn't use Steam Input

you kept your keyboard in the digital configuration, yeah?

[karmic forum]

I used the analog profile for the game

I think I understand now so basically it’s supposed to work as analog movement when your interacting with the hame but then type as normal when your not playing

Sorry for misunderstanding the use of it

[quick bough]

It does a couple of hooks, so it reads your analogue inputs correctly via Steam Input, and doesn't interpret the digital keyboard inputs anymore.

Only for the relevant keys and only for the game tho

Unfortunately not that many games use Steam Input, and some of those (e.g. Portal 2) are 32-bit

so clearly this approach is already DOA it seems

but at least it works okayish for Teardown

[quick bough]

On that note, is there a proper "protocol documentation" for the Wootility—Firmware traffic? Obviously, the there's the WootDev stuff, and I've already somewhat RE'd the keyboard mappings, but would be cool to have information regarding the gamepad mappings and settings (mainly to disable keyboard inputs on buttons with gamepad keys mapped on them.)

[quiet root]

set the setting for that in wootility?

[quick bough]

I know, but I would like everything to "just work", so ideally I talk to the firmware directly and manage this myself.

I guess for a most basic proof-of-concept, I can just tell the firmware to switch to a different profile depending on game state

[quiet root]

well we have no intention to document it tbh. wootility doesnt hide anything and exposes all possible things. if someone still feels the need to make a custom configurator or such then right now you will have to reverse engineer this from how the current profiles work

[quick bough]

Yeah, but then I run the risk of writing data that causes glitches in the Wootility

[quiet root]

highly doubt it

[quick bough]

😄

Broke my FN 2 & 3 layers there

[quiet root]

and wootility just discarded them as broken

dont see any glitch there

[quick bough]

Well, ideally Wootility would show those layers still?

[quiet root]

why would you try to interpret malformed data

[quick bough]

You don't, but you can give the user the option to reflash a disk with corrupt data, no?

In this case, FN 2 & FN 3 layers still exist in the keyboard flash memory somewhere, and I might still want to use them

If the data on them is garbage, just discard that data, and let me overwrite it

but, yes, none of this is an issue if the user doesn't write garbage data there to begin with, which is an unfortunate side-effect of me messing with stuff I only partially understand

and not being helped by usbpcap not working for me lol

[quiet root]

the only reason itll ever be corrupted is because the entire profile got corrupted due to whatever

which has happened in the past but also means most of the profile is unusable

[quick bough]

How is the test-plugin meant to be used?

The virtual-control thing crashes when I try to start it

If I compile the test-plugin myself, initing the SDK crashes my program

Fully recompiled everything and still crashes on init, so at least I know it's probably not an ABI issue

but also like I thought Rust wasn't supposed to do that

[quick bough]

Seems to just be this problem again... wtf.

Managed to narrow it down, seems to be a bug with the shared_memory crate

Well, that crate looks very different now on the latest versions, it seems the author realised it was trash and removed like 99% of the functionality lmfao

[quick bough]

Managed to get something working for Cyberpunk 2077, now I guess just to make an automatic profile switcher based on this lol

[quick bough]

Do I understand correctly that by default Profile 3 (Analog Profile 2) has this mapping?

and default Profile 4 (Analog Profile 3) has this mapping?

I kina moved stuff around in my configuration so I'm not sure what the "factory state" is

Does seem so, if this is to be trusted

[quick bough]

And there we have it: https://github.com/Sainan/AnalogSense/tree/senpai/autoswitch

Now just to add like 10 billion game executables to the list lol

[faint slate]

The translation I sent you is reflected! Thank you always!

[quiet root]

this is for community projects not official wooting dev stuff

[floral crane]

https://github.com/ShayBox/Wooting-Profile-Switcher
There's also the old C version
https://github.com/ShayBox/Wooting-Profile-Switcher/tree/original

[quick bough]

Hmm, yeah, that is close to what I'm trying to do there, although just "active window" is really not enough for games. You have to consider "in vehicle" and, honestly, even that isn't enough. Games have text input sometimes, too, etc. It's hard to make it work right externally.

I've thought about maybe adding Lua to it and allowing the state detection to be scripted, but the core problem would still be that without making it "just work" for a good sampling of games, no one would be interested in it. And even then, I'm not so sure.

I've ran into a bug where Warframe would get confused with the digital and analogue input mixing which just adds further woes to my plans.

But I guess really the biggest benefit is when it comes to handling vehicles, so games like Warframe can safely be ignored (except they do have Railjack, even if no one plays it.)

[strong siren]

i agree but adding that functionality to every game is not feasible

active window gets you most of the way there and at least it works the same for all the games :p

[quiet root]

isnt the main issue that our keyboard is somewhat special in how software can interact with it? xbxo elite series 2 has multiple controller profile but switching is done on the controller not doable via software. same for most keyboards with profiles

[quick bough]

My goal is to "inject" native analogue support into games. If I am suddenly faced with a text input and now have to manually switch profiles, I consider that a failure. It could be feasable to add manual patches like that for games where it's needed.

Esp. in open-world games the failing of just a single profile is apparent by how [W] would have to be both LSTICK UP and RT for on-foot and in-vehicle contexts. I've seen some people do double-bind the W key to that, but you end up having unwanted inputs in the different contexts.

[floral crane]

I just press A1-A3,D1 on my keyboard to switch profiles, I don't know about ARM boards but mine only has the 3 analog profiles and 1 digital, the rest aren't stored on the keyboard and very difficult to swap since they're stored in wootility local storage not on the device, so I'm limited to a typing, driving, binding of isaac, and misc profiles.

[quiet root]

same for arm

[sinful ermine]

Does anyone have any minimal working c/c++ code that can literally just read the keypresses + depression?

[quick bough]

#include <iostream>
#include <Windows.h>

using WootingAnalogResult = int;
using wooting_analog_initialise_t = WootingAnalogResult(*)();
using wooting_analog_uninitialise_t = WootingAnalogResult(*)();
using wooting_analog_read_full_buffer_t = int(*)(unsigned short* code_buffer, float* analog_buffer, unsigned int len);

int main()
{
    SetEnvironmentVariableA("RUST_LOG", "off");
    auto sdk = LoadLibraryA("wooting_analog_sdk");
    ((wooting_analog_initialise_t)GetProcAddress(sdk, "wooting_analog_initialise"))();
    auto read_full_buffer = (wooting_analog_read_full_buffer_t)GetProcAddress(sdk, "wooting_analog_read_full_buffer");
    while (true)
    {
        unsigned short code_buffer[16];
        float analog_buffer[16];
        const int num = read_full_buffer(code_buffer, analog_buffer, 16);
        if (num >= 0 && num < 16)
        {
            std::cout << "\x1B[2J";
            for (int i = 0; i != num; ++i)
            {
                std::cout << code_buffer[i] << ": " << analog_buffer << "\n";
            }
        }
    }
}

[sinful ermine]

Sweet, I guess this uses the wooting sdk? I'm also on linux, what parts are windows only here?

[quick bough]

This assumes the SDK is installed, otherwise LoadLibraryA/dlopen would return nullptr.

For UNIX:

• #include <Windows.h> -> #include <dlfcn.h>
• LoadLibraryA(x) -> dlopen(x, RTLD_LAZY)
• GetProcAddress(mod, sym) -> dlsym(mod, sym)

Unsure about SetEnvironmentVariableA, but don't need that if you don't mind the SDK writing to your console.

[balmy iron]

setenv

[severe flame]

hi guys, im not knowledgeable on stuff like this but I want to ask if there is a way to, like the image, instead of disabling gamepad mode, disabling keyboard mode and make the keyboard work only as a controller

[quick bough]

You can just remove all the keyboard mappings?

Or use these options under Gamepad Mapping

[sinful ermine]

Thank you so much, going to try this later today

[karmic forum]

I just realised I could prob make wallpaper engine wallpapers that run apps that change rgb lighting

[sinful ermine]

So I managed to get this working but read_full_buffer is always return -2000, any hint?

I think this has to do with this plugin system that I have no understanding of

Alright I figured it out after messing around with it for a while

I made a PR to the readme for the analog sdk to make the linux instructions easier to read, hopefully that gets merged in

[quick bough]

Didn't the wooting analog plugin get installed with your installation of the SDK? That's at least how it is on Windows.

[orchid falcon]

No on Linux you need to manualy install it

[minor wing]

isnt there a channel for wootomation anymore? was wonderign why the button" set to default (duration) is not in the keystroke edit menu and only in the delay element field.

[quiet root]

#💻│wootomation

[minor wing]

tnx, bit weird how discord hides these.. or, in other words.. i have been looking for it but "show all channels" is also a kind of hidden option.. not the ux award. :/

[quick bough]

smh, how dare they add backend validation

[quiet root]

yeah we did quite a lot of internal testing including botting it

[quick bough]

I'm just happy my little WebSocket client works, it almost fits in a screenshot.

[quick bough]

It's interesting, it seems people basically stopped using the emoji feature now, so I can have full reign over it. 😈

[quiet root]

gl

[quick bough]

No luck needed, it's just pretty unexciting unfortunately.

Also unsure about the anti-botting measures tbh

Casually holding 100 connections

but ¯_(ツ)_/¯

it's a nice gimmick 😄

Maybe you need a bot to periodically put an emoji to keep people engaged 😉

[sinful ermine]

what is backend validation?

[quick bough]

well, it involves a peg or—

I mean just validation on the backend server

so you can't do shit like send an arbitrary emoji

when there's a limited selection of emoji on the frontend UI

[sinful ermine]

Ah ok gotcha

[sinful ermine]

what are you building anways

[quick bough]

Nothing in particular, just saw that funny feature and span up the script to connect to the WS server in like 5 minutes.

[quiet root]

what anti botting measure

[quick bough]

but idk what your botting tests were

[quiet root]

i never said anti botting

we just load tested it with 10k connections each

[quick bough]

ah, makes sense

[quiet root]

and then spam the server with commands

just wanted to make sure any amount is sort of handled ok

[quick bough]

Could it handle up to 65,535 connections? 😛

Actually might be running out of ports a bit sooner than that

[quiet root]

yes

there is a hard port limit ofc

[sweet peak]

Psk just use multiple ips

[quick bough]

That would be overengineering it

[torn willow]

Any one knows how to log input from a mouse?
( I have a mic that need some logtiech input for soundboard but i rather keep my wooting gear )

[quick bough]

What are you trying to achieve exactly?

[static sparrow]

Anyone knows why when I open the software / web , its like crashing few times until it detects the keyboard ?

[grand flax]

U don't have wootverlay running right?

[static sparrow]

How do I check for it ?

[static sparrow]

If its a software so no I dont have it

[grand flax]

Oh then nope haha dw

[balmy iron]

Running RGB softwares? SignalRGB is particularly notorious for causing problems

[raven sequoia]

I do not understand the wooting_analog_plugin.dll
Here is what I want to do: I want to use autohotkey to DllCall the wooting_analog_plugin.dll to get analog values from keys. But I don’t know how to ask the dll. And I honestly don't understand the SDK documentation one bit.

[quick bough]

You don't use the analog plugin directly. You use the SDK.

[raven sequoia]

Same difference?
On the AutoHotKey side looks kinda like this:
Result := DllCall("[wooting_analog_plugin.dll\]Function" [, Type1, Arg1, Type2, Arg2, "Cdecl ReturnType"])

[quick bough]

Very much not same difference, because there's no way in hell you'll get that working 😄

[quick bough]

Here's a very low-level approach to using the SDK

[raven sequoia]

Why? Should work with any other DLL. https://www.autohotkey.com/docs/v1/lib/DllCall.htm

[quiet root]

the idea is that you dont bundle the dll but the user installs it at whatever version is newest

[quick bough]

The reason is that the wooting analog plugin is written in Rust, which has an unstable ABI, far away from what you would normally get with the C ABI of Win32 DLLs.

[raven sequoia]

Who said something about bundling?

[quick bough]

Even if it were written in C++, which does have a stable ABI, you still have the issue of complex data structures like hashmaps, which you can't possibly hope to interact with.

Hence, the wooting analog SDK (as well as other SDKs) use the stable C ABI with stable APIs and trivial types, so you can easily interop with them.

You just gotta go through the front entrance. 🙂

[raven sequoia]

Oooook? (I'm so out of loop that I had to ask Bing copilot what an ABI is.) A system search revealed to me that I do, in fact, also have a wooting_analog_sdk.dll .
If you excuse the sidequestion to the developers: Why does the wooting_analog_plugin.dll exists in a form that sucks donkeyballs?
Back to topic: Sooo .. I change my example to Result := DllCall("[wooting_analog_sdk.dll\]Function" [, Type1, Arg1, Type2, Arg2, "Cdecl ReturnType"]) And now?

[quick bough]

The wooting_analog_plugin is an SDK plugin that makes the SDK able to read from Wooting keyboards.

[quick bough]

This should help you. Just use the appropriate functions, e.g. DllCall instead of GetProcAddress.

It's not a 1:1 translation from C/C++ to AHK, but yeah

Also idk if you can pass pointers for the arrays. If not, use a more trivial SDK function to query key by key. See the documentation for that. 🙂

[raven sequoia]

Yeah … You might as well have posted that in Swahili written in Chinese characters. I don't do C. Or C++. Or C#. Sometimes I can kinda read it and guess what's going on. Here I can't.

[quick bough]

スキルイッス

Just ask your AI 😉

[raven sequoia]

That I did first. It was a knowable about that topic as I was. And your intro text did indeed was to me the same as your C code. Which confirms: I don't do C. Me stupid, me stopped at C-64 basic. Was computer we had in cave.

[quick bough]

https://chat.openai.com/share/f4246a74-9241-4472-a0ef-2804b83869cd

No guarantees, but looks alright to me at first glance 😄

Here's a link to the docs, btw: https://github.com/WootingKb/wooting-analog-sdk/blob/develop/SDK_USAGE.md

[raven sequoia]

Ah! Thanks! I used bing as it's free. And most often the same or better. Not in this case. And the right question would have helped, too.
And I read through all SDK documentation. I only know it was in Swahili written in Chinese characters

[sinful ermine]

What is the update rate of "wooting_analog_read_full_buffer" ? I'm writing a c++ program which samples the key's depression but my programs is cycling faster than said function, causing many repeated data points:

[quick bough]

I don't think you will get much better by using the Analog SDK. If you really want, you can poll the keyboard yourself (HID usage page 0xFF54). The input report format has a u16 scancode, which is as per USB HID specification plus some OEM values, then a u8 analogue value.

[quiet root]

in general reading the analog values wont get much faster

mainly due to it taking time for the MCU to interrupt normal event loop stuff to prepare the reports when requested

same for the RGB interface. it also has a speed limit so to say

[quick bough]

Yeah, I don't mean for it to be faster, but for it to only register on updates.

[sinful ermine]

I see, so does anyone know like what the hardware's update rate is for analog output? I'm going to see if I get duplicate values when I use the same update rate specified by wooting.

[quiet root]

@placid ledge would know best what the approx rate for the analog interface is

[placid ledge]

polling rate matches keyboard polling. So 1kHz for all boards, 8kHz for 80HE

Update rate is roughly specified in the tachyon mode description, as that is an estimate of the scan rate

updates are deduplicated if they are the same

So for 60HE tachyon mode, theoretical max update rate is 1kHz

[quiet root]

wait so you can get a full analog buffer every 1ms?

[placid ledge]

ye, up to 16 keys

[quick bough]

Given that the keyboard itself shouldn't be reporting duplicates, maybe you can just deduplicate yourself to discard instances of the SDK giving you old data.

Also, do we know the PID for the 80HE yet? 0x1600?

[placid ledge]

0x1400

[quick bough]

Hmm, was it in dev before UwU 👀

I'm guessing it will be ARM-based (protocol v2), and have 18 rows for RGB? Based on the squished top row anyway.

[gleaming silo]

yes

afaik they worked on it, or at least started planning it, years ago

[quick bough]

the only thing I'd really like a Wooting employee to tell me is why they don't make a "Wooting One HE" or similar

instead we get the goofy-ass 80HE

but I guess I don't have to agree with the decisions either 😄

[gleaming silo]

wdym by "Wooting one he"

There is a wooting one, it's just an old version of the wooting keebs

[quick bough]

I mean them just selling a normal TKL

as the Wooting One is discontinued afaik

Like, it's not something I'm personally affected by because I like my numpad but it just seems so weird to me to ignore such a big market/demand?

but you know what, I am buying the silly 80HE because it has a Japanese layout, and to support this poor company 😛

[vestal bridge]

is the new rappy snappy coming to 60 too?

[quick bough]

Wait and see™

[paper crow]

Yes

[fresh orbit]

What does it do

[vestal bridge]

for movement keys it activates the one thats pressed the most(i assume mainly for counter strafing)

"Rappy Snappy monitors at least 2 selected keys and activates the key pressed the furthest. When combined with Rapid Trigger, it'll compare the keys only when in an active state. Allowing pre-pressing and faster activation on opposite key release. When both are active at the same depth, it'll resort to your selected SOCD resolution. This enhances your (counter) strafing, bunny hopping, and block/parry/combo timing in various games."

their def on the website

https://wooting-web-files.ams3.cdn.digitaloceanspaces.com/public/store/80he_media/80HERappySnappy.mp4

visual^

[quick bough]

I would call that "radio buttons" haha

[vestal bridge]

i like rappy snappy lmao

[quick bough]

I fail to see how those words relate to its functionality, but ¯_(ツ)_/¯

[vestal bridge]

rappy snap to the other key when pressed more

idk

[quiet root]

it rapidly snaps to the other key = rappy snappy

[dusk helm]

I have a question. Is the feature Rapid Snappy or Rapid Trigger or the Adjustable Actuation Point built with the analog SDK by wooting that is open-sourced? So can I also build like a plugin that has different features

[quiet root]

its a firmware feature

[dusk helm]

Then my question becomes what are the limitations and what I can do with the analog sdk also thank you for the help 😁

[quiet root]

limitations of what. the analog sdk can read analog values from all keys and you can then implement whatever you want in software

[dusk helm]

Ahh ok like the wootingpiano project and I thought there could be some limitations of the sdk but when there is none is even better

[quiet root]

we give full access same for the rgb sdk. we dont want unnecessary limitations

[dusk helm]

Really cool that’s why I love wooting

[floral crane]

Is there a new keyboard I don't know about.

[quiet root]

80he

[floral crane]

Has the RGB sdk and Linux udev rules been updated for it, I guess it's time to update wps and aur packages.

[placid ledge]

We use generic udev rules now for our vendor id, so they don't need updated

Analog/RGB SDK will need updated, but that's a different beast

[floral crane]

Rust RGB sdk when :(.

Bigger beast.

[placid ledge]

rust gang

🦀

[floral crane]

Crab gang 🦀.

[quiet root]

whats this rust

oh the facepunch studios game

[quick bough]

It's C ABI, just link against the DLL/SO?

[floral crane]

I already updated the rust rgb sdk bindings, could also do that but it requires the dll be with the binary

[quick bough]

or statically link. there's one benefit of C over C++, no need to link in the "C++ runtime environment"

which is quite a PITA with Rust

disappointed about that because without any sort of C++ compat, it's literally useless for real-world projects

[floral crane]

there's bindgen for c and autocxx for c++

there's always the native unsafe way but it's not as good as the community built tool bindgen and autocxx which provide a safe interface with macros

[quick bough]

well, I'm talking about static linking, not dynamic linking

I've tried pretty hard to get Rust and C++ code to link into the same object and it would just keep having errors due to the runtime stuff

[floral crane]

if you make a bindgen crate it'll statically link, that's why I use the rgb sdk bindings, but you can staticaly link with the unsafe way it's just not easy

[quick bough]

but I reckon the "best" way to ship RGB SDK with your app is to bundle the DLL/SO

so newer keyboards can be supported by the user replacing the DLL/SO if they so desire

alternatively, if hard-coding the devices (aka statically linking the SDK) is the game, then "direct comms via HID" is the name 😉

[floral crane]

it would be nice to have a native rust hid rgb library, but that's up to someone else to make, It's easier to use the rgb sdk and not have to maintain another library

[quick bough]

I've reinvented the entire RGB SDK wheel in C++

[floral crane]

if I understood how it all worked like simon I probably would have made one by now, but it would take learning the hid interface for me

[quick bough]

It's very fast to write code in C++, after all 😄

Most of the code is just this haha

[floral crane]

It would be nice to dynamically link so you can change the dll 🤔 but it's too late now, I can't compile my project because of people not pinning their dependencies and now old pinned versions have updated dependencies with breaking changes

I either have to wait for tauri-egui to update to the latest tauri v2 beta and egui 0.26 or switch to a webkit ui and write css

🤢

[quick bough]

Why does any of that matter for an RGB SDK?

[floral crane]

I'm talking about my program not the rgb sdk

[quick bough]

I still don't understand how your program could suddenly break

Did you commit your old lockfile?

[floral crane]

yeah but I'm using tauri-egui which hasn't updated in 8-12 months and uses an early version of tauri v2 alpha and lots of the dependencies of both projects had lose dependency versions and have sub-dependencies that have updated and broke things

[quick bough]

yeah, but, a lockfile still contains all your package versions, including how to install them

so if you just roll back to your old lockfile

then you should be able to install and build from that

[floral crane]

doesn't work, still errors in dependencies

[quick bough]

I never thought I'd say it, but somehow nodejs seems better than Rust

and that's javascript...

[floral crane]

I think it's a cargo issue not crates.io issue, probably with a git dependency

[quick bough]

Yeah, I guess it's also possible that someone was not being very disciplined

[floral crane]

maybe I can use the wootomation stylesheet and switch to native tauri instead of egui

[quick bough]

We have our own little package management and I've had to remove some packages because some maintainers could not manage the simple task of "1 steady url per version"

Then again, a lot of devs just never bother getting any sort of git discipline

it seems they struggle with even just using git commit

[floral crane]

I'm not great with git, I force push more than I should but it's my repo and the only person contributing

Oh hey there's a new template for tauri and egui 🤔 maybe this will work instead of tauri-egui https://github.com/noxware/egui-tauri-template

[quick bough]

Force push is fine, as long as you don't force-push any tags 😛

[floral crane]

well It's usually I make a release and realize there's a bug I didn't find or won't compile and force push and delete/re-release the version

[quick bough]

yeah, that's bad

[floral crane]

lol

[quick bough]

a version number should uniquely identify, including all bugs and quirks

even devs at big tech companies like facebook don't seem to understand that a bugfix can be a compatibility break

linus torvalds is based for understanding how people actually use software

you just don't fix a bug when people are relying on it

[floral crane]

fix it and don't tell anyone like windows

wesmart

[quick bough]

I'm kinda guilty of that myself, sometimes I think a bugfix is so trivial it's not even worth mentioning

then it ends up breaking something 2 months down the line

[jagged echo]

I made a small script, which automates Wootility installation on Steam Deck and most Linux distros
https://github.com/Calslock/wootinstaller

[floral crane]

So 60HE+ has more serial number parts

zt, mt, Xt, and Yt are new I believe

[floral crane]

You had to put the new optional part in the middle instead of the end 🥲
If it wasn't already impossible to parse a serial number it is now, good thing I only need to convert to it not from it

[floral crane]

Anyone with a serial number containing letters T and/or S willing to run a debug build of my program so I can figure out the order of bytes in the new serial number? I don't have a 60HE+/80HE to test it

I need the Serial Number Buffer line from the logs, you have to run it in a terminal https://gofile.io/d/j2vA8K

[quiet root]

no one has an 80he to test lol

@placid ledge can maybe quickly resolve this

[placid ledge]

What are you parsing the serial number for?

[quiet root]

also not sure why the profile switcher needs this

[floral crane]

I don't parse the serial number I construct the serial number from the GetSerial command because Wootility uses the serial number as the profile key iirc

[quiet root]

you mean for inactive profiles?

[floral crane]

Active profiles

I get a list of devices from Wootility so you can configure unplugged devices and I have active profile names

new keyboards have new serial number parts, but I don't know what order the 3 new bytes are in, just that they're probably index 16 17 and 18

[placid ledge]

I don't understand why the serial plays into this code

We only really use the device IDs that we generate

[floral crane]

I also have a format for device id, I probably needed that for the Wootility config, but I use serial number in my config as a device key and in the UI if you have two identical model name keyboards, device ID doesn't have the production stage so it's more likely to not be unique

[placid ledge]

The DeviceID we use is intended to be unique, otherwise Wootility would break pretty aggressively in the case of a conflict

[quiet root]

i mean it would prob still be useful to display the serial like wootility does for disconnected devices cause otherwise the switcher is filled with 5 uwus if you have 5

unless the device id is also somehow easily related to the serial for an end user

[floral crane]

I haven't looked to see if device id has changed to include the 3 new bytes but it appeared you could get conflicts with device id without the stage number, every other bit I could imagine would be the same on a large run the same device

[placid ledge]

Ye, but you don't need to parse the serial number to display it. We provide the formatted serial on USB

[quiet root]

oh well

[floral crane]

wym?

This is the only way I know of to get the serial number

[placid ledge]

USB devices provide strings. Commonly manufacturer, product and serial number

Hidapi has a function for reading the serial number

And that will be the formatted serial number

The RGB SDK doesn't directly expose this, but going via that strategy is going to be a lot simpler than dealing with parsing and formatting yourself

On the side of the DeviceID Vs serial, even if you think that the id could get conflicts. It doesn't really matter to build another layer on it, cus if it conflicts you'd be screwed anyway

[floral crane]

I don't think I can do that, because the rgb sdk only lets me select a device using device index I have to loop through every device and access its serial number to make it unique, but if I use hidapi I'll be able to get every connected keyboards serial number but I won't know which device index it is to the rgb sdk at that time

[placid ledge]

In what world are you using hidapi separately? It prob wouldn't work consistently anyway due to exclusive locks. If you were to make a patch to the RGB SDK which exposes a function to grab the serial via hidapi on the selected device. Or even add it to the device meta struct and init it on device connection

[floral crane]

I thought that's what you were saying to do, use hidapi to get the serial numbers of connected keyboards

[placid ledge]

Use hidapi inside the RGB SDK, it's using hidapi already for the device connection

But then you're using the serial to generate the device id currently? So you'd still end up needing the parsed version in some form?

[floral crane]

I don't know if I can use the hidapi from rgb sdk, unless you mean wooting_usb_send_feature_with_response

I would still need to parse it for device id, I already wrote the code to convert from my Device struct to the updated serial number, I just need to parse the 3 new bytes and update the device id format if it's changed

[placid ledge]

I was saying that you would need to edit the RGB SDK itself to expose it

But ye, you need it parsed for the ID, which is tricky

But it's also a lot simpler if you don't have to deal with the formatting of the serial and only do the fixed id generation. Then just use the formatted serial from usb for display purposes

Also, assuming you're gonna be keeping the parsed serial, I'd recommend splitting it into its own struct. That Device struct of yours is quite beefy

[floral crane]

https://github.com/ShayBox/Wooting-Profile-Switcher/blob/master/src/lib.rs#L25-L87

I could do that but it would be more work than updating the existing code, and I don't use C, a change to the rgb sdk like that would have have to be backwards compatible

[placid ledge]

?

[placid ledge]

Fair, it's defo not the most straightforward path

[floral crane]

Maybe for you, but I don't know C, I can't really patch the rgb sdk, it's more straight forward for me to parse 3 extra bytes from an rgb sdk response

If the rgb sdk had a wooting_usb_get_serial_number or the usb meta had it I would use it instead of this

[placid ledge]

it's defo not

[floral crane]

was device id changed? I don't have a new board with the extra bytes but it doesn't look like it increased in length

[placid ledge]

Aside, we are working on our own app profile switching in case you weren't aware.

[placid ledge]

I do remember changing it at some point, but I'd need to check on my pc

[floral crane]

is that built into wootomation or a new app

and will it let you switch to inactive profiles?

[placid ledge]

Not Wootomation but also not really a new app either

[placid ledge]

That is the main focus

[floral crane]

ore_pog lets goo

thats the one thing I can't really do in my program

the command to swap an active profile would have been insane to construct

[placid ledge]

Ye, it's a significantly more involved process

Anyways, I gotta sleep. Good night

[floral crane]

Good night

[barren lava]

i guess this is a good moment to say i have absolutely no clue whats going on here but this conversation has been very interesting to spectate.

[floral crane]

code

[barren lava]

i got that much, but me trying to understand it is like trying to understand german as an american. i can notice most of the characters but the words they make mean absolutely nothing to me. but its interesting nonetheless. maybe someday ill learn.

[floral crane]

ChatGPT explains aliens

[floral crane]

now I know why, GetSerial doesn't return the 3 new bytes 🥲 the only option is to modify the rgb sdk to get the serial number with hidapi and parse it into the device id

[floral crane]

Nevermind I figured it out, I needed the first param to be 2 instead of 0 for the new bytes, but the params are in reverse order in the rgb sdk so it's last.

[kindred skiff]

<@&490097707487330305>

[subtle lark]

Mansen was notifying us of a bot/spam.
It has been removed.

[quick bough]

<@&490097707487330305>

[neon abyss]

..,JKMM64Y122334567890----][['

[quiet root]

yes

[quick bough]

<@&490097707487330305>

Surely you can automate this, right?

[subtle lark]

?

[quick bough]

The deleting of the spam bots

It's pretty obvious: They try pinging @everyone, usually have some discord.gg link, and send their message in multiple channels.

[subtle lark]

Oh, when we ban them, we get an option to remove their messages for (hours/days/week/forever), so we can just select that.

Though sometimes the auto cleanup takes a while.

[quick bough]

Yeah, but you still need to manually click on "Ban"

[floral crane]

I can't seem to get the RGB SDK to detect my keyboard on Linux, even with the input group or sudo. The only thing I can think of is that HIDAPI needs to be updated because it's a shared library on Linux and is 2 years old.

The HIDAPI version used by RGB SDK is 0.12 and 0.14 is out now

They also switched from make to cmake in 0.13

[floral crane]

That's not it, I tried an Ubuntu 22.04 KVM but still didn't detect my keyboard
EDIT: Seems to be an issue with my bindgen, using it directly with C works

[quick bough]

wasn't this issue already reported to you before?

[floral crane]

yes but I didn't have linux to debug it

[quiet root]

smh windows users

[floral crane]

I can finally run wayland and use linux again

with VR! I get better frames on linux in everything I test too which is crazy.

It was a simple fix, the old rgb bindgen had a 4 way switch for hidapi-libusb, hidapi-hidraw, libusb, and libudev. only hidapi-hidraw works because the rgb sdk switched to hidapi-hidraw instead of libusb awhile back.

[quick bough]

Just set up a Linux VM? I personally have Ubuntu and EndeavourOS VMs.

WSL (when it does work) is also a decent environment to test if your software works on Linux.

I say that because for ARM computers it's a bit hard to come by a VM, so WSL is a good option there.

[thick ferry]

I was wondering if someone knows a workaround for this, lets say in my layer two I want " on a key but the only option atm is the ' same for brackets [ vs {. is there a shift modifier setting i'm not aware of to trigger it and get it to work?

[paper crow]

This is an operating system thing that your keyboard (any keyboard) can't change. However, you can use DKS as a hacky-workaround to make it possible

[quick bough]

That's typical American layout

Maybe switch to a European layout in your operating system if that's more comfortable for you

[thick ferry]

Thanks for letting me know about the workaround. came from a QMK split keyboard background but got a wooting for gaming and love it. was trying to make a profile for quick coding when needed instead of swapping keyboards out

[thick ferry]

That's a good idea, I'll give it a try

[grand flax]

Another idea that might work (but haven't tried) is setting the layer 2 key to unused fn keys (fn13 to fn22) and then using autohotkey or similar to make that output your character

[echo flame]

today my wooting 60he+ arrived and i wondered how i make screesnhots and stuff, on my old keyboard i pressed fn+ the key but now its not working

i have screenshot on alt + pressure

[quick bough]

Not exactly the channel for this, but check the fn layer in wootility

[echo flame]

sorry

[quick bough]

if printscreen is not bound, add it manually

[echo flame]

ohh thanks

[open jolt]

Is it possible to change the key assignments on the WOOTING keyboard through software control, hardware control, or both?

[rich tulip]

Yes using wootility

[placid solstice]

hello my wooting doesn't stop working when i keep my keycaps pressed

[echo flame]

where is the insert key?

[jagged echo]

You have to bind it by yourself in Wootility
Next time, please ask such questions in #💬│general

[quick bough]

there's an insert key on my Wooting Two

[echo flame]

ty kochanie

[young solar]

Hello!! I am very interested in making keyboards with rapid trigger and i wanted any information anyone would be willing to give me on developing the pcb, software, etc. Anything is appreciated, thank you!

[karmic forum]

I would not really say this is the place for that, but all of wooting's features derive from hall effect sensors which essentially detect magnetic forces present in the switches.

Try looking at a different discord community for things relating to maybe something like KiCad which is a popular pcb design software.

[quick bough]

I don't know who it was but someone reported to me that the Cyberpunk 2077 "in vehicle" detection in my auto-switcher had some bugs like ages ago. I finally got around to properly implementing this. And look at how simple it is!

[quick bough]

Actually, this I'm much more happy with now: https://github.com/Sainan/AnalogSense

It hooks into the game's input stuffs to feed it actual analogue information

No jank, just the way I like it

And the sad reality is: I still drive a lot better with a controller, haha.

[rich hamlet]

does anyone know how to set the color brightness with the wooting rgb sdk?

[floral crane]

Is there a non-s3 link for Wootility? it always takes 30 minutes to download from s3.

[quiet root]

no

and we did have a few reports of download speed issues but i mean literally only a few

[sweet peak]

half the internet is S3, you cant access half the internet?

[stone horizon]

No idea what channel is appropriate for this, but I made a custom midi keyboard with wooting switches :) it's got plenty of buttons to let me play microtonal scales

[rugged wind]

I was bored and wrote code to render to a texture using arbitrary shaders and then projecting that onto the keyboard

23x6 is not exactly a great resolution though, I render to a bigger texture then scale that down somewhat smoothly

anyway custom rainbowy effects and stuff should be nice, i just need to write some shaders now

[karmic forum]

im not sure where to post abt this but all of the rust libs for the rgb control seem to break in the 2.8.x update bc without changing any code in my project revering my kb back to 2.7.2 seemed to fix my projects

[quick bough]

There's no official Rust RGB lib?

[quiet root]

the rgb sdk is c code and has a rust FFI at best

[karmic forum]

yes but the libs that have bindings to the offical sdk dont seem to work when updating so I was wondering if anyone has experienced any issues with the standard c sdk

or if it may be with the rust bindings

[quick bough]

With a protocol this simple, I'd not even bother with an SDK, tbh

[karmic forum]

yeah I guess it is pretty simple if I were just to reimpliment the rgb changing in rust

[quick bough]

For the analogue SDK, I do use their SDK, but it's also relatively easy for the user to figure that out. Just tell them to install it, and then the DLL can be loaded with manual dynamic linking.

I don't think they ship the RGB SDK to consumers, so it's up to you to keep it up-to-date anyway

Might as well just keep your HID list and protocol implementation up-to-date instead 😄

And not like they release a new piece of hardware every other week or so

So, you'd think the devs would have a ton of time to work on the SDKs, and yet... haha

[flat wigeon]

Actually I'm more concerned about this issue: https://github.com/WootingKb/wooting-analog-sdk/issues/12

It's more difficult to fix something missing in the firmware then rolling your own SDK

[flat wigeon]

Polling this over the configuration interface is laggy

[obsidian rock]

how can i get the distance of how far a key is pressed down?

[quick bough]

The analog SDK would be the thing to use

[flat wigeon]

https://github.com/WootingKb/wooting-analog-wrappers <<--- should this still be used?

[quick bough]

Don't see why not, given that the analog SDK doesn't need to be updated on the developer's end

Although the question is, of course, if you want to use an unmaintained package for such a simple task rather than do it yourself

Unmaintained because, well... who knows what Wooting's developers are working on

[flat wigeon]

I don't use the package

Too much bloat 😄

However... does it really use the current analog SDK?

The dll in the respository is quite large for just doing some simple IPC

[quick bough]

I'm not familiar with the project, but it seems you answered your own question

[flat wigeon]

It's just a guess

[quick bough]

You clearly have an opinion about bloat and hence decided not to use this package

Even if this package were the best thing ever, would it change your mind?

[flat wigeon]

lol

[quiet root]

the source for the wrapper dll is available here https://github.com/WootingKb/wooting-analog-sdk/tree/develop/wooting-analog-wrapper/src

the reason for having wrapper DLLs is that not everyone dabbles in FFI and how to use FFI in whatever language they program in

[flat wigeon]

So basically it just does some IPC

[quiet root]

ffi isnt ipc

[flat wigeon]

It directly loads the dlls needed?

[quiet root]

it allows to directly call dll functions in another language yes

ipc is more for well processes talking to each other not language binding

[flat wigeon]

Yeah, I expected that ^^

[quiet root]

we will most likely move to IPC/RPC for the background service we plan so that multiple processes can execute RGB commands and read analog data without interfering with each other

not entirely sure whats planned for that though

[flat wigeon]

So if I use this dll it also will resolve and load the installed device plugins?

[quiet root]

it should

[flat wigeon]

Okay

[quiet root]

honestly not sure if anyone ever wrote any device plugins for it

[flat wigeon]

Wooting (BigBrainAFK | Tony) says this:
the author should use the nuget package of the sdk and not hard copy the code. they should also not ship a dll in their code but rely on the installed analog sdk

[quiet root]

yes

[flat wigeon]

So should I ship the wrapper dll or not?

[quiet root]

no

but you can use the dll

you dont need to write all the FFI stuff yourself

[flat wigeon]

How do I resolve the dll?

[quiet root]

or the raw USB packets to get stuff

[quiet root]

im almost sure we had some example repo somewhere

[flat wigeon]

To me it looks like you should take the C# code and use it with the library

[quiet root]

ill try to find the example repo but it showed pretty clear on how to use the dlls

[flat wigeon]

The is one for C

[quiet root]

hmm i was pretty sure we had examples for the .net one as well... guess i was wrong.

[flat wigeon]

And I changed the file extension to .bin

KSP seems to try to load it otherwise

[quiet root]

but yeah general gist is dont ship analog sdk dll

[strong siren]

to be honest the whole wrapper code around the dll is doing lots of unnecessary things

i might rewrite it

i use it for artemis and it allocates a ton of completely unnecessary ram every time you do anything

[balmy iron]

IPC/RPC for the background service
You have become the very thing you swore to destroy

[strong siren]

optional^

[balmy iron]

Why would analog need that anyway, it's read only how can multiple processes clash

[strong siren]

usb communication in general coming from multiple programs at once is problematic

the main one i see in support threads is people having rgb-sdk apps and trying to use wootility at the same time

[balmy iron]

Yes RGB is understandable since that's read-write (and plz just do HID LampArray for that so Windows dynamic lighting & whatever else other OSes come up with can handle that)

[flat wigeon]

IPC in some way is actually a clean solution. You should just stay away from the network stack.

[quiet root]

for example running artemis (has an analog brush for rgb) and playing a game that also needs analog. in general doing a lot of read/write at the same time can lead it to break

[versed reef]

hello! I am trying to create an app that helps user determine their optimal actuation point/rapid trigger sensitivity for counterstrafing. Has anything like this been tried before? Are there functions in the SDK to set different actuation points/rapid trigger sensitivity?

[quick bough]

Nope, I'm afraid you'll have to RE the protocol

Maybe this is somewhat useful: https://gist.github.com/Sainan/0d285907961a22c8cafc106aa36513e5

[versed reef]

Oh alright, thanks for the input will check this out

[quick bough]

Oh boy

[burnt sundial]

why isnt this on crates.io D: https://github.com/WootingKb/wooting-analog-sdk/tree/develop/wooting-analog-wrapper

[quick bough]

See SDK_USAGE:

I'm not sure why, but for right now, the Git way seems preferred.

[burnt sundial]

i see

[placid ledge]

It's not on crates.io because I haven't gotten around to getting it into a state I've been happy with. e.g. the device connect/disconnect callbacks are not really working IIRC

[burnt sundial]

no its ok i was just wondering why that is and it would be really nice if there where some simple examples of using it at some point after its at the state your happy with :D

[quick bough]

That's gonna take 365 business days

Although I did think there was an example somewhere

This is what I was thinking of: https://github.com/WootingKb/wooting-analog-sdk/blob/develop/wooting-analog-wrapper/src/bin/main.rs

More of a stress-test tho

Then there's my shitty code here:

• https://github.com/Sainan/AnalogSense/blob/senpai/src/main.cpp#L54-L67
• https://github.com/Sainan/AnalogSense/blob/senpai/src/game_gta5.cpp#L28-L41
• https://github.com/Sainan/AnalogSense/blob/senpai/src/game_cyberpunk2077.cpp#L67-L73

The first part is the init, then I either use wooting_analog_read_full_buffer to populate an array or wooting_analog_read_analog to put the value in the right place (the std::copysign is just to transform the 0.0-1.0 into -0.0 to -1.0 where needed.)

[burnt sundial]

how would i go about changing the key colours from the wrapper 👀

[cold jasper]

Is it possible for wooting to accomplish something like this with their software?

https://fxtwitter.com/jimmymalavong/status/1810692866064187762?s=46&t=FkQuvM6PBhk0xgvSCZiE_w

[balmy iron]

Yes, Rappy Snappy is coming soon(tm)..

[cold jasper]

🙏

[raw oxide]

Hope the beta for it comes out asap🙏🏻

[quick bough]

Ah, huntsman. The only other analogue keyboard line on the market with an HID interface. Just a shame Razer has no analogue SDK.

[quick bough]

Well, that kinda reinvigorated my interest in analogue input. Finally got around to making my C shit properly compatible with ABI version 0, given that ABI version 1 is still not released. 😄

[quick bough]

🙂

[quick bough]

hmm my razer huntsman v3 pro arrived. I think I still haven't gotten my Wooting 60-whatever-abomination

[quick bough]

well, they luckily still have an HID interface for getting analogue values, but it seems severely different now

[quick bough]

looks like they just added a new field to the report, which tripped me up

it seems to be like a "priority" as it's a high value when the key is far down or recently activated

also seems mine came with a defective lshift key, that is ever-so-slightly down even when I am not pressing it 😄

[flat wigeon]

One could argue, better no SDK then a crappy one

[quick bough]

so true bestie

can't be that crappy unless they (re)write it in Rust, tho 😛

[flat wigeon]

I would rather say it's hard to make it not crappy

If it comes from a manufacturer, then most likely it will be overspecialized

[quick bough]

Welp, Wooting's wouldn't be too crap if they updated it more than every new keyboard model release

and even in its present state, it gets the job done

just not enticing enough maybe for games to really integrate it

[flat wigeon]

That's sort of the point

The SDK can't cover only keyboards

I want potentially analogue movement out of the box in every game, where I have 360° movement control

Think of Steam Input... which only covers Gamepads

Would be a huge improvement if it could do... Keyboards too

[quick bough]

well, it's arguably more complex than that

because gamepads can be mapped easily to context->buttonmap

of course this model also works for keyboards, but not all contexts can be anticipated by the input API

one example would be teardown. they have scripting support via Lua and some scripts just read the keys raw

so it's a fundamental API change from is_key_down to get_key_value

(kinda off-topic, but I have like 5 hall effect keyboards in my fucking house now, and that's not even counting the ones by wooting)

[quick bough]

@placid ledge It seems wooting-analog-midi fails to start if my plugin returns 0 to device_info. What am I supposed to do if there's 0 devices (that my plugin supports)?

[placid ledge]

In what way does it fail? The app itself defo can handle the case where there are no devices, I've seen it be in that state

[quick bough]

Well, it just doesn't open

I don't know if there's an error log somewhere

[placid ledge]

It should error log to the terminal if you open it via that

IIRC RUST_LOG env should work to control the level

[quick bough]

unfortunately it doesn't attach to the console window when I open it via cmd

[placid ledge]

rip

[quick bough]

I was gonna say my version might be outdated, but, lol

[placid ledge]

I barely have the time to do anything Analog SDK, let alone midi app

[quick bough]

My own usage of the SDK seems fine, so it's probably an issue on MIDI rather than the SDK

Was gonna try "properly" implementing device_info + dispatching events when appropriate

but I guess that wouldn't be a good idea then

[placid ledge]

Hmmm, does it only crash when you have a Wooting device + return 0 on your plugin?

Or is it when you have only 0

[quick bough]

Uhh, I didn't try without the Wooting plugin

Doesn't seem to load when I remove the Wooting plugin too

Seems to just be me returning 0 to the device_info that causes it to fail to start

[placid ledge]

What if you just use Wooting plugin with no device connected?

[quick bough]

it boots and says no compatible devices found

[placid ledge]

It's probably SDK side then

Could be an issue with the cplugin ffi

[quick bough]

hmm yummy

[placid ledge]

[quick bough]

SET NODE_OPTIONS=--openssl-legacy-provider

[placid ledge]

Ah, so the error comes from the fact that it got inconsistent number of devices from the SDK init to getting the device info

That was probably something I had in there for testing, as I think this was the first project where I was trying to use the analog SDK from rust

[quick bough]

I think the issue is that it takes the number of plugins as the number of devices?

[placid ledge]

The initialise function returns the number of devices, not plugins

The code in reference

[quick bough]

ohhhh

so it might be that my initialise routine also needs to return 0

yeah and now it works lol

[placid ledge]

Yeah. In this case, it's expecting a consistency between the number of devices at init vs requesting them right after

Which is a bit unncessary, as that would kinda force you to ensure your init of devices happens during plugin init, rather than being more dynamic

Like I said, probably a left over from me validating the rust interface for the Analog SDK

[quick bough]

yeah, this might cause issues as I'm spinning up a thread in the init

so I would have to wait for the thread to be scheduled in first?

[placid ledge]

Yes, or do it after

but I don't think this check is really necessary, so I'd rather remove it than force specific behaviour on your threading

That being said, I feel like I remember the midi app not having the best behaviour when it came to connecting/disconnecting devices. So having the device list ready on init would be helpful

[quick bough]

Yeah, I'll just busyspin

although I still have the same issue now in reverse

init returns 1 device, but get devices returns 2

might still be my problem, although removing the wooting analog plugin side-stepped it

Does seem to be working fine now, although it is funny that the device list in the analog midi window never updates

this is me pressing keys on both the razer and wooting keyboard while "no compatible devices found" 😄

[placid ledge]

Yeah..., I think that's prob a symptom of the bad behaviour with connecting/disconnecting devices that I alluded to earlier

[quick bough]

I mean, it seems to be working fine, at least in regards to it recognising keypresses from keyboards that were plugged in after the app was started

it just doesn't seem to handle the events to update the GUI

[flat wigeon]

Well yeah, you need compatibility shims as well for legacy stuff. Filtering input, device emulation, etc. But ideally you have one SDK which encompasses all device groups and offers default mappings for typical genres. (First Person Driving, Overhead driving, 360° movement, etc.)

[burnt sundial]

is it possible to chance key colours wiht the wrapper? 👀

[quick bough]

https://github.com/WootingKb/wooting-rgb-sdk

Wait, wtf, you now don't do this on ARM devices anymore?

Did you mess up that bad in the firmware?

[quick bough]

Ah yeah the firmware still has the issue where randomly it just stops acccepting WootDev RGB commands...

Gotta unplug it and replug it to fix it

[pearl yarrow]

anyone know how the profile code is generated?
i made a script convert an image into the LEDs and i have to use another program that moves my mouse to the color text and the keys to apply the colors
wondering if i can just generate a profile code instead

example

[umbral walrus]

@quiet root is this something we can provide?

[quiet root]

youd have to generate a complete valid profile and use the profile api

[placid ledge]

We updated the firmware so that it can accept full 256 byte reports without splitting

[placid ledge]

Does the keyboard crash entirely, or is it just the RGB bits?

[quick bough]

well, except it's kind of a breaking change

[quick bough]

input still works, only RGB stops responding to commands

[quick bough]

I did some RE before on the keyboard mapping packets, tho not the RGB, since there is an official RGB SDK, albeit those RGB changes are only temporary.

[placid ledge]

Okay? Do I need to alert you anytime I make changes 😛

[placid ledge]

It stays static on the last RGB data that was sent?

[quick bough]

Yes, I'm like basically your unpaid coworker? 😛

[quick bough]

Yeah, or on my profile colour sometimes iirc

but one thing I used to do was play Warframe with the thingy that translates the Chroma stuff to Wooting (not the official integration, one with full key coverage)

and sometimes it'd just get stuck on the last effect and I'd have to unplug and replug the keyboard

[pearl yarrow]

either a way to paste all colors at the same time or the code to generate profile codes

[pearl yarrow]

theres a profile api?

[quiet root]

not meant to be use publicly but there technically is one

thats how wootility retrieves profiles and stores them

[flat wigeon]

Then I can toggle the lighting without the ugly left/right split?

Hahaha, I fell for Wootility web

[quick bough]

oh man the RGB on my Wooting is doing funny things since I plugged it into a KVM switch

these keyboards are power-hungry if nothing else

My USB controller could not handle 2 of them in the same row lol

[fickle meteor]

btw is it possible to know what the arm soc on the 60+he is (other than its some 32-bit cortex m apparently)? (also idk if it is maybe printed on the board itself but can't really check rn because it would be painful to get it off from the case)

[tardy frigate]

they aren't made to be run through USB Hubs either

[quick bough]

that is so sad

I will probably plug it back into my PC proper, but I do have a mac device here, and it also needs keyboard, mouse, and HDMI when I wanna use that piece of shit 😄

[ivory lark]

does anyone know what usb HID codes the uwu uses? i don't own one so i cant check myself

[quick bough]

You mean the product ids?

[ivory lark]

i mean the ones used by the analog sdk

[quick bough]

All keys can be remapped in the Wootility, I think by default the mappings for the UwU analogue buttons are zxc

[ivory lark]

thanks

[quick bough]

wtf, do these people not know what they're asking for?

they're gonna hate it so fucking much 😄

[flat wigeon]

I hope, not in firmware

[radiant veldt]

i think theyre gonna add separate option for it.

[quick bough]

one would hope so

actually would be interesting if they were to add like usage statistics, would be real curious to know which option people will go with in the long run

my guess: disabled > rappy snappy > snap tap

[radiant veldt]

Wooting mark guy leaked it

[quick bough]

I feel like the Wooting guys don't know what SOCD means 😄

Both Rappy Snappy and Snap Tap are supposed to be algorithms to resolve SOCD

[paper crow]

[quick bough]

How about "SOCD Resolution: Further Down (Rappy Snappy)" and "SOCD Resolution: Input Priority"

[coral portal]

Further down isn’t really SOCD how the definition used to be use though while input priority is yeah basically just socd but intertvined with rt

[quick bough]

From what I understand, SOCD describes the event when two opposing keys are in the "pressed" state simultaneously (e.g. A and D). Rappy Snappy is, what I would describe as, a "SOCD Resolution Algorithm", which aims to resolve the SOCD event based on how far down both keys are pressed and "swallowing" one of the keypresses.

[quick bough]

My poor USB controller 😄

btw., not that it's super important, but I would appreciate if the MIDI app responded to events by updating the "connected devices" on the GUI

Maybe I'll see if I can patch this in, might be a cool learning experience (for a language and framework I hope I will never have to use in my professional career.)

[quick bough]

oh fuck me dead, this uses react

[quick bough]

also, may I just say that automatic case conversions are horrible for outside collaborators (like myself)? I legit thought the "NO_DEVICES" event was never sent because I couldn't find other instances of this string. Then I saw that BS in the Rust file.

[safe pier]

oh, i didn't see there is discussion here about this, but yes, fully agree, i made a thread in #1265136747470131263 about this, mostly just so that "Cancel Both Inputs" as a SOCD resolution outcome is hopefully not forgotten, as that one is also particularly useful in some scenarios. But yes, I'd love arbitrary SOCD configs, as Rappy Snappy -is- just a form of SOCD resolution, with the added variable of it being defined by pressure, not just on/off input state.

[quick bough]

It's interesting that you'd want the firmware to explicitly cancel the inputs. I assume the software you're using it with does not handle SOCD itself (because that's typically the resolution I see in games)?

[safe pier]

Yes, some (particularly older) fighting games don't have (good or sometimes any) SOCD handling, as there was always an assumption that they were being played using joysticks, which physically do not allow you to perform SOCD -- so when digital controllers were eventually created for them, it was a ruleset requirement that SOCD resolved to no input, as this was not possible otherwise

[quick bough]

I wonder how much of "useful SOCD resolution options" will come out of this, because I fear this "Rappy Snappy" stuff is mostly just a marketing stunt (with the silly name and all).

[safe pier]

i see the appeal of Rappy Snappy as, well, it being most-pressure SOCD resolution. And obviously Razer's Snap Tap, being latest-input SOCD resolution + Rapid Trigger -- I'd just hope it doesn't stop at just these two resolution options because they're "the most marketable"

more customization good

[quick bough]

Razer's Snap Tap seems weird to me, I think it does more than just SOCD resolution

the marketing definitely works, tho, because it seems like everyone suddenly "must have" Rappy Snappy or Snap Tap (even in Discords for some smaller hall effect keyboard manufacturers like Akko and Keychron).

[safe pier]

it does, it also does what Wooting calls Rapid Trigger on top of latest input SOCD -- releasing the key event as soon as the switch starts moving back to neutral position, not when it's past an arbitrary actuation point; and then using that as the inputs used for SOCD resolution.

[quick bough]

#⏬│rappy_and_snappy message

This was me testing both. I'm not sure if I'm tripping and I might have to retest it, but the razer keyboard also seemed to input 'S' (given that my character is moving backwards).

which is really strange when you're just tapping A and D, so I definitely see why people are uncertain if it should be allowed in competitive play 😄

[safe pier]

that's odd

[quick bough]

well, can't see it, but it definitely does strange stuff

it's also not quite most recently pressed, since whichever is further down is also a factor seemingly

I certainly prefer that Wooting's option is easy to reason about

[safe pier]

yeah, especially since Razer just claims it's straight latest-input SOCD + RT, if they're doing some extra shenanigans then that's just odd and not quite user friendly

in all the video material they put out with an input visualizer it does just trigger A/D, not S though, so idk

might be helpful to use one that's unaware of analog inputs

[quick bough]

I don't think it's using joystick input in GTA V

[quick bough]

urg, why did I ever downgrade to using the stock version of the analogue SDK, now I once again can't deinit/unload the SDK without crashing 😄

...and that's why I originally designed my plugin as a replacement for the "wooting-analog-plugin", too

I already fixed this shit for you over 8 months ago

[topaz timber]

whats the difference between "neutral" and having the setting off ?

[quick bough]

#🤖│community_dev message

[quick bough]

Probably the funniest thing about Rappy Snappy is that it results in SOCD behaviour being the same as in "analogue-ready" apps, e.g. here is GTA V with analogue support patched in: My character moves to the left despite my input being SOCD (from a digital perspective)!!!

So, maybe if you worked on improving the analogue SDK — fixing the crash on unload issue and making the testing plugin not so Rustly-stable — and pushed it a bit more, game devs would handle this stuff for you

Also, I realised the Razer default profile is some "game-ready" crap, where it basically ignores your actuation point when it notices you're starting to let go of a key.

[versed ginkgo]

If this could be change every time when I switch songs in osu that will be amazing!

Like gosu's livestream interface.

[pearl yarrow]

yeah i would make it do that if i could control wootility externally

i dont think its possible

[versed ginkgo]

Maybe need special rgb sdk from wooting?

[strong siren]

i have exactly that setup with artemis: it changes colors with whatever song im playing on spotify. let me try and find a video of it

[versed ginkgo]

Wooting can develop a function that change rgb from input image or even video.

If so it will be the most fancy rgb kb ever.

[pearl yarrow]

if u find it i will check it out tmr gonna sleep now

[pearl yarrow]

i could probably make it video if the thing that changes the rgb is efficient enough

[strong siren]

i dont really know if doing that for osu would work though. there are some ways to get data from the game but color stuff is hard probably

you can make it mirror the screen for example

[pearl yarrow]

if i find a way to change the rgb while using gosu memory i will make it work

there are osu overlays that use bg image

so gotta link it to my kb

[strong siren]

here's a rough idea of what it looks like

[gloomy bough]

does anyone know how to fix this

everytime i try to trash an advanced key

this pops up and it won't let me

[quiet root]

is there supposed to be sound

[strong siren]

no

the movement is just perlin noise, not audio reactive. you can make it reactive but i dont have mine setup like that

[pearl yarrow]

can you link the tools you used?

[strong siren]

https://artemis-rgb.com/

[pearl yarrow]

thx

[quick bough]

Does artemis work with wooting arm boards after the firmware update?

[strong siren]

it does now

as of uh 2 days ago?

[quick bough]

Good

[pearl yarrow]

wow love the example artemis rgb plugins

[quick bough]

just use the wooting rgb sdk or talk to the HID directly

all these RGB tools are just gonna hold you back more than anything imo

[red wasp]

i know wooting has their sw open source, and cad files, but does anyone know if they publish ecad stuff? schematics etc?

[strong siren]

decent amount of example plugins here: https://github.com/Artemis-RGB/Artemis/network/dependents

where is that dead link, wiki?

[quiet root]

we dont

[red wasp]

Fair enough

[naive vessel]

Any considerations for a Go wrapper in the future?

[quick bough]

Just make your own with FFI?

[naive vessel]

Hmm, could be fun

[quick bough]

@placid ledge I hope I'm not annoying but given how the SOCD stuff is seemingly "on hold" now, do you maybe have the time to get https://github.com/WootingKb/wooting-analog-sdk/pull/70 over the finish line? It is really annoying that the stock Analog SDK still crashes on unload, especially when I provided a patch for it over 8 months ago.

[placid ledge]

Unfortunately, I'm never not busy. But I've taken another look at this and have merged it

It'll take some more time before I have the space to make a new release, but I'll try and not leave it too long

[quick bough]

Now I guess we only have to wait until Wooting releases a new keyboard 😛

(Which probably wouldn't be a good move given that the 80HE is still chugging along)

I just wish I had something to do, just waiting for incompetent-ass DHL to finally give me more hall effect keyboards to suffer with

[quick bough]

Ah wait, I just realised the 80HE isn't in the SDKs yet, so that one will probably be the next

[opaque fox]

I'm having some strange issues when working with the analog SDK. At some point it suddenly starts taking 180s to initialize and a reboot is required to fix it.

[2024-07-26T19:01:15Z TRACE wooting_analog_sdk::ffi] wooting_analog_initialise called
[2024-07-26T19:01:15Z INFO  wooting_analog_sdk::sdk] No plugins found in "C:\\Program Files\\WootingAnalogPlugins"
[2024-07-26T19:01:15Z INFO  wooting_analog_sdk::sdk] Loading plugin: "C:\Program Files\WootingAnalogPlugins\wooting-analog-plugin\wooting_analog_plugin.dll"
[2024-07-26T19:01:15Z DEBUG wooting_analog_sdk::sdk] Plugin got plugin-dev sem version: 0.7.1. SDK: 0.7.1
[2024-07-26T19:01:15Z INFO  wooting_analog_sdk::sdk] Plugin and SDK are compatible!
[2024-07-26T19:01:15Z DEBUG wooting_analog_sdk::sdk] We got it and we're trying
[2024-07-26T19:01:15Z INFO  wooting_analog_sdk::sdk] Loaded plugin: "Wooting Official Plugin"
[2024-07-26T19:01:15Z DEBUG wooting_analog_sdk::sdk] Loaded 1 plugins from "C:\\Program Files\\WootingAnalogPlugins\\wooting-analog-plugin"
[2024-07-26T19:04:16Z INFO  wooting_analog_plugin] Found and opened the Some("Wooting Two HE (ARM)") successfully!
[2024-07-26T19:04:16Z DEBUG wooting_analog_plugin] Started timer
[2024-07-26T19:04:16Z DEBUG wooting_analog_sdk::sdk] SDKResult(Ok(1))
[2024-07-26T19:04:16Z INFO  wooting_analog_sdk::sdk] 1 plugins successfully initialised
[2024-07-26T19:04:16Z TRACE wooting_analog_sdk::ffi] catch unwind result: Ok(1)
Initialized successfully in 180.5000753 s

Here's the output with full logging enabled.

Looks to me like it's a shared memory access problem

[quick bough]

Can't say I've ever seen that before. Have you tried building it yourself from develop branch? There are a few good bugfixes for the "wooting-analog-plugin" in there.