yarn 
#🤖│community_dev
, that also pulls the natives
faint vapor
newer NodeJS installers offer installing build tools, otherwise this does its job: https://github.com/nodejs/node-gyp#on-windows
quiet root
doesnt help if python command refers to 3.7 by default
quiet root
which theyd just switch to python3
faint vapor
I hate that we need one scripting language for another
quiet root
true they should move node.gyp to nodejs
faint vapor
it feels like just because the devs of these tools prefer to use python for whatever, they force it upon everyone else wanting to use their tool
so yeah, once you installed the stuff, help me figure out how to correctly type the model on line 17 😦
quiet root
i wish id know why it wont install tho
lol
its correctly using python 2.7
guess imma redo build-tools
faint vapor
build tools 
faint vapor
huh uh mine says 2015
quiet root
the worst kinda shit with node-ffi and all its shit
like ref.struct
ref-array
ref itself
faint vapor
ref-array doesn't even install for me
faint vapor
oh yeah, I did that for ffi too
fathom garnet
node needs dependencies for a reference struct dafuq
faint vapor
quiet root
well node doesnt have structs
so yes
u need packages
altho i never understood why ref doesnt support arrays
in general ref, ref-struct, ref-array and ffi should be default node modules
and thanks to nvm not working on windows i have to now uninstall node 13 and install node 12
quiet root
until lxe makes node-13 branches
faint vapor
and it works for me
faint vapor
yeah but that is basically the same
quiet root
hm might try it out
faint vapor
C:\Users\Meta>nvm
Running version 1.1.7.
Usage:
nvm arch : Show if node is running in 32 or 64 bit mode.
nvm install <version> [arch] : The version can be a node.js version or "latest" for the latest stable version.
Optionally specify whether to install the 32 or 64 bit version (defaults to system arch).
Set [arch] to "all" to install 32 AND 64 bit versions.
Add --insecure to the end of this command to bypass SSL validation of the remote download server.
nvm list [available] : List the node.js installations. Type "available" at the end to see what can be installed. Aliased as ls.
nvm on : Enable node.js version management.
nvm off : Disable node.js version management.
nvm proxy [url] : Set a proxy to use for downloads. Leave [url] blank to see the current proxy.
Set [url] to "none" to remove the proxy.
nvm node_mirror [url] : Set the node mirror. Defaults to https://nodejs.org/dist/. Leave [url] blank to use default url.
nvm npm_mirror [url] : Set the npm mirror. Defaults to https://github.com/npm/cli/archive/. Leave [url] blank to default url.
nvm uninstall <version> : The version must be a specific version.
nvm use [version] [arch] : Switch to use the specified version. Optionally specify 32/64bit architecture.
nvm use <arch> will continue using the selected version, but switch to 32/64 bit mode.
nvm root [path] : Set the directory where nvm should store different versions of node.js.
If <path> is not set, the current root will be displayed.
nvm version : Displays the current running version of nvm for Windows. Aliased as v.
just sometimes you need admin power
faint vapor
I never had issues with npm
none that I couldn't solve
although native stuff always sucks here
quiet root
doesnt
faint vapor
faint vapor
hm that worked last night
then just get them from here for now https://github.com/WootingKb/wooting-rgb-sdk/releases/tag/v1.1.0
stuff the DLLs into the lib/natives/ directory
quiet root
already done
quiet root
im unable to tell u why its not working
faint vapor
the char pointer?
quiet root
ya
faint vapor
hm
faint vapor
yeah
quiet root
so this might be some deep running problem with node-ffi
faint vapor
I was wondering if the const keyword messes stuff up
faint vapor
hm ok
faint vapor
hmmm cutting off the other values and only typing connected and model gets me stuff too
types.WOOTING_USB_META = StructType({
connected: types.bool,
model: 'int', // ???
})
{ connected: true, model: 32766 }
faint vapor
I was totally looking at the wrong thing the whole time 
my JSON wrapping just revealed the fields but messed up the values or something
right now I got a buffer and need to apply the structtype to that somehow so I don't have to manually read the buffer
quiet root
its using ancient api dlls thats why
almost all tools written before the w2 api release dont work anymore
fathom garnet
I assume nobody worked on making wooting work in the unity input manager package? Just checking to make sure I’m not doing work someone is doing right now
quiet root
@fathom garnet not that i have heard of it
quiet root
just the dll
faint vapor
I'm still stuck with the struct btw 
flat wigeon
UsagePage 0x1337 😄
flat wigeon
Was wooting_rgb_direct_set_key() updated to support the Wooting Two?
It stops right at key 95, keys above that won't change color
flat wigeon
Second time i needed to reboot the keyboard 😕
faint vapor
@flat wigeon it worked in DLLs compiled from earlier versions of the PR
flat wigeon
The issue here seems to be in the firmware.
wooting_rgb_direct_set_key() won't work on key >95, but wooting_rgb_array_set_single() works
The former sends a feature report to set exactly one key, the latter sends an output report with sets the entire block
faint vapor
I forget, does it return success?
If so, just set an array with one single key on failure as a workaround
Or replace it completely, unless it's slower or something
flat wigeon
It returns success
faint vapor
always true or a legit "success" boolean in general
flat wigeon
It returns true if the command was successfully sent to the device.
So rather an always true ^^
The thing is, I want to use A1 and A2 as toggles for headphone/mic mute in Teamspeak
Currently the firmware/RGB SDK doesn't go well with that
If I skip WOOTING_COLOR_INIT_COMMAND then pressing Caps Lock or Num Lock resets all colors according to the profile
But If I use WOOTING_COLOR_INIT_COMMAND, then I have to handle everything myself including the indicators for Caps Lock and Num Lock.
Ideally I want to just set those keys to "sticky" and nothing else.
quiet root
wont work that way sadly
so the best option for you is aurora and then writing an aurora plugin that interfaces with teamspeak plugins via named pipes
or sockets
or rpc
or you go wild with spamming the settibg of colors every ms
flat wigeon
Hell no, I never tought of spamming the color setting ^^
I already have a background program with conntects to TS via named pipes
quiet root
so write a small aurora plugin
flat wigeon
But it does colors only?
quiet root
yes
flat wigeon
Does it handle Caps Lock and Num Lock?
quiet root
it handles everything
its a program made for cross device rgb
independant of manufacturers
quiet root
what do you mean?
flat wigeon
Can it overlay output from to different applications?
quiet root
i wasnt aware that the wooting can do that
flat wigeon
No it can't
quiet root
ya
flat wigeon
But the question if Aurora can
quiet root
it can take razer chroma input
other than that ud need to write plugins for auroras
like i dont udnerstand the problem
he wants toggle rgb indicators
rebinding wont bring those
unless i understood it wrong
quiet root
anyway wootings just cant overlay different rgb things cause the rgb sdk only allows 1 app to have control
nope
cause the wooting overrides it or if u init it in rgb sdk all color is gone
thats why usually people use aurora or smth
if they want normal rgb profiles plus some extra
cause aurora internally overlays its rgb inputs into 1 thing
i guess he wants it to be also controlable by TS
so when u click the UI button it toggles
otherwise yes
thered be the simple solution
flat wigeon
If I use Aurora, games will use it
quiet root
u can disable that
u can disable almost everything in aurora
including what device sdks to load
so tl;dr the only 2 ways to realise your feature are aurora, an aurora plugin and a TS named pipe to get the state of the mutes OR a completely custom program that sets the entire keyboard lighting and interacts with TS via the same TS plugin
flat wigeon
Does it detect if you switch the Wooting profile?
quiet root
nope
ud need a plugin for that aswell
and i think these problems are what tino meant
i mean the rgb sdk cant even detect that
flat wigeon
Yes
quiet root
ud need to also use the analog sdk aswell
flat wigeon
Currently I have to use that anyway
The issue is, how do I know which key switches profile and how do I get the default colors of that profile
quiet root
might wanna hand kristall a username if u have it
strong siren
But ideally you'd be able to light a key different colors depending on ts mute status
quiet root
only problem is that aurora doesnt know wootings active profile
strong siren
Yeah
I could add that in but not sure how often to poll the keyboard for the current status and stuff
You can do it in c# directly
I'm asking on our discord
I don't remember if it worked at all honestly
flat wigeon
Btw. my program has a second feature it intercepts the Explorer hook and changes Volume Up/Down to work on a db scale ^^
In my opinion much more sensible if your typical volume is at 10%
stiff shadow
Will Wooting Flaretech™️ switches EVER be available in a manner such as Cherry MX switches?
I'm talking ability to develop consumer products, general documentation and/or ability to buy sensor hardware from Wooting and POSSIBLY market a product without a liability issue?
wide nymph
@stiff shadow that’s what we have Lekker switch for
quiet root
this channel is also more for software development and stuff developed with use of a wooting keyboard and not the only the switches they use
stiff shadow
Alright, thankyou Calder c:
I won't spam post in this channel now that I know I'm off topic, but I was thinking the other day about testing some input device ideas now that I have a resin printer, and wanted to know if I could ever use Wooting style switches in it without stepping on anyone's toes.
I'm glad to know that's in the future plans
flat wigeon
It sounds like he wants to build his own device using Flaretech switches (or something comparable)... for whatever reason
hollow mango
I remember there was a writeup for getting things working in a unity game, but it seems like the link is broken, was that info outdated and removed or something?
quiet root
just use the analog sdk
hybrid lake
@hollow mango that particular guide was outdated. If you have experience writing custom code with unity you could follow the general C# guide to see how to load the library and read the values: https://dev.wooting.io/wooting-analog-sdk-guide/c-guide/. From that point you should be able to get the values in unity as well
hollow mango
Sounds good, thanks!
Any particular concerns for thread safety with either sdk, or are standard precautions enough?
fathom garnet
now im curious what you are doing that you are not checking input in unity's main thread
hollow mango
Mostly the rgb sdk, but figured I would check for both. I just genetally try to keep as much work as I can off the main thread.
flat wigeon
The RGB SDK works multithreaded, but you should lock before sending anything to the device
fathom garnet
hm I see, I just dont like putting things interacting with the unity system directly into anything but the main thread, unless you are already working with the DOTS system
hollow mango
Yeah Im working with dots.
fathom garnet
ah ok
hollow mango
As a random suggestion: it might be worthwhile reaching out to Rewired (fairly popular input manager for unity) and seeing if they will add native support.
fathom garnet
not really needed, since 19.3 or 2 you can install the preview of the new input manager from unity itself
that can already detect the wooting, but cant yet use it since its not all done
hollow mango
Ah, didn't see they were doing a new input manager. Still in 2018.3 land here.
fathom garnet
its part of them finally opening stuff up so its on github if you want to add it yourself :p was planning on maybe trying to make it work but cant get to it
hollow mango
Yeah the recent trend is pretty cool. I still have my fair share of complaints though lol.
quiet root
analog sdk is pmuch thread safe by default thanks to being built in rust
theres a lot ud need to do if u wanna fuck shit up
placid ledge
Yeah, all the C FFI calls into the new analog sdk have to claim a lock on a mutex
😄 Well, the simpler and probaby clearer version is that it's not possible to have more than 1 api call happening at once as the C interface has to claim a lock on the mutex
So if you call a method at the same time in 2 different threads the second one will have to wait for the first to complete before continuing
In general all the API functions (except initialize) are effectively just data collection (As the Wooting Device Plugin gets data from the kb in a separate thread) so they should all return really quickly
quiet root
just take over the working memory of the sdk and always tell it the mutex is unlocked 
easy crashes
placid ledge
Sounds like a great time 
quiet root
ikr
placid ledge
Mutex always unlockedTM
quiet root
sdk always crashing tm
anyway nice job with the analog sdk
lets hope rgb sdk will be cool too
placid ledge
Thanks 😄 I hope the RGB SDK will turn out good as well when I get to it
placid ledge
What would make it easy on you to implement 🤔
hollow mango
Honestly it isn't too bad right now. Just standard DllImport stuff in C#.
flat wigeon
I was thinking about the limitations of the firmware
Probably it's better to see it like the lizard mode of the Steam Controller
So the color overlaying (especially regarding num lock, caps lock and scroll lock) should actually be handled by the host, since it's not dedicated hardware for that purpose
At least as soon as the management software takes over
As a side effect the bug with wooting_rgb_direct_set_key() is no issue anymore
hollow mango
The rgb sdk says reset must be called on app exit. If that is missed (say in a hard crash or something) what are the side effects. Are they "brick keyboard" level, or more minor things?
placid ledge
It'll just mean that the leds on the keyboard won't return to the loaded profile and will remain at whatever you last set it as. Can be easily fixed by replugging the keyboard or by resetting with the sdk again
@quiet root node-ffi best libraryTM
hollow mango
Ok cool, thanks!
glacial horizon
Do be aware that after a reset you wont be able to alter the colors anymore though:
iirc the develop branch has a fix for that, not totally sure though
hollow mango
I'm actually running into an issue where both set funcs are failing entirely. not 100% sure what is up.
quiet root
any code u can show us?
glacial horizon
direct set should work, array set might be broken
else if it doesnt work, a manual rebuild fixed my problems
hollow mango
I'll try a manual rebuild. Here is some of the code though.
[DllImport( wootingDllName )]
[return: MarshalAs( UnmanagedType.Bool )]
private static extern Boolean wooting_rgb_direct_set_key( Byte row, Byte column, Byte red, Byte green, Byte blue );
[DllImport( wootingDllName )]
[return: MarshalAs( UnmanagedType.Bool )]
private static extern Boolean wooting_rgb_array_set_single( Byte row, Byte column, Byte red, Byte green, Byte blue );
[DllImport( wootingDllName )]
[return: MarshalAs( UnmanagedType.Bool )]
private static extern Boolean wooting_rgb_array_update_keyboard();
Looks like you're trying to manually write a C# wrapper around the rgb sdk? Because one already exists: https://github.com/simon-wh/Wooting.NET
hollow mango
Ah, I'll give that a shot then
hollow mango
Hm, same result. no change on keyboard, set returned false, update returned true. I am going to try a rebuild of the sdk real quick.
glacial horizon
That's what fixed direct set for me, set array is still not broken
hollow mango
Yeah rebuilding it seemed to fix. odd.
flat wigeon
It's not surprising color updates won't work after wooting_rgb_reset()
It closes the device
Direct set seems not to work for keys >95
hollow mango
That likely stems from a desire for separated functions for reset all keys and closing the device.
flat wigeon
Why is the analog SDK written in Rust, but the RGB SDK in C...
quiet root
cause one was rewritten recently and one is much the same since wooting release
glacial horizon
It is surprising as its a bug, reset should reset it to default and still have the keyboard be accessible
flat wigeon
I meant, what was the actual reason to use Rust
It's not that I can't imagine reasons, just curious
quiet root
@flat wigeon thread safety, and prob rust usually being better than c with all its variable ownership etc
but ya simon chose it while the old sdks were written by wooting founders
so only he knows
stoic belfry
https://www.reddit.com/r/WootingKB/comments/cbj426/analog_sdk_update/f06pm2u/ There's a slight answer here, it seems mostly because it has full compatibility with C / C++, speed of development and just wanting to write it in rust to learn it
flat wigeon
Hahaha ""Doing something in production "Just to expand your knowledge" is a terrible idea.""
While it's true... there are some issues with that
Also I can understand if someone dislikes the C++ standard library
placid ledge
But it wasn't "just to expand your knowledge" though
flat wigeon
Sure, that was a bit over the top
placid ledge
If it was just that then yes it's a terrible idea, but that happened to be a nice consequence of the choice
flat wigeon
One of the issues with "not in production" is, basically you need to redevelop your software after the initial design finished.
And typically finding design flaws takes testing over longer periods of time
placid ledge
I'm confused as to what point you're trying to make
hollow mango
Better worded as: Expanding your knowledge in order to improve quality of your production code. If that never happened everything would still be written in C or assembler.
formal crane
fathom garnet
flat wigeon
Technically it's pretty inefficient to poll 1000 times a second just to check if a key was pressed...
That wasn't a reply ^^
Reads in the analog SDK effectively just poll.
So I need to be careful to not miss a keystroke
Polling too often wastes power, polling too little lets me miss keystrokes
Are the analogue inputs adjusted by the linear curve of the profile?
placid ledge
Currently the analog values are not adjusted by the profile curve, internally the sdk plugins run a thread to collect analog data to ensure the data you're getting is the most up to date. As the legacy analog sdk would call hidapi read with 0 which would async read in the background, so in reality you'd get the analog data that was present the previous call you made to the sdk.
With your mention of the "Polling too often wastes power, polling too little lets me miss keystrokes" made me realise that it'd probably be worthwhile to have an option to configure the internal polling rate as well as the possibility of having an option for giving the sdk a callback which would get called whenever a key value changes
What do you think? Also, do you want the inputs to be adjusted by the curve? Could potentially look into having a setting to enable that
flat wigeon
I think there are two use cases. First, where you actually want the analogue state of the key at a given time. Second, where you basically want events like when using DKS.
For the first case I think polling is the obvious way and adjusting the linear curve makes sense.
For the second case a callback would be more useful, since the analogue values can update with the scanrate, but actual events happen rarely.
flat wigeon
wooting_analog_initialise();
wooting_analog_read_analog(0x29);
wooting_analog_uninitialise(); // Crash?!
Am I doing something wrong here?
flat wigeon
A1 - A3 have no scan code?
quiet root
correct
flat wigeon
Odd, according to the old SDK they have a scan code
flat wigeon
Do you know if that is an issue with the firmware or the SDK?
quiet root
for me everything works except a1-a3 and mode
flat wigeon
Also with keymode scancode1?
placid ledge
@flat wigeon iirc the keycodes for the Fn, A1-3 and Mode haven't been finalized in the firmware yet as they are not part of any of the keycode specs
Also, what crash you getting on uninitialise?
flat wigeon
Access violation from a another thread.
Compiled with Toolset: Visual Studio 2019 (v142), Plattform: x64, Windows SDK: 10.0, Subsystem: Windows
quiet root
prob cause u cant uninitilise before u checked if it actually is initilised
flat wigeon
If you lock the keyboards key colors without resetting it and shutdown the computer...
...the keyboard lighting will stay active
Not sure if that is an oversight or intentional.
placid ledge
Hmmmm, I'll have a look into it, how come you're not using the wrapper and loading the SDK directly?
flat wigeon
Is there a pre-compiled version of the wrapper?
I took the wrapper from here: https://github.com/WootingKb/wooting-analog-wrappers/blob/master/libs/win-x64/wooting_analog_wrapper.dll
Same thing happens
placid ledge
@flat wigeon https://github.com/WootingKb/wooting-analog-sdk/releases the release tar's include everything you should need, including headers, wrapper, etc
If it's just the uninitialisation that's not working don't worry too much about it, it isn't critical to uninitialise
flat wigeon
hmm...
Actually I'm interested in if others can reproduce this issue
I can't use the analog SDK anyway
placid ledge
I couldn't replicate it in the current develop branch of the analog sdk on linux. Haven't tried windows yet
Howcome?
flat wigeon
I want to remap A1 - A3. The analog SDK doesn't allow me to read the state of these keys.
placid ledge
It's not that the Analog SDK doesn't allow it, it's that the firmware has not assigned keycodes to them yet, I'll ask Jeroen if he can assign them
What kind of remap you looking to do, there's the full programmability which is in alpha atm?
flat wigeon
Currently I'm testing with directly accessing the HID device, but it's brittle and doesn't go well with wootility
A3 toggles the RDP Window to my work PC
Also the color of the key indicates whether the connection is established and if the RDP windows currently has focus
placid ledge
The full programmability stuff that's in alpha might be worthwhile for you. As you could use it to reassign A3 to something like F13 and use that instead
flat wigeon
Like the LED is per default off, has the default color if my RDP connection is established and is green if the window has focus
flat wigeon
Actually... mapping the key to F13 and then hooking keyboard inputs is a bit troublesome
pliant carbon
Hi, my C# code isn't working (It's not lighting up the keys) - here's the pastebin https://pastebin.com/d1hLx7zj
It worked once, then every time I run it after my keyboard stops responding to input and I need to unplug and replug it again
strong siren
you have to call RGBControl.IsConnected before calling SetKey
pliant carbon
Oh right, haven't used the api in a while. If I do something like,
while(!RGBControl.IsConnected())
{
RGBControl.IsConnected();
Thread.Sleep(1000);
}
It should work, right?
strong siren
what is the purpose of this?
pliant carbon
To connect to the keyboard?
strong siren
you should only need to call it once
what you did there would only be useful if you were asking the user to plug the keyboard in or something like that
pliant carbon
I see
Okay, I checked it once, and threw an exception when it returns false
But my keys still don't change colour
Should direct parameter be true?
Oh it works if direct is true, why?
strong siren
you can either set direct to true or call UpdateKeyboard after
strong siren
if you want to set multiple keys at a time, you only need to call update after you set them all
pliant carbon
Got it
If I'm setting multiple keys, is SetFull faster?
I need to set a few (~10) keys very quickly
strong siren
i'm not sure actually
aurora Set()'s them all first and Updates after and it takes around 40-45ms to do the whole board
pliant carbon
I think it should be fine with only a few keys then
strong siren
im not sure if the setfull is faster. i would test but i dont have my wooting with me because quarantine :(
pliant carbon
I'll test it once I figure out how to make that function work I don't quite understand it
strong siren
you have to fill the array with the coordinates you want from the table in the readme. it's easier if you just setkey and update tbh
pliant carbon
Yeah I'll stick with that thanks alot
pliant carbon
Where can I find the wooting-analog-sdk.dll? I'm downloading it from the link in pinned then using the dll from wrapper > sdk but the C# api cannot find an entry point named wooting_read_analog when I try to read a key's analog value
placid ledge
You using the new sdk and c# library? https://github.com/WootingKb/wooting-analog-sdk
pliant carbon
I am using the Wooting.NET NuGet package
that you made
it says that the sdk and plugin are already installed and updated through wootility
I think I have the wrong dll
placid ledge
Wooting.NET is only for RGB sdk now
as the analog sdk that was included is now deprecated
and replaced by the analog-sdk I linked
pliant carbon
I just need to detect keypresses
pliant carbon
So they are different from the Wooting.NET Keys enum
This is going to be a pain to convert them :/
What will be the best way to do that? For example, how do I read the key (2, 3) as its keymap value?
placid ledge
key (2,3)?
pliant carbon
placid ledge
That's the mapping between the keycode you give and the keyboard matrix: https://github.com/WootingKb/wooting-rgb-sdk#keyboard-matrix indexing
pliant carbon
So I can't use that to read the analogue value of that key?
placid ledge
No, the analog SDK usees standard keycode sets
placid ledge
You need to convert the keycode -> WootingKey.Keys
pliant carbon
I am
placid ledge
Assuming you're reading the keys and lighting based on their values
pliant carbon
or you mean the other way around
I read it like this
float analogValue = (float)WootingAnalogSDK.ReadAnalog((ushort)move.Key).Item2;
Setup a dictionary that maps WootingKey.Keys to the HID (or Keycode of your choice set using SetKeycodeMode). Then you can map the values to the respective keycode in HID for the analog sdk
I should probably update Wooting.NET so there's a easy way to use it in tandom with the new Analog sdk
pliant carbon
I did that but I don't know what you mean by HID. I thought it was the values in the USB section of this list?
static Dictionary<WootingKey.Keys, ushort> HIDs = new Dictionary<WootingKey.Keys, ushort>
{
{ WootingKey.Keys.A, 4 },
{ WootingKey.Keys.B, 5 },
{ WootingKey.Keys.C, 6 },
{ WootingKey.Keys.D, 7 },
{ WootingKey.Keys.E, 8 },
{ WootingKey.Keys.F, 9 },
};
Yes, that is correct
HID is the standard USB keycodes, that's the right one to be converting to
pliant carbon
Oh it does work now! Item2 should have been Item1. Also, I noticed the alphabetical keys go in order (A = 4, B = 5), so a quick fix is just to offset the key value by 37
Of course, it will only work for alphabetical keys, but I only need that right now
thanks for all the help!
placid ledge
No problem, lemme know if you run into any other issues 😄 seems like there's still some improvements to be made on the current setup
hazy locust
any mac developers reading the keyboard using libwooting_analog_sdk.dylib and libwooting-rgb-sdk.dylib?
I'm using ctypes to read in the dylib files into python (like @sharp patrol's (https://github.com/BattleCisco/pyWooting)) but my keyboard is failing to be recognized (even though wootility and the rest of my computer recognizes it), and when I try some of the boofer_read functions it crashed my ipython kernel.
Any advice would be greatly appreciated
quiet root
did u use the new analog sdk?
sharp patrol
I suppose it might have gotten deprecated as it was a while ago that I last used it
I can take a look at it this afternoon to see what is required to update it
Ah, wait I didn't see the mac keyword. I'm not sure if the dll generated are os independent. Microsoft did release a .net core which allows you could allow you to run dlls on mac
hazy locust
did u use the new analog sdk?
@quiet root
yes! At least, I think so.
https://github.com/WootingKb/wooting-analog-sdk
quiet root
ok ya thats the new one
the functions work differently tho
they arent the same as before
hazy locust
yeah I've been struggling with that a bit haha
here's what I have for the functions:
(base) PSY-C02ZF41RLVDM:dylibs henrymj$ nm -gU libwooting_analog_sdk.dylib
00000000000137a0 T _drop_device_info
0000000000013390 T _generate_device_id
000000000000e920 T _is_initialised
0000000000013670 T _new_device_info
000000000000eb80 T _read_analog
00000000000be400 T _rust_eh_personality
000000000000ea50 T _unload
0000000000011e30 T _wooting_analog_clear_device_event_cb
0000000000011f50 T _wooting_analog_get_connected_devices_info
00000000000115b0 T _wooting_analog_initialise
00000000000117d0 T _wooting_analog_is_initialised
0000000000011bb0 T _wooting_analog_read_analog
0000000000011bc0 T _wooting_analog_read_analog_device
00000000000124f0 T _wooting_analog_read_full_buffer
0000000000012500 T _wooting_analog_read_full_buffer_device
0000000000011d00 T _wooting_analog_set_device_event_cb
00000000000119d0 T _wooting_analog_set_keycode_mode
00000000000118b0 T _wooting_analog_uninitialise
00000000000116f0 T _wooting_analog_version
u can check the headerfiles it comes with
they tell u what functions return and what they expect
placid ledge
and you're not supposed to use the analog_sdk dll directly, use the libwooting_analog_wrapper
https://dev.wooting.io/wooting-analog-sdk-guide/analog-api-description/ / https://github.com/WootingKb/wooting-analog-sdk/blob/master/SDK_USAGE.md
hazy locust
thanks to both of you @quiet root @placid ledge !
pliant carbon
How do I make my keyboard light up again after changing colours with the API
do I need to reset all keyboard settings?
pliant carbon
thx
torpid arch
Hello, is Wootility written in Rust, as well?
fathom garnet
it's using electron as the base
and I think only Simon worked with Rust yet, Jeroen hasn't tmk
torpid arch
I can't seem to find it on the github, so I assume it's closed source. I was really hoping to try and integrate a different color space, maybe HCL aka HLC.
fathom garnet
yea there were plans to open source it, but after going over benefits vs drawbacks it was decided to keep it closed (for now) and instead provide SDKs for rgb/analog and perhaps more of a plugin-style instead of fully custom base software, though I don't know what the exact plans are right now, as the main focus is on the lekker board for now
torpid arch
Yeah, that's what got me here. The Lekker looks beautiful. I completely understand keeping it closed while still in the early stages. Especially with so few in-house developers, the risks really outweigh the rewards.
placid ledge
Yeah, we would like to open source it, but it isn't the right time.
Wootility is made using Electron + React + Redux + Typescript, haven't been able to get much Rust in there yet 😄
torpid arch
So uhh. Would you be offended if I tried to pull that .asar apart? ❤️ Promise I just want to see if I can make the color picker use HCL / HLC for easier/prettier color picking.
placid ledge
Nah, go for it. Might not be easy to work with though as it's all minified typescript compiled js
torpid arch
Yeah, that's going to be interesting. compiled JS is so much harder to read than assembly.
placid ledge
Wootility still being closed source is less about hiding the code and more about juggling an open source project while we have our plans for what we want to do with Wootility
Well, that's what it is for me at least. I'm a big fan of open source, so I'd push for it to happen if it made sense at this time
torpid arch
That makes sense, I'm sure it's tons of work juggling all of that as it is. Admittingly, I'm not the best dev. I have almost no experience, it's all hobby stuff so far. Any PRs I made would probably make you want to cry. 😛
I hope everything is going well with the Lekker/Management aspect of all of this.
quiet root
i mean i said it multiple times... id be happy to get the map files so deobfuscate the js
wouldnt mean its opensource but people who want to change smth can
flat wigeon
You can also sniff on the USB traffic ^^
I have different devices from different vendors (at work: G11 from Logitech and at home the Wooting Two + Roccat Kova+)
unreal sentinel
It helps you sniffing the usb help
torpid arch
@quiet root Eh, maybe. I think the answer is persistence.
flat wigeon
It was just formatting?
torpid arch
It's definitely mini-fined, but there are a few things that aren't. For example, the ld() function is a way of turning async functions into synchronous ones via generator functions and yield.
But the names are somewhat visible for some things. There's also some data structures that help a lot, and make thinks clear.
hazy locust
hey all, dumb python/mac developer here.
I'm running a lil python script that instantiates a class using the analog_sdk.dylib and ctypes, then waits for a spacebar.
When I try running it, I get the issue of 2020-04-16T17:38:37Z ERROR wooting_analog_plugin] Error opening HID Device: Failed opening hid device
quiet root
you're not supposed to use the analog_sdk dll directly, use the libwooting_analog_wrapper
https://dev.wooting.io/wooting-analog-sdk-guide/analog-api-description/ / https://github.com/WootingKb/wooting-analog-sdk/blob/master/SDK_USAGE.md
hazy locust
I tried using the analog_wrapper.dylib, but then the class was failing to even see if the kb was connected
(though is_initialised returned true)
This is the script
full disclosure I'm a researcher trying to record pressure in addition to response times, not a professional developer
placid ledge
Are you still getting that error that you previously mentioned? Is there any other info in the output?
hazy locust
I am still getting that buffer crash, but this new issue occurs in jupyter or when running the python script I linked - I'll need the script to work since we can't run experiments in notebooks
This is the output I get from the script
setting up kb
[2020-04-16T18:51:09Z ERROR wooting_analog_plugin] Error opening HID Device: Failed opening hid device
> Checking if keyboard is connected...
WAITING FOR SPACE
[2020-04-16T18:51:09Z ERROR wooting_analog_plugin] Error opening HID Device: Failed opening hid device
[2020-04-16T18:51:10Z ERROR wooting_analog_plugin] Error opening HID Device: Failed opening hid device
[2020-04-16T18:51:10Z ERROR wooting_analog_plugin] Error opening HID Device: Failed opening hid device
[2020-04-16T18:51:11Z ERROR wooting_analog_plugin] Error opening HID Device: Failed opening hid device
Have you updated your keyboard firmware to latest stable?
hazy locust
Have you updated your keyboard firmware to latest stable?
@placid ledge yes!
wootility says so at least
placid ledge
Alright, wootility is at least version 3.4?
hazy locust
3.4.6
placid ledge
Also, could you run your script with the RUST_LOG environment variable set to "debug"?
Solid
i.e. RUST_LOG=debug python woottst.py
That should give more logging output which will hopefully have some more info we can work with
placid ledge
No worries, having a look through atm
hazy locust
here's the highlights though:
[2020-04-16T18:59:58Z WARN wooting_analog_sdk::sdk] Failed to load any plugins from "/Library/WootingAnalogPlugins"!
[2020-04-16T18:59:58Z INFO wooting_analog_sdk::sdk] Attempting to load plugin: "/Library/WootingAnalogPlugins/wooting-analog-plugin/libwooting_analog_plugin.dylib"
[2020-04-16T18:59:58Z INFO wooting_analog_sdk::sdk] Plugin got plugin-dev sem version: 0.4.0. SDK: 0.4.0
[2020-04-16T18:59:58Z INFO wooting_analog_sdk::sdk] Plugin and SDK are compatible!
[2020-04-16T18:59:58Z DEBUG wooting_analog_sdk::sdk] We got it and we're trying
[2020-04-16T18:59:58Z INFO wooting_analog_sdk::sdk] Loaded plugin: "Wooting Official Plugin"
[2020-04-16T18:59:58Z INFO wooting_analog_sdk::sdk] Loaded 1 plugins from "/Library/WootingAnalogPlugins/wooting-analog-plugin"
[2020-04-16T18:59:58Z INFO wooting_analog_plugin] Found device impl match: HidDeviceInfo { path: "IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS09@14400000/USB2.0 Hub@14400000/AppleUSB20Hub@14400000/AppleUSB20HubPort@14410000/WootingOne@14410000/IOUSBHostInterface@6/IOUSBHostHIDDevice@14410000,6", vendor_id: 1003, product_id: 65281, serial_number: Some("WOOT_001_A01B1904W011H01310"), release_number: 64, manufacturer_string: Some("Wooting"), product_string: Some("WootingOne"), usage_page: 65364, usage: 1, interface_number: -1 }
[2020-04-16T18:59:58Z ERROR wooting_analog_plugin] Error opening HID Device: Failed opening hid device
very informative
placid ledge
It's hard for me to fully debug it as I'm not super familar with Mac. My best guess is maybe a permissions issue? It's annoying the error given for opening the Device is pretty barebones
You're able to get the rgb sdk working?
hazy locust
all I've tried is using the rgb sdk's is_connected function, which works if I use the analog sdk to initialise, but not if I use the analog-wrapper
I tried running the script as root w/o change
placid ledge
The rgb sdk is unrelated to the analog sdk. I'm confused about what you mean by it working when using analog sdk to initialise not the wrapper?
hazy locust
when I try the sequence of commands
wp = WootingPython()
wp.initialise()
wp.is_initialised()
wp.get_info()
wp.is_connected()
and in my class it's calling on the analog-sdk.dylib for the 1st 3 and rbg-sdk.dylib for the last, I get a final output of true.
When it's calling on the analog-wrapper.dylib for the 1st 3 instead, the last output is false
that behavior has been consistent across a few attempts
placid ledge
Hmmmm, that's weird
Could you try only initialising the analog sdk with the wrapper?
placid ledge
Have you had the scripts running simultaneously? Because from looking around mac specific issues for the hidapi library it appears that the interface may be opened exclusively so having multiple instances may be problematic
hazy locust
oooooo
how about that
I'll kill the notebook!
what a game changer
that solved that!
Now my script won't read in the spacebar input haha
what progress though
placid ledge
In your code you've listed the code as SCAN_CODE_SPACE, are you using the scan code keycode set then?
Because you'll need to set the keycode mode to scancode if you're using that set
I get 0x2C keycode for space bar
In the default keycode set used by the analog sdk(HID)
Also, for your wait_for_key method you can call the read_analog method for the specific key rather than waiting for read_full_buffer
hazy locust
That is what I get for copying indiscriminately and then hoping to fix afterwards
I tried replacing SCAN_CODE_SPACE with 0x2C, but the problem persists
is read_full_buffer very slow?
placid ledge
Hmmm, weird. It's not very slow, but for getting a single key result, it's better to use read_analog
You could also output the results you're getting from read_full_buffer to see what it's giving when you press the spacebar
hazy locust
ya the scan_codes and analog_vals are coming out as []
eventually the script dies w/ a segmentation fault
could it be that my buffers are no good
hazy locust
[MAC] does anyone have experience using python to read in HID keys from the wooting one? the examples I can find online use scan codes (https://github.com/andrewramsay/wooting-python-logger-example/blob/master/logger.py)
or an enum setup (https://github.com/BattleCisco/pyWooting/blob/master/reader.py)
And I'm wondering if my issues are coming from this.
Specifically, I seem to be failing to read out from the buffer, and I eventually get a segmentation fault 11, indicating the script is using too much memory or allot resources it does not have access to
placid ledge
The way you're calling the read_full_buffer seems a bit off. Have a look again at the function signature here: https://github.com/WootingKb/wooting-analog-sdk/blob/master/SDK_USAGE.md#read-all-analog-values
You should have 3 parameters, the first 2 being the two buffers for the code_buffer and analog_buffer respectively
You could be getting the segmentation fault due to the fact that the 2nd parameter you're giving is the len and not a buffer pointer. Meaning that it will try and assign data into a buffer at address ~32 which is likely not valid
hazy locust
rad, I will try to make this change and see what happens
placid ledge
I can imagine that potentially the reason why you don't hit the error immediately is due to the fact that it'll only attempt to fill up the buffer if you have at least one key pressed
hazy locust
bless
you
@placid ledge
expect acknowledgements in the paper (many years from now)
valid nexus
Hrm, wooting_analog_uninitialise() causes a segfault on my machine.
Also, on the first run wooting_analog_initialise() appeared to work correctly, but on subsequent runs I get the output...
0.000000100 deps/dpb/src/log.c:59 [INFO] Version : 1e56f58-dirty
0.000470300 deps/dpb/src/win32.c:583 [INFO] Platform : win32
[2020-04-20T13:47:48Z WARN wooting_analog_test_plugin] Error : OpenFileMappingA failed with 2
[2020-04-20T13:47:48Z WARN wooting_analog_test_plugin] Attempted to open exist SharedMemFailed... Falling back to creation
[2020-04-20T13:47:48Z INFO wooting_analog_test_plugin] Some("C:\\msys64\\tmp\\wooting-test-plugin.link")
[2020-04-20T13:47:48Z INFO wooting_analog_test_plugin] init
Segmentation fault
woot_init() still returns the correct output, but those log messages...
the code that does that is...
WootingAnalogResult woot_ret = wooting_analog_initialise();
if( woot_ret != WootingAnalogResult_Ok )
{
log_warning("wooting_analog_initialise() = %d", woot_ret);
}
wooting_analog_uninitialise();
gcc.exe (Rev2, Built by MSYS2 project) 9.2.0, win10, wooting2, latest everything, linking with -L'C:\Program Files\wooting-analog-sdk' -lwooting_analog_sdk, header files copied from current master (138a9db
) at https://github.com/WootingKb/wooting-analog-sdk and dll installed by the wootility, it claims latest
flat wigeon
I have the same issue but using VS2019 with Clang. Also the same thing happens with the wrapper.
quiet root
kristall mind sending me the project?
unless its some secret code
then ill quickly whip smth up
flat wigeon
Compile as Release x64
This is a minimal example. I forgot to set the toolchain to Clang here, but the original project used Clang. Still the same thing happens
valid nexus
using the wrapper produces the exact same results
unreal sentinel
I hate the word wrapper
valid nexus
oh wow... managed to crash the keyboard
// gcc wooting.c -owooting.exe -Ideps/include -L. -lwooting_analog_wrapper -lwooting-rgb-sdk64
#include <windows.h>
#include <stdio.h>
#include <wooting/wooting-analog-wrapper.h>
#include <wooting/wooting-rgb-sdk.h>
int main(int argc, char* argv[])
//int APIENTRY WinMain(HINSTANCE hCurrentInst, HINSTANCE hPrev, LPSTR lpszCmdLine, int nCmdShow)
{
WootingAnalogResult woot_ret = wooting_analog_initialise();
if( woot_ret != WootingAnalogResult_Ok )
{
printf("wooting_analog_initialise() = %d\n", woot_ret);
}
bool woot_rgb = wooting_rgb_kbd_connected();
if( !woot_rgb )
{
printf("no rgb\n");
}
wooting_rgb_direct_set_key(1,1, 255,0,0);
Sleep(1000);
wooting_rgb_reset();
wooting_analog_uninitialise();
return 0;
}
Program output...
$ gcc wooting.c -owooting.exe -Ideps/include -L. -lwooting_analog_wrapper -lwooting-rgb-sdk64 && ./wooting
[2020-04-21T01:25:29Z WARN wooting_analog_test_plugin] Error : OpenFileMappingA failed with 2
[2020-04-21T01:25:29Z WARN wooting_analog_test_plugin] Attempted to open exist SharedMemFailed... Falling back to creation
[2020-04-21T01:25:29Z INFO wooting_analog_test_plugin] Some("C:\\msys64\\tmp\\wooting-test-plugin.link")
[2020-04-21T01:25:29Z INFO wooting_analog_test_plugin] init
thread 'Timer thread' panicked at 'called `Option::unwrap()` on a `None` value', /rustc/5e1a799842ba6ed4a57e91f7ab9435947482f7d8\src\libcore\macros\mod.rs:15:40
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
[2020-04-21T01:27:36Z ERROR wooting_analog_plugin] Failed to read buffer: hidapi error: The device is not connected.
[2020-04-21T01:27:36Z ERROR wooting_analog_plugin] Failed to read buffer: hidapi error: The device is not connected.
Segmentation fault
The last two lines "failed to read buffer" is where I unplugged the keyboard
yeah that's the RGB api that's crashing the keyboard
flat wigeon
You should not use wooting_rgb_direct_set_key() anyway, as it doesn't work for the numpad block of the W2.
valid nexus
why doesn't the docs mention this? Seems like for changing a single key this is the exact function to be using
I think the bigger point is that within the first 30 minutes of playing with the rgb sdk I've managed to hang the keyboard. Seems like a bit of an issue there.
real prairie
You should not use wooting_rgb_direct_set_key() anyway, as it doesn't work for the numpad block of the W2.
Maybe that is the reason why you managed to hang the keyboard when playing with rgb.
valid nexus
where is that mentioned anywhere in the documentation?
real prairie
if that is the case and it is not mentioned in the docs that would be an issue. But I did not read the docs so I cant say if says you shouldnt use that
valid nexus
it doesn't, so I stand to the original point, it crashing the keyboard is an issue, and I'll take kindly for opinions about what should and should not be done to be kept to themselves.
flat wigeon
To me it looks like they forgot to update the firmware to allow numpad keys to be changed directly.
Regarding the hangup, are you sure to keyboard didn't respond anymore? Did you try the mode key?
valid nexus
mode keys do nothing
flat wigeon
Keypresses are still not registered?
valid nexus
nothing until I unplug the keyboard
flat wigeon
I was able to hangup the keyboard too, but I didn't expect it to be that easy.
The keyboard seems to have some race condition issues with the RGB lighting
valid nexus
given how rock-solid it's been in my admittedly single week playing with the keyboard, I'm inclined to point fingers at teh sdk at this point... it's not like windows is renowned for having the most robust api's out there
I guess time to start speaking HID directly to test that theory
actually a better plan might be to try to duplicate the hang on other platforms. Race condition in a keyboard leaves me scratching my chin... I would assume the keyboard cpu is single threaded... how could a race condition happen? I'd expect all the usb comms to be buffered and processed when the firmware thinks it's appropriate
flat wigeon
Enable Tachyon mode and press Caps Lock and Num Lock simultanously a few times.
flat wigeon
Btw. why do you want to set the color only for one key?
valid nexus
right now, for hello world. I also wanted to test if it interferes with the pressure indicator along the F? keys. Later, just general habit of change as few bytes as possible.
flat wigeon
You know... 0nce the RGB SDK locks the keyboard, the indicators for Caps Lock and Num Lock won't be updated anymore, so you have to handle these yourself if it matters.
And I recommend you better send the lock command (WOOTING_COLOR_INIT_COMMAND), otherwise the keyboard will reset all colors if you press either Num Lock or Caps Lock.
valid nexus
good to know
placid ledge
I had a look into the issue you were running into with wooting_analog_unitialise causing a segfault. If you're running into it still I wouldn't worry too much about it. I wasn't able to replicate it on Linux on the latest develop branch. However, it's not a massive deal if you don't unitialise when you're exiting your application, as it just performs some non-critical cleanup. You can just leave it out for now while I try and get to the bottom of it.
For the issue with the keyboard locking up with the RGB sdk, that is a weird one, I haven't come across that
I'll also have a look into not being able to use direct_set_key on the Wooting Two numpad, as I hadn't heard of that issue until now
Also, as an aside, you can safely ignore these log messages
[2020-04-21T01:25:29Z WARN wooting_analog_test_plugin] Error : OpenFileMappingA failed with 2
[2020-04-21T01:25:29Z WARN wooting_analog_test_plugin] Attempted to open exist SharedMemFailed... Falling back to creation
[2020-04-21T01:25:29Z INFO wooting_analog_test_plugin] Some("C:\\msys64\\tmp\\wooting-test-plugin.link")
[2020-04-21T01:25:29Z INFO wooting_analog_test_plugin] init
The output it's giving you is a bit misleading and shouldn't be being displayed to you by default as there isn't actually anything going wrong there. In the latest develop this has been resolved so only relevant errors are presented to you, but until a new update is pushed, you can safely ignore those messages
If you continue facing issues, let me know. As currently, I'm the main person looking after the SDK's and I want to make sure they're working for everyone
flat wigeon
I wasn't able to kill the keyboard using the RGB SDK. However the keyboard stops responding if you update colors of single keys (without the lock command) while repeatedly pressing either Num Lock or Caps Lock.
But I could imagine that issue could be reproduced with the RGB SDK as well., if two applications use the same device and one application resets the keyboard colors...
strong siren
I think I've had something similar to the caps lock + rgb sdk happen to me as well but I can't remember the exact details
It's probably in this server somewhere though
valid nexus
I've set profile A1 to be red, with the pressure gauge on the function keys. I was setting a single key (in this case the 1-! key) to green, and calling sleep(5000), so that I could push a key and see if the pressure gauge still worked. This is what is fairly consistently causing the keyboard, and the program, to lock up. Unplugging the keyboard fixes both. I'll see if I can replicate this on other platforms hopefully tomorrow.
chilly oar
@valid nexus The W2 support was added very late to the RGB SDK, so maybe there are some issues when it comes to the additional keys. Maybe try this fork: https://github.com/GottZ/wooting-rgb-sdk
Either way, as far as I know the RGB SDK and the analog SDK should be independent from each other. So if there is a crash on the analog SDK it should have nothing to do with the RGB SDK and the other way around.
And as mentioned you need indeed initialise the RGB mode first before you sending any RGB values to the keyboard and you need to close that mode if you are finished otherwise the RGB don't change anymore.
flat wigeon
Firmware issues go to the wootility-issues repository?
chilly oar
@flat wigeon Yes, you can post it there.
grizzled wolf
Hey, in the linux wootility appimage you can have RGB effects enabled at the same time as tachyon mode, is this intended?
grizzled wolf
Only some work, for example ripple and trail do not work
hybrid lake
It's not intended, the RGB effects will not work well with Tachyon mode enabled. In the next update we'll make this more clear in the UI
grizzled wolf
well they're working just fine, not sure if the scanrate is stable though
hybrid lake
Yeah the problem is that it influences the scanrate and thus pretty much neglects the Tachyon mode improvements. Plus the analog effects don't work properly, because we use some digital optimisation.
grizzled wolf
I was wondering, what if instead of having the keyboard emulate a controller (which leads to games derping out) we could emulate digital keypresses for a similar result?
For example i could set a cycle speed (ex: 20ms), then i could keep the selected key pressed for a percentage of time based on how deep it's pressed.
For example if i press the W key 40% of the way, i'd hold W for 8ms, release it for 12ms and repeat.
this would work on most games that would usually derp out like six siege since it's all keyboard inputs
i could do this myself with the sdk, though i don't have the keyboard yet
i was wondering if there's a clean way to do this.
I'll want the keyboard to operate in digital mode so that no controller is detected from the game, however i still want to read the analog values.
i could bind the keys i'm interested in to something odd like F13+ (either in game, so they keyboard still uses wasd for example, or in the keyboard with DKS since rebinding isn't a feature yet), then i read that value and output the repeated keypresses
the obvious issue with that solution is that the keyboard inputs a key, i read it and output a different key, which is doable but it's annoying to setup for different applications
i was wondering if it's possible to read the analog value of the W key (for example), output digital keypresses of the same key and have whatever application is currently active not detect a controller
thus having the program act like a middle man, discarding the analog input and replacing it with digital
TLDR:
hold W 25% of the way -> W---W---W---W---
hold W 50% of the way -> WW--WW--WW--WW--
is that possible or would i need to change the keys being used?
like this: hold W 25% of the way -> F13---F13---F13---F13---
The goal is to improve compatibility, this is the same as tapping the keys for an "analog" result with normal keyboards (i'm sure we all did this at some point with driving games), but so quickly the user would be unable to notice, thus avoiding the need to emulate a controller.
flat wigeon
Of course you could do that
But all this funky tricks have their own downsides
I did think about implementing something like this for World of Tanks, as this game doesn't even have gamepad support
But depending on the game you have to live with weird animations due to repeated keypresses, if you do that
Also you may accidentally spam a key, when for example in a menu, which can have undesirable side effects.
grizzled wolf
yeah ofc it's not a perfect solution
but it's a fair middle ground
i'm curious as to whether it's possible to take the W analog input, output that as W keypresses and not have the game recognize it as a controller without having to go through a secondary key
like reading analog W input, outputting F13 keypresses and having the game read those
flat wigeon
Do you know Pudge Wars from Warcraft III TFT?
I mapped my Gamepad on Keyboard + Mouse Inputs
Precision -20, Reaction +20
And to be honest, I don't think this is something that should be implemented in Firmware
You are limited in what you can do in firmware, because you don't have a view of anything that happens in the OS
grizzled wolf
im not familiar with that tbh x)
i'm mainly interested in making a personal solution
if it works well then we can consider having that be a default option
flat wigeon
Ah and I forgot another issue, depending on the programming, you need to synchronize with the games framerate.
grizzled wolf
that can be done by setting the cycle speed
though games nowdays aren't that picky
it's not a perfect solution but it helps.
It should work perfectly for stuff like MGSV, 6siege, helldivers (idk if it works already for it) and the likes
but yeah my main concern is whether i'd have to use 2 keys or just 1.
since to use only one i'd need to essentially ignore the keyboard input and only use my program's input instead (keyboard presses W, i 'trash' that and replace it with my own keypress logic)
little monolith
@grizzled wolf that would just be awful in terms of the experience you’d be getting
grizzled wolf
how so, you'd barely feel the difference as long as the cycle speed is high enough
little monolith
assuming you implement something with account for up and down events, the frequency of the game handling the input etc
you’d get super jittery movement, most likely
grizzled wolf
a normal macro for it works just fine
the main issue is i can't tweak it in real time
little monolith
also i’d imagine quite a bit of games don’t let you move right after you press the key
grizzled wolf
??
little monolith
i can easily think of gta 5 as the example
because of the animations, doing what you described would be impossible
grizzled wolf
i mean i know it works cause i've tried it with a macro editor in the past, i'm mostly wondering whether i'd have to go through 2 keys (keyboard presses W, program detects W, sends F13 keypresses, the game is bound to F13) o just one (keyboard presses W, program detects it, trashes the keyboard keypress and sends W digital keypresses)
little monolith
input in most games is handled with window events
grizzled wolf
can't say i tried with most games i guess x)
little monolith
the os fires an event at the active window every time a key changes its state to either up or down
grizzled wolf
though usually (read: almost always) they're buffered and that leads to fairly decent results
though based on the animation type it can be messy
still better than the alternative (which is: nothing works)
little monolith
why would down and up events of the same key be buffered?
grizzled wolf
here let me show you an example
1 sec i gotta process the video
in this example i press D for 10ms, release it for 10ms, repeat
looks buttery smooth to me
@little monolith
usually there's a transition period between animations, or the animations themselves are fairly similar. as long as either is true the effect is invisible to the user
for example this method is practically unusable in Hades since you go from stationary to half-way through the running animation in a single frame
grizzled wolf
anyway im still looking to know whether i can do this with 1 key or if i'd need 2
;)
fathom garnet
think @placid ledge is the one who should know it for sure, given he wrote the sdk :^)
grizzled wolf
summoning simon
btw i'll add these here as well to show how this looks like with cars in gtav
orchid pebble
doing analog on a normal keyboard is called , manual pwm
hybrid lake
I remember someone wrote an AutoHotKey script once that outputs PWM from the Directinput joystick
grizzled wolf
googling AHK pwm or autohotkey pwm leads to nothing though
grizzled wolf
but yeah doing it myself actually doesn't seem bad at all, the AHK wrapper looks very thicc
grizzled wolf
i've been looking at the AHK wrapper and i'm not sure what blocking a key does.
If i block a key but don't add a function is that key essentially disabled until i unblock it?
So for example if i use:
wootingKey .= Wooting.AddKey(GetKeySC("W")).SetBlock(true)
then the W key is completely disabled in all programs?
cause if so that'd be really good
I've also been trying to look for the same option in the C# SDK but i couldn't find it
hybrid lake
I think I still have the script on my old laptop, I didn't make it myself, let me check monday
grizzled wolf
though to be fair doing it myself with the ahk wrapper sounds like more fun :P
trail pollen
I have a question, if code is written with the current source development kit will it need to be later optimized for the lekker edition wooting two?
fathom garnet
unlikely, might just want to adjust numbers since the analog curve can start earlier
but otherwise you basically work with values from 0-255, don't see much changing there
grizzled wolf
now i have quite an interesting dilemma
looking at the ahk wrapper i can specify a window, can i set multiple ones like this?
.OnAnalog(Func("notepadFunction"))
.SetWinTitle("ahk_class Notepad")
.SetHotkey(true)
wootingKey := Wooting.AddKey(GetKeySC("A"))
.OnAnalog(Func("firefoxFunction"))
.SetWinTitle("ahk_exe Firefox.exe")
.SetHotkey(true)```and can i have a "default" option that is used when none of the windows are found?
or would i need to make 1 function and check the current title myself and execute the correct function (meaning i'd be unable to use .SetWinTitle)?
if i can have a default + a window-specific function for any amount of keys i could essentially recreate something like ghub/steelseries engine
by having a program with a user friendly gui that exports AHK scripts
grizzled wolf
hmm i thought my idea of using AHK to quickly tap keys to simulate analog input was good
but actually AHK's timer precision is kinda trash
grizzled wolf
ok, question:
what would the c# equivalent of this be?
wootingKey := Wooting.AddKey(GetKeySC("A"))
.OnAnalog(Func("DoNothingAtAll"))
.SetBlock(true)
.SetWinTitle("ahk_class Notepad")
.SetHotkey(true)
return
DoNothingAtAll(value){
}```essentially the goal here would be to disable the A key (the function does nothing), when in analog mode, while the notepad is open
also i know i can use Function wooting_rgb_sdk_sys::wooting_usb_send_feature to set a profile (ty copvampire), however can i also see what the current profile is?
p.s. odd how that function is so useful and yet i had to dig in this link to find it: https://docs.rs/wooting-rgb-sdk-sys/0.1.0/wooting_rgb_sdk_sys/index.html, plus i can't quite tell what it does beyond seeing what copvampire did with their profile switching script
strong siren
There's another command with that same send features that tells you which profile is active
The list of those commands is pinned in this channel
grizzled wolf
Oh i missed it, neat
right now my doubt is whether i can block the keys with c# (or maybe python, stonks), like i can with AHK.
for example in the AHK example above if i were to press the A key in analog mode nothing would happen
blissful willow
Any chance of Wooting open sourcing the firmware code? I know it's just ATMega code, and the firmware for MacOS is quite buggy and I'd like to fix it.
placid ledge
I have a question, if code is written with the current source development kit will it need to be later optimized for the lekker edition wooting two?
@trail pollen @fathom garnet
Just noticed this and would like to throw in that the Analog SDK was designed with Lekker in mind. The analog values you recieve are a float between 0-1 so your code should work with Lekker without any modification due to the SDK's updating architecture
fathom garnet
oh its floats now? neat, thought it was using a byte as range
placid ledge
Ye, the old SDK was just on bytes, but the new one was designed to use floats
grizzled wolf
still wondering if i can block a key like AHK, but with the c# sdk instead.
meaning whatever program is currently active detects no input (same as the AHK snippet above where i assign an empty function)
placid ledge
There is the potential option for disabling digital keys on the profile you're using
Won't necessarily work ideally without app based profile switching, but that is coming soonTM
grizzled wolf
oho good to know
so that means that if the keyboard is in analog mode and i press a key (either half-way or bottoming out) i can read the analog value and also prevent any input from being detected?
that way i can have a small program that takes the analog input of let's say the W key and then taps the W key quickly to kinda emulate the analog input
placid ledge
Well, the disabling of digital keys disables regular key input for all keys on the keyboard
placid ledge
Currently that's not possible through the firmware, not entirely sure what userspace options you have
grizzled wolf
with AHK the moment i assign a hotkey (like the snippet) it's the same as if i never pressed the key, so that'd be spot on
but AHK isn't precise enough to quickly send the keypresses
so i kinda have to find a different solution x)
flat wigeon
Shouldn't it be possible to disable one key through DKS?
grizzled wolf
yeah but then i reckon i'd not read the input either, would i?
plus i'd be limited to 20
placid ledge
afaik you should be able to read the analog values from the keys with the analog sdk no matter what
grizzled wolf
maybe the remap update also lets me unbind a key completely
which kinda gets a similar result
or i have the actuation distance on interested keys maxed out and only run the script when the key isn't bottomed out
placid ledge
Correction to my previous statement, unbinding a key with remap update will not produce analog values through the sdk
grizzled wolf
oof
placid ledge
Theoretically, seeing as you're emulating keyboard input in general, you could use a profile with digital keys disabled and just emulate the rest of the keypresses normally
grizzled wolf
side note, i wonder if this kind of feature could ever make it to wootility
for games that don't support controller + mouse
placid ledge
Well, assuming it works, we'd definitely explore the possibility of it
grizzled wolf
sometimes it's janky, like mgsv, other times it's better than analog like gta5
placid ledge
It doesn't necessarily need to work in all cases, because, as you can tell, analog doesn't work perfectly in everything as well. Could be an interesting option to have. Although, I haven't looked into it/used it so I can't really say anything definitive at the moment
grizzled wolf
fingers crossed then!
memory-wise the existing analog curve + a loop time (ex: 100ms) should be enough
flat wigeon
If you are sending feature reports which are answered with an input report... don't start Wootility while your program is running
This way I messed up my keyboard settings several times
And fn + Pos 1 became "max volume", every single time
grizzled wolf
oh?
is there no way to reset that? :O
(also not sure what you mean with feature/input reports)
flat wigeon
I need to reset all keyboard settings to undo that
wooting_usb_send_feature() sends a feature report to the device. depending on the report the device answers with an input report
But seemingly if Wootility and a third party application send feature reports at the same time, wootility receives the input reports meant for the other application too and misinterprets it.
blissful willow
Any response to my question w.r.t. open sourcing the firmware?
quiet root
they wont
same way they wont opensource the wootility
its a management nightnare for such a small team
maybe in the future but my guess is no
hybrid lake
@grizzled wolf found a AHK script, not 100% sure if this was the good one
grizzled wolf
looked at the script
grizzled wolf
it's a bit janky since it doesn't control how long the keys are pressed, which is a sure way to get jagged movement.
plus the 1ms sleep of AHK actually ends up being 15-16ms, adding further delay.
However the concept is the same
hybrid lake
Yeah I remember it being more advanced, this seems pretty basic. Maybe it's different than I remember
grizzled wolf
i'm working on it but AHK is memeing me
grizzled wolf
ok i got it to work in notepad, but it refuses to work ingame, smh
and now it works!
i have a very high deadzone since my controller has a bit of drift, making it awkward at low speed
but it's otherwise almost perfect
i'll get a gif ready
caveat: this script is super duper CPU intensive, AHK has either 15ms accuracy or 0.01ms accuracy with no in-between
there are 2 variables called 1JoyX and 1JoyY, those must be changed between 1 and 16 until the script works.
cycleDuration is how long a cycle lasts, less is better generally but it depends on the game (gta5 works better with a longer cycle).
deadzone is the deadzone, duh, probably useless on the wooting
the only downside of this script is that it's unresponsive as it won't check for new input until the current cycle ends, this could be changed with a bit of extra code but it's good enough to showcase how it works for now
i picked helldivers for the gif since controller + mouse doesn't work with it
fierce ember
hi I want to open wotility's analog binding setiing 1,2,3 file and checking code
How can i do this?
quiet root
?
grizzled wolf
Found a bit of a hacky way to improve AHK's sleep resolution without nuking cpu performance
i also added better responsiveness to controls (the ones i mentioned beforehand but didn't feel like doing)
each input has between 0 and 2.4ms of delay, but that seems to be close enough
ashen dune
try timer resolution to improve it to 0.5 ms
grizzled wolf
what do you mean?
oh i totally forgot a variable lol
fixed
timePeriod worked best at 3ms for me, not sure why but going lower makes it less precise
aside from a busy sleep there's no way to improve this further i reckon
though it works well
ashen dune
@grizzled wolf I mean that the lowest possible system resolution time on windows is 0.5ms
grizzled wolf
i got the best result with 3ms, 1ms actually makes the delay even higher
but yeah tweak with it and see if there's any improvement
either way it's an imperfect solution
ashen dune
but it's only settable via timerresolution program, https://cms.lucashale.com/timer-resolution/
windows usually doesnt go beyond 1ms itself
ashen dune
the program goes to 0.5ms
flat wigeon
lulz
10 Dollar for a program which takes like... an hour to program?
Technically... if AHK offers timers, it is also responsible for setting the timer resolution.
ashen dune
u can check which program requested 0.5ms
quiet root
exactly
real prairie
but current is .49
real prairie
that is not German precision engineering
ashen dune
most programs probably request 1ms
quiet root
actually no
ashen dune
no?
ashen dune
10000 means 1ms
real prairie
so 100²
quiet root
ya i forgot about 1 unit being 100ns
grizzled wolf
🤔
quiet root
and not 1ns
grizzled wolf
but yeh either way AHK is just not precise, regardless of the clock
it's precise enough but no cigar
grizzled wolf
even just the keypress itself takes about 0.5ms
it all adds up
but yeh the script sets the timer resolution already, pick you favourite value and see if it helps. :)
ashen dune
what do you mean with this anyway? "each input has between 0 and 2.4ms of delay, but that seems to be close enough"
how did you measure that
@grizzled wolf ?
grizzled wolf
with 2 timers
the QPC function, which is already in the script, is accurate down to the 0.00001 ms
so what i do is look at the time
ashen dune
That 0 - 2.4ms is suspiciously same as Wooting's total delay btw
grizzled wolf
send a keypress
then look at the time again
the 0-2.4ms is AHK's fault
something like ghub, steelseries engine, synapse and similar have no such issue
in the end the script works
but not as well as a proper solution
imagine your fingers are permanently shakey
ashen dune
How do you know it's AHK's fault?
grizzled wolf
i mean... i timed it? x)
even the folks in the AHK discord know it's a touchy subject
ashen dune
I'm just trying to understand and I'm not understanding your method.
grizzled wolf
well
i did a few steps
first i run the QPC function
then immediately run it again
and see the difference
0.0024ms (approx, going by memory)
so QPC is quick
i now add a SendInput call
and suddenly it's 0.49 - 0.51 ish
ashen dune
so you're not physically pressing a key?
ashen dune
right
ashen dune
?
grizzled wolf
so i dont have to run it every time
i press F12, the script runs
so i can just mash F12
versus clicking the script x)
ashen dune
so you actually mash f12?
quiet root
how can qcp be 0.0024ms
grizzled wolf
travel distance doesn't matter
as soon as it detects the key is being pressed
it starts the timer
sends a virtual keypress
then checks the time
if i add a sleep(0) call (sleep for 0 ms) or a sleep(1)
i'll get 15-16ms, which is the main issue
ashen dune
so it starts the timer after actuation point is passed and windows has recognized key send?
grizzled wolf
setbatchlines -1 helps
improving the timer resolution helps too
but it won't ever be as precise
yes
keep in mind i dont have a wooting
just a puny digital keyboard
ashen dune
No idea how virtual keypresses work so cannot comment.
grizzled wolf
there are a few ways
Send, SendInput, SendRaw and SendEvent
the 2nd option is the fastest
and it's buffered
but it has less options
Send would be 2ms on its own
ashen dune
is it something done inside CPU or does it involve USB/keyboard in any way?
grizzled wolf
cpu
grizzled wolf
the only way to be more precise than this
is to use a busy loop
or something that isn't a janky scripting language
a busy loop is what i did in the first iteration of the script
and it's perfect!
ashen dune
have you tried windows 10 ultimate power mode?
ashen dune
I mean power settings.. if you running on a balanced could be cpu sleep timers
grizzled wolf
but yeh with a busy loop you get ez 0.01 ms accuracy no problem
ashen dune
so try high perf or ultimate perf
grizzled wolf
i run max power all the time hoho
grizzled wolf
the issue with the busy loop is that you can't use the sleep function
so it nukes your CPU :P
but yeah it works as-is
but you won't be able to have super short cycles
like 2-5 ms
which would make games like mgsv more bearable
ashen dune
grizzled wolf
i actually dont have that option
just balanced, high and power saving
either way thats not the issue i reckon
minimum processor rate is 100%
checkmate
ashen dune
Yeah Probably AHK but its cool to see what can be done 😉
grizzled wolf
ideally you'd have this script built into the keyboard itself
that'd be the end all be all solution
since it already has a busy loop
or
you make something like ghub
but ghetto mode
ashen dune
idk even what this script is
grizzled wolf
but i'm not going to make the same script in C#
ghub is logitech's suite
with macros, profiles n shite
ghub, steelseries engine, razer synapse and all the lesser ones
have 1ms accuracy
but they don't nuke your cpu like a busy loop would :P
and just in case
busy loop is a while(true){}
essentially a "sleep is for the weak" solution
on the plus side this system is accurate enough for macros to be viable
i can make something in java/python/whatever that stitches AHK scripts together to make profile switching and macros, on top of this feature
which was my goal all along
i can even have a default profile too
ashen dune
w8'n for Wooting Macros 8)
grizzled wolf
according to the devs
that's a lot of waiting
on the plus side the remapping interface looks amazing to assign macros with
@quiet root sorry i totally missed your question
qpc is that precise cause i don't have any sleep
it reads the current time in ns
quiet root
i mean yes it queries the win32api
but
shouldnt the call rely on the nt timer
as in the currently set resolution
grizzled wolf
that timer resolution is a system clock, it affects stuff like sleeping
there's a reason the picture you linked earlier uses ns rather than ms
:3
the 0.5ms limit isn't a hardware limitation either
it's just windows asking us to chill
quiet root
use linux easy fix
grizzled wolf
ah yes the OS without AHK :P
quiet root
use c
grizzled wolf
i could
and for this specific feature, maybe i would have
but my end goal is to make a ghetto ghub/synapse/steelseries engine/whatever
with a program that just creates AHK scripts
this allows me to make macros with AHK (which has GUI programs to do just that)
essentially i'd have a macro folder which just contains functions that do stuff, made with a macro creator
then a profiles folder which contains the macros stitched together into a profile
i then end with 1 giant AHK script that lets me set different macros for any number of executables and analog support
quiet root
uh
how bout
sleepMS(ms)
{
DllCall("QueryPerformanceFrequency", "Int64*", freq)
DllCall("QueryPerformanceCounter", "Int64*", CounterBefore)
DllCall("QueryPerformanceCounter", "Int64*", CounterAfter)
while((CounterAfter - CounterBefore) / freq * 1000 < ms)
{
DllCall("QueryPerformanceCounter", "Int64*", CounterAfter)
}
}
jank solution but it works
grizzled wolf
that is a busy loop
welcome to solution number 1
instead of <1000
make it <100000000
and check your cpu usage
grizzled wolf
imagine using resource manager : ^)
but yeah in my first script i had something similar
it spikes my cpu to about 10-12% usage
(which is unacceptable)
quiet root
lol it was so far down my list i only noticed the red plops of it going away when i killed the process to find it
not too bad imo
grizzled wolf
it caps at 12%
to prevent you from nuking yourself
that's just windows being kind to you
balmy iron
Or maybe because a busy loop like that is probably only going to pin one core/thread
quiet root
ahk is not multithreaded id guess
quiet root
like move to highest core available
since thats prob not used the most
and windows will push games onto the first cores most likely
grizzled wolf
not only that
this is kind of a bad busy loop too
i had better accuracy with mine
but yeah between 0-2.4ms but negligible performance loss
and 0.2ms but you lose a core
i'm choosing the former x)
quiet root
i mean if those cycles are so pressure ud actually not use ahk by default
grizzled wolf
TimePeriod := 2
global start := 0
global end := 0
QPC() {
static PerformanceFreq, _ := DllCall("QueryPerformanceFrequency", "Int64*", PerformanceFreq)
DllCall("QueryPerformanceCounter", "Int64*", PerformanceCount)
return PerformanceCount / PerformanceFreq * 1000
}
ExitFunc(){
DllCall("Winmm\timeEndPeriod", "UInt", TimePeriod)
return
}
OnExit("ExitFunc")
F12::
DllCall("Winmm\timeBeginPeriod", "UInt", TimePeriod)
start := QPC()
DllCall("Sleep", "UInt", 65)
end := QPC()
MsgBox % "Sleep duration = " . (end - start)
return```this is the system i currently use
the above sleeps 65ms when pressing F12
timeperiod is supposed to be the timer resolution, where the minimum is 0.5
but it kinda makes no difference below 3
and that uses about 0% cpu x)
keep in mind it has no other logic attached to it, it's just the timer. it's part of the 2.4ms worst case scenario but not the only cause
either way the script works, it may miss a few beats but you'd barely notice
I'll also re-share the script in case someone wants to try it out, it got buried hard x)