yo just tryna increase my chances of my problem being resolved. does anyone here know how to properly set up wootingmidi?
#🤖│community_dev
raw birch
quiet root
please dont cross post
raw birch
didnt say that in the rules, will not cross post from now on
quiet root
its not really a rule but its also nice to have 1 question in 1 channel only so theres no possibility of multiple people answering in different channels
raw birch
understandable
still pagoda
Heyo,
so after a slight disappointment of default rainbow color scheme I wrote myself a script to calculate a precise rainbow colors, depending on where the key actually is. So far it only takes horizontal position of key in consideration, thus double line keys (both enters and num +) are not precise, but unnoticable difference.
That be told, I now actually understand why propper rainbow wasnt implemented, as the blue and green (along with cyan) are kinda long, compared to orange and red.
Which brings me to another question:
I noticed the lighting is actually controllable by api/sdk/interface (idk propper terminology here), and got interested in how quickly is keyboard able to change colors?
is it able to change each key color 60times/second? 30? 10?
what about partial updates? How many keys/s ?
placid ledge
iirc in Aurora it was indicating that an entire keyboard rgb update using the SDK was about 40/50ms which gives like 25/20 fps. So that's potentially around what you should expect. Obviously a lot of factors can influence that update time, so don't treat that as maybe more of an 'average scenario'. Would need to do more investigation to pull out exact figures for all your questions, but in general you should be able to do whatever you would reasonably expect to be able to do
still pagoda
Hmm, thats good.
Just to clarify, this is talking about full keyboard change key by key or "flushing" it in one step? If the latter, do you have an idea of how long it takes to update a single key?
Also thanks for answers
placid ledge
I believe Aurora uses the "Flushing" approach, i.e. a single full keyboard update rather. So there's only one communication with the keyboard at the end, rather than one for each key change.
I'm not certain exactly how long it takes to update a single key directly, but they are fairly costly compared to doing the single "flush". So I'd recommend using the entire flush approach if you're changing a significant number of keys. Whereas, if you're only changing a few, then doing the direct set key should be alright
still pagoda
Many thanks!
placid ledge
No problem! This is all kinda off the top of my heard right now, so if you need some further clarification on some parts then feel free to ask!
granite rover
quiet root
dont cross post please
finite river
@quiet root IEnumerable is the interface that exposes the enumerator. Functional difference, but ¯_(ツ)_/¯
quiet root
is it wrong enough yet?
finite river
Do NaN
quiet root
done
quiet root
didnt even know c# had a NIL keyword
finite river
It doesn't. I don't know of a compiler that does, actually.
finite river
But nil is English for zero, so that was my reasoning. Never used Ruby and only lua for WoW AddOns, but was totally unaware C Standard had a nil keyword
finite river
Gotcha.
balmy iron
Assert your dominance and just use NULL instead
balmy iron
Or 0, it's even shorter, so it gotta be more efficient
little monolith
NULL is a windows.h macro, yes
nullptr is essentially 0 but only used with pointers for readability
rare spoke
#define nil NULL
thorn echo
I just got here and I'm wondering - is there a community hub for wooting dev outside the 10 projects on the spotlight page? Looking through pinned messages, there was talk of starting one in June 2018
quiet root
not yet mostly due to other efforts of the woot team
floral crane
oh my god I didnt even see theres sdks for this, it gets better and better every day, the things im going to make 
AND ITS IN RUST, I must be in heaven
quiet root
just use the node wrapper 
i should prob give the node wrapper some more love in the future
flat wigeon
Did anyone here experiment with analog volume controls?
quiet root
i am almost positive we had this discussion already
flat wigeon
My question was if someone actually experimented with it ^^
quiet root
no real experimenting needed
flat wigeon
It is
quiet root
unless u want something crossplatform
flat wigeon
It's not about if it's technically possible
quiet root
so u just want someone to write it for you
flat wigeon
For example I had the idea to use the 3 keys for mute as an indicator too
quiet root
i mean its easy as this
write a small tool that changes volume
implement a small counter for how long its pressed
plug into a graph formula
then u can change the curve
the longer its held the further right on the curve ud be
the faster it decreses
or increases
as long as you dont need it to be cross platform
this is no magic and actual simple code
if we talk crossplatform then we start doing sorcery
flat wigeon
That's not what I meant
quiet root
then idk what u mean by experimenting
cause all of what u most likely want is 100% possible and just needs to be done by someone
flat wigeon
I mean I can bind the keys to change volume depending on the how far the key is pressed down. But then I could ask the next question how to indicate the current state.
quiet root
also easily done like above but instead of timing how long its pressed down u put in the analog value
flat wigeon
My current idea is to split the indicator across the the volume control keys using the brightness. Somehow like a traditional health bar.
quiet root
i mean questionable practicallity
flat wigeon
And I again I don't ask about if or how it's done
quiet root
but as easy as holding down a key
well the practicallity is why prob no one has done it
it would be more than unpractical compared to traditional volume media controls
while this would use the analog gimmick of the wooting
it would only really be useable with heavy springs
altho it might be easier on the lekker
due to larger travel distance we can measure
meaning more accuracy with lighter springs
tl;dr no one has written code that does it cause impractical (on current wooting boards with normal spring weights)
i mean have u even used a wootings analog features for smth like joysticks etc? @flat wigeon
flat wigeon
To be honest, only Spyro. I tried with Mechwarrior 5, but it didn't work out as expected.
And Spyro is gamepad
quiet root
cause most games that actually benefit from having some kind of analog control through various walking/driving speeds
benefit more from a curve that has steps
than an actual curve
would be pmuch the same for volume control
so ya well all wait and see how lekker does
maybe there we can do what u wanna accomplish
flat wigeon
Thank you for your ideas. I'll keep that in mind.
grizzled wolf
I mean I can bind the keys to change volume depending on the how far the key is pressed down. But then I could ask the next question how to indicate the current state.
@flat wigeon
If you want to press a button a tiny bit to increase volume, more than halfway to decrease it and bottoming out to mute/unmute, you can do it and the AHK wrapper is extra handy.
If the goal is to set the value to a percentage based on how far you press a key that is also possible, though probably not as usable.
flat wigeon
Funny idea, but I think you really need to be very precise to set the volume to the intended level. Even with Lekker Edition.
Actually... that IS an interesting idea. I could segment the volume levels into three regions. For example VolUp for -0 - -15 db, VolDown for -10 - -30 db and mute for -30db - -∞
silent cipher
@Kristallranke There is a tool called Volume2, maybe this interesting for you.
flat wigeon
More reasonable what MS offers per default
silent cipher
For Windows 10 I also like the App "EarTrumpet" to get the classic per-app volume but with the sleek new look.
Oh and it supports UWP apps too
Plus you can also popout the whole volume mixing panel
trail pollen
@clear hedge If you may please spare a moment was there not an example with discord for notifications somewhere? I am looking to build an applet that would display lights for the event of a programs notification.
quiet root
discord notifications are shared via ipc
blissful willow
Please please make the firmware open source.
I run into a few annoying firmware bugs from time to time that I'd be happy to fix
fathom garnet
they mentioned during the wootup about how they can't really do that while it is one of the bigger parts over competition
- all the reasons why wootility is not open source (yet)
blissful willow
Both are highly reverse-engineerable though. Your competition will have zero problem figuring them out.
E.g. I already enabled inspector tools on wootility, found your firmware bin links, reversed your strange text encoding thing, found out you're using atmel and loaded your firmware into IDA pro without any issue.
Took me 10 minutes. Your competitors will have zero issue doing the same.
I can't contribute back binary patches to you, though 😅
i.e. the stuck Fn key bug, the fact my modes reset every 5 minutes, etc.
quiet root
weont be open source anyway
while yes "easily" reversed
its still money the competition has to invest
the same way their wootility isnt super hard to extract the entire code from
1 command done
u get all js files
blissful willow
Not really, competitors invest this stuff all the time. Plus, I haven't even opened the wooting 2 to see how you have the atmel wired up. Assuming you're just using analog inputs, it would be very trivial to reproduce the firmware without RE.
Just because it costs doesn't mean it's not worth it.
quiet root
welp decisions are decisions
quiet root
not to mention they wont open source the wootility either due to different reasons
the pcb is no black magic either
anyone can open up the keyboard and get the traces
make another pcb
yet they dont opensource it
quiet root
they will prob fix a ton of bugs as soon as lekker is out and integrated into wootility etc
cause thats why most of the dev time is pmuch non existent
fathom garnet
and with Simon doing more stuff now, Jeroen should have some more time as well, not sure which one of them would be more likely to work on the firmware right now
unique holly
Quality of life such as the ugly non rounded corners around the iso enter. That one is just outragous.
JK
quiet root
simon already pulled the rgb sdk ahead a few years of dev time if jeroen was alone
wait analog sdk
rgb isnt rewritten yet
clear hedge
the rgb sdk is shockingly behind 😛
quiet root
simon is working on it
clear hedge
I know 😂
quiet root
and then we have nice sdks
hybrid lake
woops didn't read helpdesk yet
open minnow
Hey everyone! I'm interessted in writing some small projects for the wooting keyboard using Rust.
I checked out the crates, and is seems like only 2 components of the wooting sdk is oficially added?
'wooting-analog-common' and 'wooting-analog-plugin-dev'.
If i wanna use the sdk through crates, is the one Provided by David Wood, good?
crate 'wooting-sdk', looks like it's not been updated in a year.
hybrid lake
It might still work the RGB SDK, but for the analog SDK I think you can use something from the new Analog SDK
@placid ledge knows more about Rust than I do
open minnow
I downloaded it and I've tested rgb so far works, seems good! @normal sapphire dude, this is nice!
normal sapphire
I’ve yet to revisit this and update it to more recent versions of the C SDKs, but I expect they’ll both still work.
Open to PRs if there are improvements to be had.
placid ledge
That reminds me that I hadn't resolved the issue of easy use of the new analog sdk from Rust. The main issue arises from the architecture design of the SDK and the fact that Rust doesn't have a stable ABI, as the design is based on loading the SDK dynamically. So the unstableness of the Rust ABI could result in problems arising if loading the SDK in a rust project using a different Rust version than the SDK is compiled with
For safety, I may just write a Rust wrapper for the C ABI that is already in use. It would have the slight annoyance of having to convert types to C types then back to Rust types, but at least there's extremely low risk for issues compared to a unstable Rust ABI approach
Any feedback would be greatly appreciated
open minnow
Woah
normal sapphire
As far as I'm aware, there isn't a great solution for shipping a compiled Rust SDK and having it be compatible with whatever toolchain the user has. You could expose a C interface from your Rust SDK, and use that from a crate that the user would compile using Cargo alongside the rest of their project dependencies.
placid ledge
Yeah, that's what I was thinking of doing, the C interface is already there, so it's just a matter of expanding the wooting-analog-wrapper to have an idiomatic rust wrapper over the C interface
placid ledge
For you RGB SDK users out there, v1.2.0 of the RGB SDK has been released: https://github.com/WootingKb/wooting-rgb-sdk/releases wrapper libraries will need a slight update, but this should be the final breaking change before RGB SDK v2 (which unfortunately is not high up our priority list currently). If you're using C#, my Wooting.NET wrapper has been updated for v1.2.
quiet root
lame
placid ledge
😢
Is the firmware RGB improvements more exciting? 😛 Pushed to alpha channel today (and hopefully beta soon)
flat wigeon
Did you check if wooting_rgb_direct_set_key() now works with all keys of the Wooting Two?
placid ledge
Yes, in my testing direct set key appears to be working for the entirety of the keys on the Wooting Two
pliant carbon
That's cool and all, but can the wooting run doom?
Damn, you can't - microprocessor memory only has 2kb
When you need at least 2.5mb
So sad
wide nymph
Lekker Edition will be
hearty forge
I am playing around with the C# analog SDK and just noticed what a huge difference Tachyon mode makes
(two keypresses, each pixel is one millisecond)
Currently there is no way in the SDK to request Tachyon mode or at least to detect if it's on, or am I missing something?
hybrid lake
I am playing around with the C# analog SDK and just noticed what a huge difference Tachyon mode makes
@hearty forge Hmm I'm not sure if it's the graph, but what is the average time you measure for regular? If I remember correctly, normal will be about 3-4 ms and tachyon <1 ms
Saying that it looks like the graph has about 3-4 times the samples
flat wigeon
https://github.com/WootingKb/wootility-issues/issues/32 <<--- if you are going to fix this. What about a way to specify a preferred update rate?
hybrid lake
It's not directly related, since this is more about not sending packets if there's no change. I do agree we need to reconsider update rate and tachyon mode. Right now Tachyon mode is less accurate for analog values, because it waits shorter for switching times etc
We could try setting an update rate until you notice a stable signal, but not sure if that's a good power to give users
It might help for experienced users, but can be really confusing for new users
And even then there's other things impacting your rate
flat wigeon
The basic idea was, you don't have to spam 1000 updates per second if the application behind it only needs like 60 updates.
Just like you don't have to spam updates if nothing has changed.
hybrid lake
Oh like that
Yeah that's true, but pretty hard to define
And it's not necessarily a bad or wasted thing, I think in that issue's case there is also a suspicion that spamming xinput reports on windows startup causes some issues
Don't remember exactly
grizzled wolf
!contact
lime glacierBOT
Hey there, as suggested, email social@wooting.io with the following information;
Name:
Date the issue occurred:
Description of the Issue:
Steps taken:
Order details (Order #, Address etc):
Serial number (Back of your Wooting):
If for a general enquiry you do not need to provide the above information. Please give Wooting a few days to respoond.
hearty forge
@hybrid lake I fetch Keys with ReadFullBuffer every 1ms. With Tachyon I see a new value each time, with regular the value changes after either 8-10ms or 15-16ms
For example for one keypress on regular it might update after 9ms, then after 15ms, 10ms, 15ms, 15ms, etc.
Of course for most 60fps games thats plenty, so I see why that's the default
Yeah that's true, but pretty hard to define
I can't hold the key steady at 50%, the value always slightly changes, so I definitely see what you mean. But 99% of the time any key is either at 0 or 1, and at that point "nothing changed" seems straightforward
hybrid lake
Thanks for the update. With "hard to define" I meant it's hard to define what the update rate is an application needs
Do you use RGB effects? @hearty forge
hearty forge
I just tried turning RGB effects off in regular mode. It makes a slight difference in that more updates happen after 10ms instead of after 15ms
But that might just be random variance or different system load
little monolith
different system load can’t really be the cause of 5ms difference
unless you’re running it on an 80s machine
flat wigeon
The Teams API documentation is a pile of garbage
https://discord.com/developers/docs/topics/rpc <<--- with discord I just need to check this page to know, it can do what I want
quiet root
ya u check that page and it still doesnt work cause 99% of the rpc api is locked
gg
the only thing rpc can do atm
is tell u the username and change rich presence
flat wigeon
99% of what is listed here?
Since I found code of a stream deck plugin using the RPC SDK, I expected this to work.
The RPC API itself is questionable. OAuth Credentials over a named pipe?
Documentation of course incomplete, but at least you can see at a glance, what the API offers
quiet root
afaik
the only thing that works is rich presence and name fetching
cant do anything for the user via the api
like subscribing to unread messages
switchign voice channels etc
quiet root
so it seems deafening and muting is part of the available stuff
since it lies inside the rpc scope
not rpc-api
kinda sad all the useful stuff is not available
flat wigeon
It depends on what you want to do. For me that's okay. I just need mute, deaf and for RGB updates the corresponding events and maybe of someone is in my channel and if somebody is talking
Not sure what your usecase is...
quiet root
since rpc.api includes almost all event subs like channel join, new notifications etc
currently none
rich presence is nothing i wanna highly customize
and mute deaf well i can do that with keybinds
strong siren
Aurora has a better discord plug-in to display mute status and some others on the rgb but it's definitely not an ideal solution
strong siren
Yeah
quiet root
whatever discord likes to make out of this state
id really like to do more with integrating discord
but since all the actually useful stuff is locked u need to resort to BD plugins
and other rather janky shit
flat wigeon
Maybe they discontinued it
I'm under the impression that the RPC API was originally meant for game integration.
balmy iron
Wouldn't be surprised, seems games integrating Discord is a thing of the past now
quiet root
general app integration
logitech has access aswell
some other apps do too
but unless ure big company u wont get on the app whitelist
strong siren
Yeah basically this
flat wigeon
If you read the page it looks like they really mean games and other applications just as a sidenote
strong siren
Razer has something like this as well but it's broken afaik
quiet root
obviously the main focus is games
discord is supposed to be a gaming social app
thats why the servers are called guilds etc
but the whole gaming first thing has long since gone
discord is just a general purpose communication app now
flat wigeon
The issue here is... do you really want to let a game meddle with your Discord client?
quiet root
plus theres a seperate game sdk
and yes id like the game to interact with discord
makes partying easy etc
balmy iron
Eh the one time I played a game that did it I had to give permission
quiet root
plus people can see what ure up to thx to rich presence
balmy iron
Unless that's gone now?
quiet root
obviously it requires perms
na u need to let it access
which is a good thing
means u cant have malicous apps
easily
strong siren
Discord making the game do things I can understand. Like create a party when you make an invite in a discord channel. The other way around I can't see why it would be useful.
Besides displaying the rich presence stuff I guess
flat wigeon
I can see why it's useful. You start a game, join a party and bam you are in the same channel with those guys
strong siren
I guess so
quiet root
well anyway due to it theres cool shit in RPC which is locked away tho
which basically includes full api access meaning u could have nice rgb control software displaying various discord stats
seems like the gamesdk is obsolete aswell
now that the whole game store and stuff is gone
hardy trail
visual zenith
Would anyone be willing to spend some time working on an interesting problem that I have? I would like to take the analog input from the W2 and have the open source program FreePiano recognize it. Wooting Piano is awesome; I just want FreePiano to see the analog input that is being seen by Wooting Piano. Any help is absolutely appreciated! 🙂
quiet root
id guess freepiano takes midi signals?
hybrid lake
It works with the Analog SDK, did you install that? @visual zenith
You can find the installer here: https://github.com/WootingKb/wooting-analog-sdk/releases
You'll want the .msi file if you're on windows
visual zenith
Hey Jeroen - yes, I know this. Simon and I have been talking as I have been working on Wooting Piano; however, I would like to have FreePiano receive the analog data so that the notes receive velocity. I do have the source code for FreePiano. With the SDK installed, what would I have to focus on to have FreePiano target the Wooting keyboard?
and Tony - yes, FreePiano takes midi signals, but the velocity is a set number as far as FreePiano is concerned, so I was trying to find out how to change that to whatever the input that is received from the keyboard is translated to the sound of the note played.
hybrid lake
Oh woops, FreePiano is not the same as Wooting Piano, sorry
quiet root
i am almost sure no one here worked with free piano so i guess no one can point you to source code to modify for free piano to receive velocity
plus ud need to calc that anyway
visual zenith
Yeah, I have the source code for it
That would be awesome to have the Wooting keyboard's velocity abilities interpreted by FreePiano. I was trying to somehow merge the Wooting Piano's way of understanding the analog signal to FreePiano.
quiet root
the keyboard doesnt have velocity tho
visual zenith
It does, through analog.
visual zenith
I have been playing it via Wooting Piano
quiet root
over a certain time frame
visual zenith
Yeah
By taking whatever value used, a range, you can get a nice dynamic.
I was trying all sorts of values the other day
Sounds cool when you mess with the timbre of a tine or bell sound as well
the harder you hit, the brighter the sound.
I also set up Wooting Piano for all keys
and mapped it to the way I have FreePiano mapped.. But, FreePiano allows me to groups my keys into each scale, among a number of other cool features that I'd like to still use.
If i can only figure a way to basically send what Wooting Piano is doing over in the FreePiano source code, that would be cool.
quiet root
since i dont wanna be nitpicking rn i wont address the slight concept issues but as mentioned youd need to ask people who work on freepiano
we can help with the wooting analog side of things
just not the freepiano one
visual zenith
I figured as much. I sent the owner an email.
I just figured with the source code and a bunch of brilliant minds over here that maybe something could be done. I have been messing around in the virtual piano space for the past five years. It's neat. The Wooting will make a great midi keyboard for us virtual keyboard players once everything is where it needs to be.
I would even be willing to pay someone to help me.
I am not made of money, but a little something at least.
Simon is also great help
He is looking at it, but he is busy, so I have been futzing around.
opaque fox
I'm fixing my old plugin that has stopped working, but I have run into some trouble. I'm using WootingAnalogSDK.NET and it crashes during the execution of WootingAnalogSDK.Initialize(). [2020-07-04T10:18:54Z WARN wooting_analog_test_plugin] Error : OpenFileMappingA failed with 2 [2020-07-04T10:18:54Z WARN wooting_analog_test_plugin] Attempted to open exist SharedMemFailed... Falling back to creation [2020-07-04T10:18:54Z INFO wooting_analog_test_plugin] Some("C:\\Users\\Garbius\\AppData\\Local\\Temp\\wooting-test-plugin.link") thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', /rustc/5e1a799842ba6ed4a57e91f7ab9435947482f7d8\src\libcore\macros\mod.rs:15:40 stack backtrace: 0: drop_device_info 1: rust_eh_personality 2: drop_device_info 3: drop_device_info 4: drop_device_info 5: drop_device_info 6: drop_device_info 7: rust_eh_personality 8: rust_eh_personality 9: <unknown> 10: <unknown> 11: <unknown> 12: wooting_analog_initialise 13: wooting_analog_initialise 14: <unknown> 15: <unknown> 16: <unknown> 17: <unknown> 18: <unknown> 19: <unknown> 20: <unknown> 21: GetCLRRuntimeHost 22: <unknown> 23: <unknown> 24: coreclr_shutdown_2 25: <unknown> 26: <unknown> 27: <unknown> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. Unhandled exception. System.Runtime.InteropServices.SEHException (0x80004005): External component has thrown an exception. at WootingAnalogSDKNET.WootingAnalogSDK.initialise() at WootingAnalogSDKNET.WootingAnalogSDK.Initialise() at WootingTest.Program.Main(String[] args) Keyboard FW version 1.29.1, Wootility 3.5.8-beta, WootingAnalogSDK.NET 0.4.2 from NuGet. What am I missing?
placid ledge
@opaque fox Could you see if this file mentioned exists and if so delete it? "C:\Users\Garbius\AppData\Local\Temp\wooting-test-plugin.link"
quiet root
the test plugin warning is still a thing?
placid ledge
There are some changes in the pipeline, I can't remember exactly what state I left the test plugin warnings in
placid ledge
Although, the error looks like it could be unrelated to the test plugin, but I think there is still some work to be done on the test plugin as the warnings appear to potentially be a bit misleading/confusing
opaque fox
My keyboard went completely on the fritz today, so I can't test that atm. Not sure if it's related to yesterday's malfunctions. I did run a normal Xinput profile after the error above, but that does not work any more.
placid ledge
@opaque fox What are you experiencing? The Analog SDK erroring shouldn't interfere with the keyboard at all
opaque fox
I had some weird errors where the everything except the basic keyboard function stopped working. I managed to fix that yesterday with the help of Rocky_4. After that, I'm no longer getting the error. I did delete the file you mentioned, so I'm not sure what actually fixed it. Now I'll just have to figure out the mess Keen created in the Space Engineers input code. Thank you for the help and I hope I'll have a working plugin to present again soon.
placid ledge
Ah, glad you got it sorted! I'm not certain that that file was related to the error you were getting, maybe the issue you were having with the keyboard was related. At least it's sorted now. Good luck on your adventures! I'd be glad to hear any feedback you have on the SDK!
opaque fox
It sure has improved a lot since the first version of my plugin, which makes sense because it was still in beta back then. It was all smooth sailing this time around and I can't really think of anything I would want improved. I will be sure to let you know if I find anything.
opaque fox
@placid ledge That SEHException resurfaced again today. I deleted wooting-test-plugin.link, but it did not help and a new file is created every time I run Initialise(). Do you want me to test anything in particular before I try doing the same things I did yesterday?
placid ledge
Hmmmm, that's weird. Don't worry about the wooting-test-plugin.link file, it's expected to be created everytime & I don't think it's related
Everything was working normally in-between? You changed anything software side?
Quite a weird issue
opaque fox
Nothing changed. I did turn the computer off overnight.
placid ledge
Hmmm
Could you give me the full log output when running it aftering defining the RUST_BACKTRACE=full and RUST_LOG=debug environment variables?
placid ledge
Thanks
On the surface from that log it appears to be failing shortly after discovering the keyboard. Does replugging your keyboard change anything?
opaque fox
Nope. Still the same.
placid ledge
Huh, I think I've found a potential lead
What's your current status of your keyboard firmware?
Version? Recent update or reset?
placid ledge
Hmmm
What I noticed was that when it finds your keyboard it cannot find a product_string or serial_number which is very unusual
@hybrid lake
I imagine it's down to that, but I have no idea how that could happen
opaque fox
Cheap Chinese counterfeit, y'know.
Jokes aside
It was likely from an early batch if that makes a difference.
placid ledge
Oh yeah 😄
So everything was working last night and without doing any changes it stopped working today?
opaque fox
As far as I know, yes. This is the second occurrence now...
placid ledge
What was the issue you were experiencing that you mentioned?
I wonder if there's a hardware fault somewhere
opaque fox
It was reduced to a basic keyboard. No analog axes worked in XInput nor DirectInput.
DirectInput was fixed by some registry hack
Xinput was tough to fix. The last thing I did that made it work was to disable and enable Xinput in wootility. I had done that before without success.
If you want the full story, it's over in #archived_helpdesk_for_keyboards
placid ledge
Hmmmm, thanks for all the info. I think I'll have to talk to Jeroen about it to try and figure it out
opaque fox
My pleasure. I'll see if I can fix it and then if I can reproduce it.
normal sapphire
Not sure if this is the right place to ask - I package Wootility for the NixOS linux distribution (https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/misc/wootility/default.nix). On NixOS, you can add hardware.wooting.enable = true; to a declarative system configuration and be off to the races.
I'm attempting to update the package to 3.5.10 - when launching I get the following output:
[17:38:27.705] [info] 3.5.10
Checking for update
[17:38:27.714] [info] undefined
Fontconfig warning: "/etc/fonts/fonts.conf", line 86: unknown element "blank"
[17:38:27.922] [info] Update for version 3.5.10 is not available (latest version: 3.5.10, downgrade is disallowed).
I've checked that there aren't missing shared objects that wootility is trying to link to and the udev rules are in place (e.g. my earlier wootility 3.4.6 package works) - any ideas why this might be failing?
I should have said that I also get a window appearing, but it's just solid white.
placid ledge
Hmmmm
That's weird
I can't think of any dependency changes with this version
What would you say NixOS is most similar to package wise?
normal sapphire
I recall hitting similar issues when I packaged this originally but it eventually just went away and I couldn't work out why. I've tried rebooting after adding this work-in-progress update (https://github.com/davidtwco/nixpkgs/commit/87aa4031baaf83dd4319da41f74e4f4b9e1cb741) to my system just in case, but no luck. Could there be some cached data somewhere? I've tried removing ~/.config/wootility, but not ~/.cache/wootility-updater.
It's not like anything really - every package is stored in /nix/store and there can be different versions of different libraries, traditional file system paths don't have anything in it and software is patched to work.
placid ledge
When did you download the update? We had some issues with pushing the update and for a bit of time the Linux version was a build from Mac which has now been replaced
Do you get the same thing if you redownload the AppImage?
normal sapphire
(that makes using software not written with it in mind difficult, but it infers many advantages)
I downloaded this within the last hour.
Downloading again right now gets the same hash as I got before.
quiet root
idk whats wrong about that output
placid ledge
That log is the normal output, there's a lot of room for improvement for error logging with Wootility.
normal sapphire
I can run the 3.4.6 version of my package directly and it just works - it still has [info] undefined line but then continues working.
normal sapphire
I can tell if you mean wait for a new version or wait because you've thought of something.
quiet root
na was just checking smth
placid ledge
Got anything in ~/.config/wootility/log.log?
normal sapphire
I wiped that directory (since I've been jumping back and forth between 3.4.6 and 3.5.10) and then re-launched - it only has what has been printed in the console. Interestingly, after clearing that directory, I've found that it only prints this and no white window appears:
[2020-07-07 17:59:19.118] [info] 3.5.10
[2020-07-07 17:59:19.128] [info] undefined
[2020-07-07 17:59:19.193] [info] Generated new staging user ID: 83435a63-720d-55c7-b6b3-23dc12b26455
Hmmm
normal sapphire
Nevermind, it just launched the window now - took longer though.
[2020-07-07 17:59:19.118] [info] 3.5.10
[2020-07-07 17:59:19.128] [info] undefined
[2020-07-07 17:59:19.193] [info] Generated new staging user ID: 83435a63-720d-55c7-b6b3-23dc12b26455
[2020-07-07 18:01:05.853] [info] Update for version 3.5.10 is not available (latest version: 3.5.10, downgrade is disallowed).
I think I might whip up a NixOS vm and do some investigation
quiet root
they offer images
normal sapphire
let me know if there's any way I can help
quiet root
welp im out dont wanna open that can of worms. hope simon can help
flat wigeon
Damnit, I just got a reminder, why it's not a good idea to have macros being executed from the device
The panic to cancel the macro if you accidentally changed the active window
opaque fox
@Simon I did not manage to get it working again. I haven't gone through every single step I did before, but I did remove it from Windows, cleaned the registry, and reset the keyboard. Have you made any progress? I'm hoping there will be a permanent fix.
placid ledge
Unfortunately haven't had much time to look into it, been busy with the new stable release yesterday and today.
Is it still the case where the product & serial number are missing when running the analog sdk?
opaque fox
The error looked identical. I can confirm that to make sure.
Funny thing is that wootility seems to detect the serial number.
placid ledge
Huh, weird. Does running it as admin change anything?
If you just give me the output which mentions the keyboard then that's the main bit rn
placid ledge
What is going on, now it gets the serial number but not the product string or manufacturer string
For the time being I can compile a version of the sdk for you which ignores those as they aren't critical to the functionality so you can at least use the SDK
opaque fox
Thanks. That would be awesome! I would appreciate not having to set up rustc again.
It manages to get the serial number some of the times, but never the product or manufacturer strings.
opaque fox
Windows 10 Pro 1903
placid ledge
Give this a try
The changes are only in the plugin.dll, but I included the sdk.dll as well just in case as I'm not on the same rust ver as 0.4.0 was originally compiled with
opaque fox
It's no longer printing the empty strings, but...
placid ledge
Could you set those environment variables again?
RUST_BACKTRACE=full RUST_LOG=debug
placid ledge
Thanks
Looks like something messed up with my windows build environment and it didn't actually build my changes. I'll get ye another one to try one sec
Try this
opaque fox
It initialized!
placid ledge
Awesome! Hopefully it should work for you now
Will try and get to the bottom of the root cause, but I think I'll apply those changes to future versions as helps a bit with error handling, especially given the non-critical nature of that information being retrieved
opaque fox
I'm getting tons of beautiful floats now. Thank you!
Just @ me or send me a DM if I can assist in any way.
opaque fox
Now I'll just have to fix whatever is wrong with my code...
faint vapor
hey there, I tested my package with the newer SDK files on a live debian and when I installed either libusb-dev or libhidapi-dev, the function searching for keyboards gets stuck and only stops when I unplug the keyboard. Uninstalling both makes it work then.
(also I noticed the linux builds have a lot of debugging enabled but I think that's ok for now)
so before I create an issue about that, did anyone experience that before or know a solution?
opaque fox
I figured it out. New release! Get it while it's hot! https://github.com/Garbius/WootingPlugin/releases/tag/v0.2
If you're playing Space Engineers, that is.
faint sonnet
@nimble whale just popped over from the Bards Guild to say brilliant work on Wooting Piano, that was the killer app for me to buy a Wooting Two 👍
flat wigeon
lol, there seems to be a new firmware bug
In RGB mode, if I press Num Lock or Caps Lock, it turns white
But if I press it a second time, it doesn't return to its original color
Firmware 1.29.1
placid ledge
What exactly do you mean by "RGB mode"? Using the RGB SDK?
flat wigeon
Yes
placid ledge
Was able to confirm the issue, do you mind opening an issue on github(https://github.com/WootingKb/wootility-issues) for it? Helps us keep track of the problem
flat wigeon
I don't really need a photo for this, do I? ^^
flat wigeon
placid ledge
Thank you so much!
I don't really need a photo for this, do I? ^^
At least for this where I've replicated it's not needed, but I appreciate it!
Sorry I didn't catch your previous message 😄
opaque fox
@placid ledge I'm sorry to be a pain in your ass, but I wonder if there has been any development regarding the weirdness with the serial, product, and manufacturer strings?
placid ledge
No worries! Have been pretty busy so haven't been able to do much investigation on it yet. The annoying thing is with the lack of being able to replicate it to get to the bottom of it.
Could you post it as an issue on here: https://github.com/WootingKb/wooting-analog-plugin Helps up keep track of the issue & keeps you in the loop with any developments
flat wigeon
Imagine FN + Num 0-9 to manage RDP connections through an RDP connection
opaque fox
I've submitted that issue now https://github.com/WootingKb/wooting-analog-plugin/issues/5. If there's anything else you need, just say the word.
chilly oar
@flat wigeon Bind F13+ keys to them and use AutoHotKey to do whatever you need.
flat wigeon
Doesn't work that way though
chilly oar
What exactly do you want to simulate?
AHK can do scripts, so it should be able to do everything.
flat wigeon
I need to know the state of these connections trough the initial RDP connection
chilly oar
So you would need some plugins (programs) which can check the state.
flat wigeon
quiet root
ahk can use windows apis
on the other hand you can also just use global hooks in lets say c# or the likes and hook to f13 etc
flat wigeon
I'm not sure, what using AHK would help me here
flat wigeon
Currently A3 is my RDP connection to my work computer. The key has different colors depending on if the connection is established/visible/in foreground.
If I press A3 then:
- connection not establed -> run mstsc
- visible/hidden -> show and set as foreground window
- in foreground -> hide window
My idea was basically to do exactly that with FN + <numkey> through the initial RDP connection
acoustic drift
I am sorry, I have no idea what RDP connection even is
flat wigeon
Remotedesktop
acoustic drift
Oh
quiet root
@flat wigeon ahk makes it easy to do stuff like this
you could use any language but global hotkeys arent easy in many languages and have some caviats sometimes
flat wigeon
Global hotkeys are generally painful, because you have to find a combination which is definitely not in use by any other application.
I don't like to use the F-keys either, because it's limited
placid ledge
(F13-F24 is never really going to be used by any application)
flat wigeon
But I only have 12 of those 😄
placid ledge
You can rebind A3 -> F13 using Wootility remapping
which I think is what they were on about before
flat wigeon
And since I can read the keys analog values anyway I don't get much from rebinding it
placid ledge
Fair
If you're already using Analog SDK it's not going to make much of a difference
However, you could put F13 on the function layer for A3 and use that as a seperate hook for doing the functionality through e.g. AHK
flat wigeon
Does the analog SDK handle the Fn-bindings?
quiet root
it gets read as the bound key
and from what i can tell ure only interested in rgb
for making them light up depending on connection
flat wigeon
I'm interested in both ways. Fn + Num1 to show/hide the RDP connection to VM1 as well as updating the indicator LED accordingly.
quiet root
you could rebind a3 to another unused key aswell to get rid of analog sdk
@flat wigeon so bind f13 to function layer num1
and read the key
do stuff
flat wigeon
There is no reason to get rid of the analog SDK
quiet root
it sounded like it was the only thing
flat wigeon
Currently I have 3 active features mute/deaf in Teamspeak 3 with indicators, manage my RDP connection to my work computer (with indicator) and volume control (on a db scale instead of linear)
quiet root
anyway ud just hook other hotkeys to manage the rdp then
i mean u already read the keys so idk where the real problem lies
windows exposes enough apis to do this
flat wigeon
There is no problem, I already linked, what I need
quiet root
so not really woot dev related?
flat wigeon
My comment wasn't meant as a question, more as an idea what you can do with the num block and the fn key
quiet root
not really sure if this channel is a "throw in ideas" channel
usually people ask how to do smth which is why people told you how to do it in several ways
ideas are usually shared as PoC github repos and such
flat wigeon
Yeah, probably I should do that...
flat wigeon
Then I should start with a PoC for analog volume control with different approaches ^^
rich wren
who do i talk to if i have a question on my order on the wooting wrist rest?
fathom garnet
#archived_questions_answers or just send them an email
rich wren
cool thanks
placid ledge
Analog SDK v0.5.0 is out btw! https://github.com/WootingKb/wooting-analog-sdk/releases/tag/v0.5.0
grizzled wolf
Hi, just bought my Wooting Two last tuesday and am experimenting with the sdks. Now I was wondering about best practices with the analog SDK. Since it, as I understand it, returns all values since last call to wooting_analog_read_full_buffer_device. If I have multiple application or processes polling these values, I might miss key presses. I there a way around this?
balmy iron
It does handle multiple apps using the SDK at the same time fine in my experience, unless I'm not understanding what you mean
grizzled wolf
I mean that if I read the buffer, an other app will not get that value, since it's not in the buffer anymore. I tested this by running 2 instances of the example project from the c# wrapper. Then when I press a key, I don't receive the same values in both instances.
balmy iron
Hmm, weird, I just opened 3 instances of my little thing and they are all reading the same values..
grizzled wolf
Key 83 is registered in one instance, but not the other
balmy iron
How often are you polling? Since it seems like it does get the same keys but not necessarily the same analog values
grizzled wolf
I'm just using the default example. So that's every 100 miliseconds. But I think this behaviour is to be expected given the setup of the wrapper. It does not have a per-app buffer.
balmy iron
Yeah try setting it to 10ms instead, it's what I use
grizzled wolf
thanks for your help
grizzled wolf
Sorry, I have 2 more questions. I hope this is the right place for that.
- The analog sdk, when in the Function layer, when I press a key that has been mapped to something (no matter what), I notice that it returns the value from the Main layer and if nothing has been mapped to that key in the Function layer, it doesn't register at all. Should I report this as a bug, or is this intended behaviour?
Edit: My mistake, it does always register the input. Does not register however that the Function layer is active.
- If a key has been remapped, no matter what KeycodeType I use, I get the remapped value of the key. Is there a way to get the actual position of the key that has been pressed? I need this, because I want to change the color of the pressed key, but now if the key has been moved, the led on the original location changes color instead.
quiet root
well i thought that the keyboard would always send the "keyposition" basically
cause the analog sdk should not rely on what the os gets
but read out the analog switch values
altho then again if u remap the kbd for easier gameplay or smth a game using the analog sdk wouldnt use the keymapping
grizzled wolf
that's not what I'm seeing. I wrote a very simple piece of code to test this. It prints the output to console
WootingAnalogSDK.Initialise();
WootingAnalogSDK.SetKeycodeMode(KeycodeType.ScanCode1);
ConsoleKeyInfo key;
do
{
var length = 0;
dynamic a = 0;
while(length == 0)
{
Thread.Sleep(50);
var (input, status) = WootingAnalogSDK.ReadFullBuffer(20);
length = input.Count;
if (length > 0)
{
// Console.WriteLine($"Wooting: {(ConsoleKey)input.First().Item1}");
Console.WriteLine($"Wooting: {input.First().Item1}");
}
}
key = Console.ReadKey(true);
Console.WriteLine($"System: {key.Key}");
WootingAnalogSDK.ReadFullBuffer();
}
while (key.Key != ConsoleKey.Enter);
Then when I remap both system and analog values change, no matter what KeycodeType I use
And that makes sense. But I can't figure out how to get the actual key. I think this must be possible, since also Wootility does this
flat wigeon
well i thought that the keyboard would always send the "keyposition" basically
@quiet root That was at least true for the old analog SDK (which used UsagePage 0x1338).
From what I read there... you could directly interface with the keyboard (UsagePage 0x1337)
https://github.com/WootingKb/wooting-analog-sdk-old <<--- section keyboard matrix. The first figure shows col- and row numbers used by the RGB SDK. The second figure shows the actual scan codes used in the input/feature reports.
But keep in mind to not start Wootility while your application queries the analog states. Otherwise Wootility will trash your keyboard configuration.
If you want it quick and dirty, then you can modify the RGB SDK, which already has a handle to the correct interface of the device.
Every time you send a feature report (0x00 0xd0 0xda 0x14 0x00 0x00 0x00 0x00) the device responds with an input report
The input report contains all analog values (starting with offset 5)
grizzled wolf
that's helpful, thanks!
placid ledge
@grizzled wolf Hi! We noticed you posted on the Trello with some issues with the Analog SDK (which I'm assuming the conversation here is a follow on from that). For bug related things in future you can post them here: https://github.com/WootingKb/wooting-analog-sdk/issues
In regards to 'knowing the position of the pressed key', that one is kind of annoying. Before remapping, the Analog SDK would pretty much have that behaviour as the raw 'HID Code' would effectively encode the position of the key as it could only ever be in one place. This gets a bit broken with the fact that Remapping can change where that key is positioned so you can no longer be certain of the physical position of that key. This is behaviour that I'm not a massive fan of, as that is something I want to be easily achievable with the Analog SDK.
I've still got to look into it a bit more to see how it'd actually look/behave. However, in my brief discussion with Jeroen on the topic we were thinking about potentially including the row/col or the scan index from the old keyboard matrix (https://github.com/WootingKb/wooting-analog-sdk-old#keyboard-matrix), alongside the Keycode in the result so that you have both the bound key and the position information available.
EDIT: I've opened an issue on the Analog SDK repo to keep track of the 'knowing position of the pressed key' https://github.com/WootingKb/wooting-analog-sdk/issues/12
balmy iron
Is it intentional that doing something like c wooting_analog_initialise(); wooting_analog_uninitialise(); wooting_analog_initialise();
causes thread '<unnamed>' panicked at 'env_logger::init should not be called after logger initialized: SetLoggerError(())', /home/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/env_logger-0.7.1/src/lib.rs:1042:16 ? Does not quite match what the comment says 🤔
placid ledge
That is not intentional
Could you open an issue for it on the github? https://github.com/WootingKb/wooting-analog-sdk/issues
balmy iron
Nah, too lazy
placid ledge
Will try get it resolved for next release
Ahaha welp, it is pretty small so I can try a quick fix here
placid ledge
@balmy iron I've fixed it in dev, how much do you need this working?
As in, do you want a dev build that you can work with until the next release where it'll be included, or you just wanna wait?
balmy iron
I'm fine with waiting since it's a very very minor thing
placid ledge
Cool
grizzled wolf
@placid ledge thanks for your response. Will post on github next time and will add a bug about analog sdk not returning HID for Functional layer. Regarding the initialise/uninitialise, while you're at it you might also want to take a look at wooting_analog_is_initialised, because it always returns TRUE.
placid ledge
Hmmm, that's weird that it always returns true. It's something that came up before and I specifically added test cases for it. You're using the WootingAnalogSDK.NET wrapper? And you've got Analog SDK v0.5.0(The version should be shown in your installed app list in Windows Settings assuming that's your platform)?
grizzled wolf
Yes, using the wrapper and sdk 0.5.0 that was installed with Wootility
placid ledge
Strange, and you're getting it returning true when checking it before initialisation?
grizzled wolf
Yes, I am. I first saw this in my own project where I use the wrapper directly. Then retested it with the analog-test project from the .net wrapper (https://github.com/WootingKb/wooting-analog-wrappers/tree/master/examples/analog-test). Both had the same result.
grizzled wolf
Have a question about the RGB sdk. I want create some different RGB effects, all updating part of the keyboard. I can't read the current colors, so I thought I'd set a couple of keys then do an update.
Like this:
RGBDeviceInfo device = RGBControl.GetDeviceInfo();
RGBControl.SetKey(WootingKey.Keys.Enter, 255, 0, 0); // wooting_rgb_array_set_single
RGBControl.UpdateKeyboard(); // wooting_rgb_array_update_keyboard
But when I do the update, a whole section of the keyboard goes dark.
Tried it with my own project, directly calling the sdk, then with the .NET wrapper. Build sdk both as x84 and x64. All have the same result.
Am I doing something wrong, is this a bug or is it not supposed to be used like this?
strong siren
i think you have to explicitly set the colors on the other keys. not 100% sure
flat wigeon
As far as I know, you can't read the colors from the keyboard with the RGB SDK. If you want to change the color of a single key, you must either update the entire block or use wooting_rgb_direct_set_key().
grizzled wolf
Thanks. Read source code for the rgb sdk. See that it uses 5 rgb buffers and then updates each buffer that has a change. Not what I expected after reading the documentation, but it makes sense.
proud oasis
As far as I know, you can't read the colors from the keyboard with the RGB SDK. If you want to change the color of a single key, you must either update the entire block or use wooting_rgb_direct_set_key().
@flat wigeon ye. technically it would be possible but it would be a total hack. (reading the currently active profile + rgb values and buffering any changes done through the rgb sdk = table of truth. from my experiments i can say this would mess with wootility so.. i'd not do that unless wootility is closed 😇)
proud oasis
well ye somewhat.
quiet root
i dont see why youd not do a hack for a hack
proud oasis
well.. it doesn't contain any of the profile stuff that wootility does
(it could be added tho and it works)
hm.. for some reason i wanna play with the sdk again.. maybe i'll dig into this then. issue already exists too. https://github.com/WootingKb/wooting-rgb-sdk/issues/25
the problem is just that you have to transfer the key colors in chunks. (if i'm not mistaken 5 for the twooting and 4 for the wooting 1)
it looks funny if you don't reset the colors first. you literally see the assigned rgb controller areas / chunks 😄
proud oasis
ye.. got the sdk running on linux now. will work on it.
grizzled wolf
That's awesome 😄
proud oasis
o and as a sideeffect I'll implement a fancy sdk usage example
proud oasis
hmm..
proud oasis
ah nvm.. i found the coordinates n stuff
proud oasis
hmm.. now where do i get the remaining keys.. strange..
proud oasis
ok that's strange.. the return key, f11 and left shift are missing
@grizzled wolf such progress so wow. i can read each profile now.
grizzled wolf
Nice. Put it in the sdk, so we can use it 🙂
Do you also know why, when rgb sdk is connected, the color changes for caps/num/scroll lock don't work?
proud oasis
ye that's intentional. when using aurora etc. you can just customize numlock, capslock and scrolllock yourself.
i enlighten left shift, right shift and capslock when i press caps
o and i just finished this
the get_safe_led_idex is just not ISO layout compliant. i gatta need to work on that too :/
grizzled wolf
not entirely sure what I'm looking at. Looks like fancy colors...
proud oasis
i just added per key rgb color retrival into the sdk. thats what you are looking at.
meaning, it can read the profile colors now
grizzled wolf
Ok. Then you're also able to init the color array with the current colors and then use the wooting_rgb_array_set_key to update just a couple of them
that's exactly what I was hoping for
yesterday I tried doing the whole board key by key with direct set. I could see the delay between first and last key to change color. This will be much nicer
i'm trying to create some bubble effects as overlay over the current profile. Can't wait to try out what you've come up with
proud oasis
well i'll head to bed now. i should probably start doing commits now after a bit of cleanup
proud oasis
also in addition to that, the original profile can be animated with a proper ripple effect now
proud oasis
such progress so wow
flat wigeon
It would be useful if you could change profile on the fly without saving it to the keyboard first.
Is there any information how many write cycles the memory supports?
placid ledge
100k iirc
iirc same for both the EEPROM which is used on the current keyboards for memory, and the flash chip we'll be using on Lekker/HE
indigo hound
Yea, EEPROM has limited erase count. This is mostly mitigated with onlt updating the changed values and some kind of rolling buffer to spread the wear over all the adresses. Reading from EEPROM should not be an issue. FLash memory has better erase/write rates but you have to deal with the comprimises of flash memory. Mainly that flash memory can read on a byte level, when resetting it back the entire block gets reset back to '!' logic high, writing a '0' can be done on a byte level (with bitwise also on the bitlevel). For that inconviniance you get a much faster resetable non-volitile memory that is relatively highly dense for data.
EEPROM instead sets and resets on a byte level and leaves the rest alone unless told to. On low level chips this EEPROM is adressed with 8 bits adrressing, but 32 bit eeproms are becomming a thing
Also wear leveling is a great feature to enable/inplement or purchice for. It can be tricky to make your own EEPROM controller to handle 32 bit integers in 8 bit regusters and afterwards correctly recreate it.
flat wigeon
I don't think that implementing wear leveling is very useful here
The write cycles are mainly relevant for automatic profile switching because it may happen much more frequently then manual profile switching
But if the Wooting is going to support loading profiles to RAM, that is entirely not an issue
fallen surge
Hey guys I've installed the Wooting Plugin for Unreal Engine 4.
Initially I had some issues at first then with the help of two nice ppl in this community I managed to rebuild and compile the code (if that makes any sense to you programmers). I'll tell you how I did it, but upon running Unreal Engine 4 in Blueprints the mouse cursor is offset; so when I thought that my cursor is on an icon in actuallity the invisible cursor is elsewhere.
Prior to running UE4 upon installation I had some issues regarding code.
This is how I fixed it:
I changed lines 12 & 36 that had 1s to 0s inside the WootingAnalogInputFunctionLibrary.h
also changed any coding files the includes Module.Manager.h and DelegateCombinations.h to Modules/ModuleManager.h and Delegates.DelegatgeCombinations.h
So that's how I resolve the code but upon running UE4 in Blueprints interface I've encountered the mouse cursor offset issue.
balmy iron
I still don't do anything with UE so I have no effing clue why visuals would be buggered like that, is it broken like that without the plugin?
fallen surge
no
w/o the plug-in it works just fine
anyways there is an alternative in making use of analog
w/o the wooting plugin that is
indigo hound
Dont know if applicable there however for me, running programs windowed sometimes resolved these artifacts. Where the visual display does not match the UI(eg. buttons) and would be offset. Thus running it windowed and letting the window manager make it fullscreen fixes these 'features'.
placid ledge
@fallen surge The UI offset issue you mentioned is very strange, as you can prob tell, the plugin doesn't do anything crazy and integrates with Unreal's plugin system, so an issue like that doesn't sound like something wrong with the plugin, as the plugin does nothing related to that. Also, the changes you made to the enum in WootingAnalogInputFunctionLibrary.h are quite invalid, those values need to match the ones that the Analog SDK itself uses so changing those numbers will produce unexpected behaviour. What issue were you experiencing that led you to do that? Also, which version of Unreal are you using?
fallen surge
@placid ledge upon following the instructions on https://github.com/WootingKb/wooting-analog-unreal-plugin I was attempting to generate the project file as mentioned in Step 4; however, it says it couldn't and I have to manually rebuild in code. So I opened Visual Studios and rebuild, but then it gave a lot of compiling errors. So following some advice that led me to change the values.
fallen surge
So I didn't rebuild the code successfully I wasn't able to enter UE4
balmy iron
Yeah I suggested that awful hack to the enums, would have probably been a better idea to just add the zeroth value and name it invalid or something...
placid ledge
Hmmm, interesting. What Unreal version are you using? Might require some tweaks to be fully compatible with a newer version @fallen surge
fallen surge
@placid ledge the version for UE4 is 4.25.3
placid ledge
Alright, thank you, I'll get it installed and make sure everything is as it should be
fallen surge
aight
placid ledge
Looks to have been some plugin API breaking changes introduced in 4.25. I can't run unreal in my VM, so think I'll have to push fixing this til tomorrow so I can get a bare metal windows machine setup
fallen surge
no rush @placid ledge
placid ledge
@fallen surge Was just able to take a look at it. Latest commit has the tweaks with the Enums required to work with Unreal v4.25. I didn't experience the mouse offset issue you mentioned, still confused by that as the plugin doesn't do anything related to UI, it just describes objects in the way Unreal requires to generate UI elements for them
fallen surge
@placid ledge maybe it has something to due with the graphics card?
like is the graphics card you are using AMD? or Nvidia?
placid ledge
I doubt that'd make a difference, but I've got AMD (laptop)
fallen surge
prior to installing the Wooting One plug-in, v4.25 has issues with Nvidia or at least from my experience
like it would crash and shutdown the program whenever I open blueprints
placid ledge
big oof
fallen surge
I reported this w/ the bug report to the UE4 team and they are waiting for an update from Nvida.
so I have to resort to saving my work more frequently.
placid ledge
sounds pretty rough
Has the wooting unreal plugin been working well enough for you?
fallen surge
not really
I've tried restarting the pc but doesn't really resolve so I had to use my prev UE4 project w/o the Wooting Plug-in
placid ledge
is it still that UI offset issue you mentioned before?
fallen surge
yes
placid ledge
Hmmmm, I don't know what I can do to help with that, have you mentioned it to the UE4 team?
balmy iron
Got any kind of HiDPI scaling going on?
placid ledge
@fallen surge I have found one thing, which is the only thing I can think of that could possibly mess the mouse up is the method that's used for passing through regular inputs when no analog keyboard is found. Could you try commenting out this line: https://github.com/WootingKb/wooting-analog-unreal-plugin/blob/master/WootingAnalogInput/Source/WootingAnalogInputDevice/Private/WootingAnalogInputDevice.cpp#L36 and see if it changes anything?
fallen surge
k
so basically I'
I've commented out the line you've suggested.
also I've changed the 0s back to 1s in WootingAnalogInputFunctionLibrary.h
rebuild, save then tried to exit Visual Studios
and I got this progress bar
k I tried Opening the UE4 file but I'm getting this error
should I change the 1s back into 0s in WootingAnallogInputFunctionLibrary.h?
So I've reopend VS again I did a build this time instead of rebuild and I got thsee error messages.
placid ledge
You should download the latest from the repo as I have the stuff with the enums fixed on there
Those error messages at the end are not helpful at all, I had to look at the compiler output to get the actual error
I got exactly those before from the error messages and they are not helpful in the slightest
fallen surge
so I've download the latest plug-in recompiled ran UE4 still get the mouse cursor offset.
placid ledge
Try commenting out what I mentioned on that. I was pointing you to update not because I'd expect it to resolve the mouse issue itself, but it means you don't need to worry about correcting the enum and such as that is already resolved
You should be able to just comment that line and see if it makes any difference after a recompile
If that doesn't change anything then I'm pretty certain it's an issue with UE4 that I can't do anything about
fallen surge
k will do that after lunch
fallen surge
so far so good; no offset.
placid ledge
Hmmm, interesting, thanks. I'll do some investigation to try find out why, maybe the interface it's overriding has changed slightly
With that commented everything should work as normal except that you won't get regular key presses coming through the Analog key inputs if there's no analog coming through. Which is there to provide compatibility if you don't have an analog keyboard, but should be fine for you for now
heavy moth
Not sure if this is the right place to write suggestions but It would be really appreciated if left/right mouse clicks would be added to the remap options in wootlity
indigo hound
Theoretical possible.. but would be a odd features to need/want. Most games allow keyboard input and mouse input in the ingamd remapping. Probably causing a lot more bugreports. But is for some a great idea while for me and my workflow it would be a bad idea with conflicts with my lowlever keybinder.
placid ledge
@fallen surge Yo, I was able to take another look at the Unreal Engine plugin and found some overrides missing from the KeyInterceptHandler which is what you commented out. I guess they must've been added recently with a couple related to DPI/Mouse position so could be the culprit. I've committed the addition of those so if you've got some time could you download the latest from GitHub and try it out to see if the issue is fully resolved now? Thanks
fallen surge
okay will do that after my job interview
placid ledge
Awesome! Thank you
heavy moth
Theoretical possible.. but would be a odd features to need/want. Most games allow keyboard input and mouse input in the ingamd remapping. Probably causing a lot more bugreports. But is for some a great idea while for me and my workflow it would be a bad idea with conflicts with my lowlever keybinder.
@indigo hound Id like that feature for some editing softwares I use it could dramatically Increase the workflow with the pressure sensitivity which is the main reason I got the keyboard, not for gaming. Hopefully it'll be added in the future
grizzled wolf
As i'll now be moving to linux (after windows decided to delete a bunch of files), i guess it's a good time to suggest yet again to add an impulse option when handling analog input, as the solution i worked on requires AHK (which i won't have access to).
Essentially it works by tapping the relevant keys quickly to simulate analog input.
In some cases it doesn't work very well (eg: hades will derp out due to very quick animations) and with others it works better than a controller (eg: gta5 driving).
This is the ahk script i made a while back, which is what seems to work best.
It's slightly derpy at times due to AHK not being very precise, but it works very well overall.
And this is how it looks like ingame.
With a few bonus, now old gifs:
https://cdn.discordapp.com/attachments/453072453435129856/703355208855453726/gtaexample3.gif
flat wigeon
"after windows decided to delete a bunch of files" <<--- LOL. That certainly needs explanation and why that wouldn't happen with Linux based systems.
grizzled wolf
I updated, files gone
grizzled wolf
minor update that happened in the background.
at first i could not connect to my network anymore, so i rebooted.
when i came back i lost a whole bunch of settings and files (which browser is my default, saved passwords, programs settings like steam and lghub, plus a bunch of files. steam started downloading about 12 gigs of stuff)
and besides, it's a nice feature to add, i just went ahead and re-suggested it as the solution i worked on will not work for me anymore, sad times.
flat wigeon
Lost settings makes sense, since they just apply snapshots on parts of the registry, but lost files is new to me
grizzled wolf
windows settings, sure
program settings, that aint good
logitech ghub was reset to default essentially for example
meaning the config file was deleted
plus the 12+ gigs of stuff that was re-downloaded afterwards, i still don't know how much i lost
it affected multiple drives, hence steam re-downloading things (i have my steam library in a different drive)
flat wigeon
Newer heard of that
grizzled wolf
same tbh, and i'm surprised it didn't blow up recently
guess i was an unlucky victim
flat wigeon
Except for OS related registry settings everything should be safe
flat wigeon
I remember steam having similar symptoms after system crashes...
grizzled wolf
downloading 10+ gigs of actually missing files?
flat wigeon
Depends on the size of the game ^^
flat wigeon
Steam settings gone, need to reenter my password, does redownload games after that
grizzled wolf
in this case the files were actually missing
flat wigeon
hmm...
grizzled wolf
reminds me of that one update that deleted stuff in the document folder x)
grizzled wolf
Anyway since i'm already here, i'd like to point out that the script works a bit differently compared to the usual approach for this type of effect.
Usually programs that convert analog input to digital would tap the key for an extremely small duration, changing the frequency at it was pressed more or less.
so for example at 50% it may press a key every 8ms, while at 75% it'll press it every 4ms.
Instead i went for a fixed cycle time, by default 20ms, then holding down the key for a percentage of time each cycle according to how far it's being pressed, with a few cases were the next cycle starts early to improve responsiveness. (if we're past the portion of the cycle during which the key is pressed, but the key is currently being pressed enough to exceed the current time in the cycle, then it'll reset. So for example if i press a key 20% of the way and the cycle lasts 20ms, 1-4 will be pressed down, 5-20 won't. If right now i'm at the 12th ms i press the key more than 60% of the way, the cycle resets)
As it turns out this approach works much better as games may derp out when keys are being pressed too quickly. :)
fallen surge
@placid ledge this is an update on your script; whenever I resize the window for the blueprint the offset begins to happen.
grizzled wolf
Thanks to a tester i can confirm that my script works in horizon zero down, while controller+keyboard does not. ;)
placid ledge
@fallen surge Hmmm, I take it it's not fully fixed then? Will have to take another look at it, at least now I may be able to replicate it for myself
fallen surge
out of curiousity @placid ledge have you make any control mechanics that involves dodging?
I'm of course referring to blueprints
placid ledge
Unfortunately I have not, I haven't done a massive amount of playing around with Unreal Engine outside of creating the Analog plugin & making sure it's working
glacial horizon
Anyone here familiar with node-gyp and its errors
Trying to install a package but it keeps erroring out, i do have visual studio with its C++ extensions installed. Also have windows build tools installed. Package i'm trying to install is screen-avg-color: https://www.npmjs.com/package/screen-avg-color.
Any help is appreciated
indigo hound
https://www.npmjs.com/package/node-gyp
node-gyp requires that you have installed a compatible version of Python, one of: v2.7, v3.5, v3.6, v3.7, or v3.8.
quiet root
@glacial horizon id also suggest trying an older node version
from around 2 years ago
glacial horizon
https://www.npmjs.com/package/node-gyp
node-gyp requires that you have installed a compatible version of Python, one of: v2.7, v3.5, v3.6, v3.7, or v3.8.
@indigo hound windows-build-tools installs 2.7 😉
@glacial horizon id also suggest trying an older node version
@quiet root Ill give this a shot, thanks
Yeah that fixed it, thanks!
willow jungle
Question; would it be possible to export via some API when a key is pressed?
I would like to build a solenoid to have a physical feedback but then i need to be able to get information about the keys 😮
wide nymph
@willow jungle Basically the Analog SDK tell you exactly when, which and how far a key is pressed
That's what we made it for 😄
willow jungle
Sweet! Then i just need to figure out the rest 😄
wide nymph
Not sure if we can have some type of boilerplate thing that could make it faster to setup without needing to confirm to some frameworks or whatever.
Would need to have feedback on what step makes it more complicated to get started and then see if we can simplify it, so it's more accessible.
willow jungle
Yeah, i am no developer but i am willing to try to have two softwares talk to eachother or such 😛
Surely it would be heaps easier to just have it implemented in the wotility but i guess not so many users would use this feature 😛
willow jungle
Oh, and also. Is there any statistics available in wotillity? Would be nice to see what keys i type the most and stuff like that? 😄
placid ledge
https://github.com/WootingKb/wooting-rgb-sdk/releases/tag/v1.3.0 Hello devs! Got a minor update for the RGB SDK for you all, if you're using functions like wooting_rgb_array_set_full or wooting_rgb_array_set_single you'll see much better colour responses using this update!
quiet root
so no more manual gamma adjust?
placid ledge
You could still do it manually, I hadn't considered the possibility of wanting to do your own gamma mapping, I can add an opt out for the default gamma adjustment. Adding it to those functions was done to make the behaviour consistent, as the direct set functions & colours set with Wootility use that gammaFilter, so you would get different resulting colours which isn't exactly great default behaviour.
cyan saddle
Alright, I am having some weird issues.
wooting_analog_get_connected_devices_info is returning 1 and the stuff pointer I pass to it doesn't seem to be valid as a struct array or as a struct pointer array?
Now it's working.
Guess I just messed something up.
[15:51:12] [main/INFO] (wooting_analog) Found 1 keyboard
[15:51:12] [main/INFO] (wooting_analog) Keyboard 0:
[15:51:12] [main/INFO] (wooting_analog) vid: 1003
[15:51:12] [main/INFO] (wooting_analog) pid: -254
[15:51:12] [main/INFO] (wooting_analog) mfgr: Wooting
[15:51:12] [main/INFO] (wooting_analog) name: WootingTwo
[15:51:12] [main/INFO] (wooting_analog) did: --snip--
[15:51:12] [main/INFO] (wooting_analog) type: 1
:-)
placid ledge
@cyan saddle Glad it started working. If you run into any further issues feel free to message me
cyan saddle
Most of my problems tend to be me being stupid.
Is there a way to get the keyboard layout with this?
placid ledge
Do you mean the remapping layout?
cyan saddle
Yes and the different physical layouts.
I'd like to be able to create a GUI that has all of the keys in the correct locations.
I can hard code the stuff if I need to.
placid ledge
Not currently, but it is something I plan to add. At least the remapping layout or position indentifiers so you know where in the keyboard the key was pressed rather than just the key that's bound to it
cyan saddle
Figures.
placid ledge
Currently we're pretty occupied by Lekker development, lots of changes have been made to the firmware so it's tricky for me to implement anything like that right now unfortunately 😩
cyan saddle
It's okay, don't worry.
I'll be getting one of those ones soon.
I plan on seeing what a magnet does.
cyan saddle
The Corsair stuff has something like this for LED positions in its SDK:
typedef struct{
double x;
double y;
double width;
doible height;
} LedPosition;
typedef struct{
int count;
LedPosition* leds;
}
Maybe using something similar would work, could add in a scancode and label field.
placid ledge
Yeah, I was planning on using the keyboard matrix row/column positioning that is currently used in the RGB SDK and is now how most things work in the firmware as well. With some SDK improvements I plan to do with Lekker you should be able to determine the row/col of the analog key and also retrieve the remapping layout that's currently configured
cyan saddle
Cool, haven't used the RGB stuff since a bit after the Two Kickstarter.
Doing some game mods. :-)
grizzled wolf
Gentlemen..... i just tried the analog read c# example SDK in VS19. The nuget package is installed as well as the latest wootillity...
However i get Analog SDK Successfully initiated with 0 devices, and Read failed with NoDevices...... what may i have done wrong?
grizzled wolf
Ahhh... i got it: the wrapper was not in the root of the project 🙄 for some reason
grizzled wolf
Neato, submitted my impulse analog input feature request as an issue on github: https://github.com/WootingKb/wootility-issues/issues/71 
cyan saddle
Anyone happen to have a mapping for GLFW <-> USB HID?
cyan saddle
:-)
cyan saddle
I mean, right now I am doing it the worst way possible:
for(AnalogKeyboardKey key : (Set<AnalogKeyboardKey>)(Object)KEYS){
int usbCode = GLFW_HID.getOrDefault(key.getCode(), -1);
if(usbCode != -1){
key.setValue(WootingAnalog.wooting_analog_read_analog((short)usbCode));
}
}
(Don't mind the stupid casting, API related stuff)
cyan saddle
Hmm, using wooting_analog_read_full_buffer with params of a direct ShortBuffer's address, a direct FloatBuffer's address and 103 returns 0.
Wonder why.
cyan saddle
boolean override = InputRegistry.getInstance().isDeviceBeingConfigured(this);
for(AnalogKeyboardKey key : (Set<AnalogKeyboardKey>)(Object)KEYS){
if(override || key.isBound()){
int usbCode = GLFW_HID.getOrDefault(key.getCode(), -1);
if(usbCode != -1){
key.setValue(WootingAnalog.wooting_analog_read_analog((short)usbCode));
}
}
}
This is a bit better, now I only grab bound keys unless the GUI is being shown. :-)
Next is per-key actuiation points for the boolean state stuff.
flat wigeon
Is it just me or does the keyboard take quite a while to fully update the color on all keys?
strong siren
depends on what you consider "quite a while"
i've noticed different update times anywhere from 30-50ms on different usb ports. not sure why
flat wigeon
I mean clearly visible
Full keyboard color changes look somewhat like a wave animation, even though it's supposed to change all at once.
My first ideas were maybe increase the buffer size, so everything can be sent at once. Or alternatively add an extra commit command, so you can first update the colors and commit the changes afterwards. Just like the RGB SDK does internally.
I guess I'll look if there is an issue for that
placid ledge
That's strange, it shouldn't be taking so long to update that you can watch each part of the RGB update. Each time the keyboard scans for key analog data it'll update one part of the RGB that's been updated. On Wooting One/Two that's in 3 parts. When it takes a long time to update where you can watch it update in parts, do you notice slow input speed? If input is slow then it indicates a potential issue firmware side, whereas if not then it could be something wrong on the software side causing the USB packets to be received quite slowly
placid ledge
What does your setup with the RGB sdk look like?
flat wigeon
Firmware Version 3.5.12
My program is linked against the dll. It prepares the entire buffer with wooting_rgb_array_set_single() and calls wooting_rgb_array_update_keyboard() when it's finished. Auto update is disabled of course.
The keyboard is plugged into the rear USB port on the mainboard. According to Wireshark it takes up to 3,55 ms between sending the first and the last part.
placid ledge
That version you mentioned is your Wootility version, your firmware version should be more like v1.29.x
Hmmm, that 3.55ms between seems quite long
Also, the framerate in the clip you sent is fairly low, would you say that is a good representation of how it looks IRL?
flat wigeon
Oh sry I mixed the versions, 1.29.3
Yes, I think this is a good representation. Maybe a bit faster actually.
flat wigeon
In the original Video it takes 4 frames @29,731Hz until it was fully lit. So I would estimate ~100ms.
merry steppe
Is possuable to add sleep mode for backlight? Like if i dont press any key for 10 mins backlight turns off to save LED lifespan
placid ledge
In the original Video it takes 4 frames @29,731Hz until it was fully lit. So I w...
Hmmm, that's quite weird, it shouldn't really take that long. The only times I've experienced it updating slowly like that (which infact was even slower) was when devving Chroma Connect for Wootility in a pretty slow Windows VM. Could you potentially send me a copy of your software you're using for this? Have you tested on different machines & usb ports to see if that makes any difference?
placid ledge
Is possuable to add sleep mode for backlight? Like if i dont press any key for 1...
I like that idea, it's potentially something we could implement on the firmware side. Do you want to open an issue here (https://github.com/WootingKb/wootility-issues/issues) to request that feature then we can keep track of conversation around that in one place?
merry steppe
YES
merry steppe
@placid ledge thanks https://github.com/WootingKb/wootility-issues/issues/72
copper raven
Hey - this might sound really stupid, but do y’all think there’s any chance you might figure out how to maybe partner up with nvidia to use a wooting keyboard as if it’s a mouse for reflex latency analyzer monitors?
Another premium feature and first keyboard to do so at that point 🤣🤣
prime knoll
that could be cool
hybrid lake
Hey - this might sound really stupid, but do y’all think there’s any chance you ...
This is a great idea. Don't have any contacts there, but can try randomly mailing some people 😛
ashen dune
@hybrid lake Would probably work best with Rapid Trigger enabled to cut down travel latency further
copper raven
@hybrid lake I have a few, but no one in the direct department for this specifically and most of them are business friends, but let me know if you need help to get in contact if you don't get through.
This is where you go
To report interest for joining the “partner program” for analyzer
Can also sign up here
lone swan
wooting.io is down, not sure if there is the actual "wooting devs" or just people deving with a wooting keyboard.
opal berry
Any idea why PayPal is not accepted at checkout like it says its supported on the website?
wide nymph
@opal berry It was recently removed on the US store due to raising Paypal fees and not being able to add a fee for the payment method. Where did you see it still supported Paypal?
In EU it is still supported, as we don't have to deal with the currency exchange, making it somewhat acceptable
flat wigeon
Is it intended that switching profile updates keyboard lighting even though it is locked by the RGB SDK?
strong siren
It didn't do this before fwiw
Switching profiles didn't have any effect on the lighting. I don't know when this changed exactly
placid ledge
That's not intended
Will have a look at it
or even better open an issue on rgb sdk
placid ledge
Ahahah, nah, just caught at the right time. Thanks for opening the issue! Will hopefully be able to find some time to look at it this week as should be small and get it included in next beta
copper raven
#🤖│community_dev message
Don't want to tag any of the woot devs that would be relevant for this, so just hoping you'll see it eventually, is there any update on this?
I have a few news and can pull some strings to make this really happen
would be really cool to see it being the first keyboard supporting this, competitors will spend a good amount of time before they'll do so : )
wet knot
It wont happen.
copper raven
How come?
hybrid lake
would be really cool to see it being the first keyboard supporting this, competi...
I kinda forgot about this sorry, let's get this rolling. It's a great idea. I'll PM you
flat wigeon
The analog SDK does still crash on UnInitialise()?
flat wigeon
My KSP crashed upon calling UnInitialise()
flat wigeon
I used the wooting_analog_wrapper.dll from the WootingAnalogSDK.Net Nuget package (0.5.0) and the current WootingAnalogSDK.cs (with serialisation removed).
placid ledge
Hmmm, that's strange, I'll have to have another look at it
quiet root
wooting.io is down, not sure if there is the actual "wooting devs" or just peopl...
just people developing stuff using the SDKs
flat wigeon
Can I query and set the FN state from the host?
placid ledge
Like setting Fn lock on or just to get it to act like fn is being held?
flat wigeon
Ultimately both, but one of it would be sufficient for now
rustic lichen
Maybe with a script that inputs scroll depending on the analog value.
Try this with your mouse :
Scroll a web page or this thread by one « click », see the page move by a mere 2-5 lines. Repeat.
Now, imagine a script doing this for 1/s for 10% analog, 5/s for 50% and 10/s for 100%.
Values are improvised.
placid ledge
Ultimately both, but one of it would be sufficient for now
Hmmm, I don't think there's any real way for you to do it right now. What's the use case?
flat wigeon
For setting the FN state: put FN on another device
To be honest I'm not sure anymore if I really want to do this.
But at least I need to be able to query the FN state to handle extra functions and lighting on the FN layer properly.
rustic lichen
Kinda wanna set it up and try it out ahaha
I’m waiting my HE and already want to do many « code » related thing with it...
-A 49-60+ key piano script/remap with music software (pianoteq someone ?)
-Put my simulators to their real limit (Euro Truck, BeamNg and so on)
-Entire Web brower interface ?
I know, I know... many of my ideas will fall apart day 1 😂
floral charm
placid ledge
@glossy dagger I think this is prob what you need https://github.com/WootingKb/wooting-analog-sdk/blob/release/v0.5/SDK_USAGE.md
glossy dagger
oh, missed the bit about wooting-analog-wrapper ... where is that library located on a typical install?
placid ledge
It's not installed, you'll want to get the wrapper from the latest release: https://github.com/WootingKb/wooting-analog-sdk/releases
glossy dagger
ah fair
placid ledge
it links to the wooting-analog-sdk shared library that gets installed with the SDK. The wrapper is almost like a helper that safely handles loading in cases that the sdk isn't installed
glossy dagger
yep
and presumably the other advantage is that the wrapper doesn't have to update when the SDK does
placid ledge
exactly
so you can just link to & bundle the wrapper and your app should be able to stay compabile with future analog sdk release without any work on your end
it also safely handles missing features, so if at some point a new function gets added and you use it in a newer version of the wrapper, then the wrapper will handle the case where the user has an old version of the sdk installed
glossy dagger
wooting_analog_read_analog takes in a scan code, is there any SDK-provided way to get the correspondence of scan codes to the row/column coordinates in the RGB SDK? or do i have to put a table in my application
placid ledge
I was kinda expecting you'd run into this, for now, you'll need to set up a table. I've got plans for making it a bit easier to use in tandom with the RGB SDK, see: https://github.com/WootingKb/wooting-analog-sdk/issues/12
I imagine you'll prob want to just use the standard HID codes which are given in the analog SDK by default for your mapping
glossy dagger
https://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html#scancodesets wooting_analog_read_analog takes the USB column from this table by default?
placid ledge
Yes
You've got a few different choices for keycodes as you can see under the Keycodes heading in the link I sent you before
glossy dagger
@placid ledge okay, so yep there is definitely some bug with the RGB not working, unless i'm doing something wrong with the API, but i don't think so
placid ledge
Have you tried just lighting up some keys manually?
glossy dagger
wait what the
okay, now wootility doesn't seem to be able to change the colors...?
now it is
aaaaaaaand now the API is working again, great
well idk what's going on, but there seems to be an intermittent issue where
- the keyboard can't process RGB updates, instead attempting to use the API just disables wootility effects and sets the LEDs to their normal color
- wootility can't write color profile changes to the keyboard
not sure what causes it, but replug seems to fix it when it comes up
placid ledge
if the keyboard still thinks the RGB SDK is active then changes set by wootility will not be reflected on the keyboard
glossy dagger
that might be something to do with it? idk
placid ledge
you using the latest RGB SDK, also, which commands are you using to set colours
instead attempting to use the API just disables wootility effects and sets the LEDs to their normal color is an indication that the RGB SDK has initialised
glossy dagger
latest, and i use wooting_rgb_array_set_single followed by wooting_rgb_array_update_keyboard
placid ledge
as effects don't really work when using the RGB SDK so it sets all the colours to be what the profile has set on it for the inital colours
are you just initialising once at the start and closing it once when done?
Once you init you'll see that behaviour you described disables wootility effects and sets the LEDs to their normal color then after that any colours set by the sdk should be immediately reflected on the keyboard
glossy dagger
right so to be perfectly honest, i'm probably not following the spec exactly, so the issue might just be my fault
in particular, the program i'm using to send RGB updates is a python program using ctypes to wrap the DLL, and it's also multithreaded
because it's multithreaded, there's ... not a very easy way to have cleanup code that runs when the program is about to terminate
this shouldn't be an issue because i intend to keep this program on pretty much all the time during normal use, but during development i obviously need to restart it sometimes
my current hacky solution is to have a second program that loads the DLL again just so it can call wooting_rgb_close
but i guess initializing twice and closing once occasionally causes issues?
placid ledge
Interesting setup
I wouldn't have thought that initialising twice would be an issue, although, that's not a scenario I have tested
as long as you run wooting_rgb_close it should put the keyboard back into the regular state so that Wootility can work with it properly again
balmy iron
Yeah, the SDK is for making your own .exe, put simply
hexed zodiac
so what do i code in?
balmy iron
Whatever language you want so long as it can call C functions (so most of them)
balmy iron
That's not a language I'm too familiar with, but look up Python CFFI
balmy iron
Google (or your preferred search engine) is your friend here
balmy iron
Yes
hexed zodiac
so i went to instilation
i have 3.9
is it telling me to use visual studio
so i habe visual studio with the python module
what do i do now
balmy iron
Good luck, I can't help you because I don't do any Python and I don't do any development on Windows anymore
hexed zodiac
how do i use the sdk?
balmy iron
https://dev.wooting.io/ read le docs, hey they even have some hints on how to interface with Python using ctypes which may or may not be simpler
hexed zodiac
i cant find the bits about python
hexed zodiac
i dont know how to do this
Introduction
If you wish to use the SDK, you should be dynamically linking to the wooting-analog-wrapper library and shipping it with your application. The way the SDK works is that it uses the wrapper to try and find the SDK at runtime, so it may gracefully error if the SDK isn't found. The wrapper library just passes through SDK calls to the actual SDK, so if there is an SDK update with new features you should update your wrapper when needed.
Getting Started
To get started using the SDK at the moment you'll need to build the entire repo by running cargo make.
Then you should add the output directory to your PATH variable, appending PATH TO REPO/target/debug to PATH on Windows and LD_LIBRARY_PATH on Linux/Mac. Once this is done, copy the wooting_analog_wrapper library to your project directory and get started!
balmy iron
To make it easy you should probably just get the prebuilt release, what are you trying to do?
quiet root
@hexed zodiac https://github.com/BattleCisco/pyWooting
heres example code for rgb and analog
plus the wrapper ofc
placid ledge
Note: That uses the old analog sdk which is now broken, but should be a pretty solid reference for getting going with the sdk's and python
hexed zodiac
can you explain whats going on wtuth it
rich sparrow
Does anyone know if its possible to bind the mousewheel to a key through additional software? Basically making it scroll down the further you press down the key. Trying to get variable movement speed working in Escape from tarkov
foggy pumice
Note: That uses the old analog sdk which is now broken, but should be a pretty s...
Does the wooting keyboard 360 movement work on xbox one series s?
placid ledge
Does the wooting keyboard 360 movement work on xbox one series s?
Don't know for certain, as I'm not really aware of anyone testing it. But if I had to guess, I'd imagine it wouldn't given that people who've tried on ps4 only get standard keyboard behaviour
quiet root
ya but the xbox usually handles xbox controllers which the wooting says it is
placid ledge
true, depends on what level of verification they do on xbox for legit controllers, I'd be curious to see what result would be with testing it on xbox
foggy pumice
true, depends on what level of verification they do on xbox for legit controller...
I’m willing to test it mind dming me I have an Xbox series s with 120 FPS it’d be cute if I got one sent for free 🙂
@quiet root
quiet root
LOL
ya no
id rather buy an xbox myself
plus this question isnt really for this channel i think. it fits better in #archived_questions_answers
placid ledge
@chilly oar in relation to what you looked into with the udev rules, rgb sdk etc. (thought it may be more suited here). The issue with the rgb sdk does seem a bit concerning, it shouldn't need any more access, as it makes use of the same interface the Wootility uses to communicate with the keyboard, so should only require that interface. The RGB SDK in general is in a weird state as I don't really intend to keep it going in its current form with Lekker, I've been developing a more generic communication library with the keyboard in Rust alongside lekker firmware development so I imagine that I'll use that as a basis for a RGB SDK for lekker onwards and will make sure to get that issue resolved so more narrow access permissions can be given.
I like the investigation into an approach for udev which only gives permissions to the required nodes and not everything. That's defo a good improvement, but unfortunately as you seem to have discovered it's a bit tricky due to the limited filtering nature of those rules. I think we can look into it more deeply with the lekker firmware as we'll be doing the PID switch and such so we have more room to make significant changes to the USB interface
balmy iron
Coolio, looking forward to that
Although on the other hand I think there is maybe a bit too much tinfoil hattery going on since Windows seems to be all yolo users get full access whatever 😄
chilly oar
Indeed, by using different device IDs you know the exact static interface number.
The more generic approach would be to use a vendor defined class number, than you can filter by that. You only need to check if Linux creates the hidraw node for that because that is maybe not the case and so prevent this is a solution.
placid ledge
Although on the other hand I think there is maybe a bit too much tinfoil hattery...
Possibly, but we can always strive to have a better setup than windows 😄
balmy iron
And if it doesn't then it should be fairly easy to fix that with rules
chilly oar
I would also like to see that the configuration interface is separated from the RGB stuff. So that apps which just run the RGB SDK can't alter the device.
placid ledge
Indeed, by using different device IDs you know the exact static interface number...
Yeah, will have to do some investigation into that with the class numbers.
placid ledge
I would also like to see that the configuration interface is separated from the ...
Hmmmm, that is a good idea, would be good to limit the scope of the RGB SDK. Guess it depends on how much of the other commands we want people to have access to. As with the library I've been building up, you could theoretically end up with lots more options for what is achievable, which may be a desirable for people who want to have more custom control over their device outside of wootility. Although, outside of that, one big reason to split them up is to avoid interference with the RGB SDK and Wootility, as, atm if you use RGB SDK while using wootility it can cause a lot of issues due to how the interface works.
chilly oar
The whole context handling can be maybe improved. Looking at the current behavior I would imagine there are three separate areas.
Using the Wootility to control all, using of the RGB SDK to control only the colors, using of the RAW SDK to only get the analog values.
So the RAW SDK would be independent because it should be read only anyway, while the Wootility should rule over the RGB stuff. So maybe the Wootility stays as is and uses the configuration interface while the RGB SDK uses a different interface which shares the same internal functions but has a lower priority.
But in the end I still prefer my previous suggestion to let the Wootility have the only permission to control everything and all apps need to communication with the Wootility. Meaning the Wootility needs to be running in order the RGB stuff can work. Doing that you are may able to block apps which are known to be bad. The user can decide which app is allowed to have access and he would later on be maybe able to block certain keys for overriding the color.
By the later approach it would be possible to use more than one app at the time. It would be also possible to setup a priority list. To maybe limit certain apps to specific key areas.
Basically to use the same handling as Razer.
This is similar to the old idea from Wooting to allow user to create their own plugins for the Wootility.
balmy iron
I'd rather not have something always running, unless I could make it be socket activated and only run when needed
chilly oar
It would be possible to outsource it into a service.
It's maybe not as simple anymore as it is now but the current method has a lot of problems when more than one app is used.
I imagine adding a reliable handling into the keyboard would be a nightmare.
Every app would need to claim a handler and the keyboard would need to deny a request if there is already an app which has the control. In order to ensure that the app which has the control is still active it would need to send a heartbeat.
By using that method the keyboard would be able to inform the app that it has temporary no control over the colors (because the rule is to be nice) as long as the Wootility is active. Like when the Wootility is the active window it can inform the device and the device can inform the app. So as soon as the Wootility is active the device shows the color from the Wootility and if not the colors from the app.
So then an app would be in one of these states:
- no connection to device
- the app has the control and it's active
- the app has the control but the colors are overwritten temporary by the Wootility
- the app has no control and needs to wait to get it
While only the first app can control the colors and every other app get informed that there is already another app which has the control.
If an app dies the device would know about it due to missing heartbeat. Then the next app can get the control.
But I don't really like if the device has to much into it, it should only handle basic stuff. All the higher ranked intelligent things should not be handled by the device itself.
flat wigeon
Hmmmm, that is a good idea, would be good to limit the scope of the RGB SDK. Gue...
I'm still confused why you don't use report ids but instead have a magic 16 bit number (which is AFAIK always the same) instead. With report ids other programs would still read the reports but can process them correctly. Which is my main issue, if Wootility does something I get a report of which I don't know what kind of data it contains. Same goes for Wootility which in turn trashes the keyboard configuration.
balmy iron
Of course the best way of handling analog keyboard input would be to encourage it to be a proper standard supported at the OS level
chilly oar
@flat wigeon The magic number is just to ensure that no other app tries to communicate with it. So that the device knows it's a legit communication with the SDK.
There is no report number if the report structure don't provide two different structures and because the report has just one it's suppressed. What is the advantage if the Wooting would add more structures into the report?
Also there are already a few problems with Linux using the usage numbers, I don't think using report IDs would make that better.
flat wigeon
Actually I meant the input reports from the configuration interface
chilly oar
@flat wigeon And? The configuration interface is also used for the RGB stuff.
There is no separate RGB interface.
flat wigeon
There are several different input reports with the same id
chilly oar
What?
flat wigeon
err without id
chilly oar
This is the report and there is just one structure (one for ingoing, one for outgoing & one for the feature) and so just one report ID and so it's suppressed.
flat wigeon
What I mean is, since there is no report id and the magic number is always the same, I can't really tell apart different reports
chilly oar
Which reports do you want to differ?
You send a feature or a report and you get an answer. Because the device can only handle one connection there is a problem as soon as two apps want to talk to the Wooting.
But this has nothing to do with the report per se. This can be fixed if Wooting would add an indication value which is also used as the response so the app can filter which answer belongs to it.
Like if my app would send 0x42 after the magic number and if the Wooting would put that value into the reply my app would be able to check against all incoming messages and only react if the reply contains the value 0x42 so I know that this reply belongs to my app and not another one. But again this has nothing to do with the report ID.
Due to this problem you can't have two Wootiltiy instances open at the same time.
flat wigeon
Other devices typically handle this with report ids.
Not really to support more then one application, but they do
And it's not necessarily an issue if you get reports that don't belong to you if you can interpret it correctly.
chilly oar
@flat wigeon A report ID is used to combine two or more different structures or reports (for example interfaces) into just one interface.
Like you can have a mouse on report ID one and a keyboard on report ID two. But you can also have five individual joysticks on the same interface with report ID from one to five.
This is used to spare interfaces and so endpoints and so buffer. But because they share the buffer this can also cause problems. I'm not 100% sure but I would assume you can only send and receive one report at the time. So sharing the interface would also reduce the effective polling rate.
With the report ID you can easily setup individual instances of a feature. Like with my joystick example above. So instead of creating five joystick interfaces which have the same structure you only need to setup one and just add the five reports ID.
flat wigeon
So it does make a big difference if you use a report id vs you put an identifier into your actual data?
chilly oar
These are two completely different things.
I haven't found the source where I read about it. It's used but not really explained here: https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf
At least on a quick search I haven't found the description there.
On A.7 on site 134 is an example.
So each interface gets a USB node, if there are multiple interfaces for a device it gets an additional device node which is then the parent USB node for all the interfaces. Each interface will then get its function node (the HID device). By using report IDs you can create a composite device with only one interface. So then there is only one USB node while each individual collection with it's individual report ID would get a different function node (the HID device). So the entire device tree would look different...
chilly oar
@flat wigeon I found it... It's described here: https://www.usb.org/sites/default/files/hid1_11.pdf
flat wigeon
Oh, that's how it works
chilly oar
to a particular report. For example, a Report
descriptor could define a 3-byte report with a
Report ID of 01. This device would generate a
4-byte data report in which the first byte is 01.
The device may also generate other reports, each
with a unique ID. This allows the host to
distinguish different types of reports arriving
over a single interrupt in pipe. And allows the
device to distinguish different types of reports
arriving over a single interrupt out pipe. Report
ID zero is reserved and should not be used.```Thanks for the info
cedar jolt
can you lube the flare tech switches without losing the anlog features ]
chilly oar
Yes, you only need to be careful to not lube the prism and to be more parsimonious so that the lubing can't flow onto the sensors later on over time.
quiet root
really think woot_dev and its accompanying role need a clearer name cause people seem to think this is for developers working on the actual product and not for community members working with the released SDKs and such
tidal anvil
Or com_dev for short, then add a description in the top of the channel that this is for community developers?
hybrid lake
done
wet knot
Ohh rename
glass radish
