Implement CUE LFX (- Functionality)

[DarthAffe]

I'm honestly not sure if I'll do this. On first sight it seems to be really complicated without adding functionality that isn't already implemented or easy to add in CUE.NET. But I'll investigate it further before finally deciding.

[RobertBeekman]

I've been browsing through the docs for a while now and from what I can tell they've really gone with an approach that assumes you want to 'configure' the SDK like you would configure a custom profile in CUE (the program).

I'm not sure how much use this approach is when you're developing your own application (honestly for Artemis all I really want is detailed device info and the ability to send a bitmap, but that's mainly because I want to keep drawing separated from the device, this ofcourse doesn't reflect on other CUE.NET users).

I think (and kinda hope, because it looks like a lot of work) that this LFX extension is mainly an export of new functions they added to CUE2. I don't program a lot in C++ but I can imagine that LFX is very convenient if you don't want to be drawing stuff in C++ yourself. As for C# and CUE.NET however, it seems like you can get all this done with Brushes and a few simple animations.

Still, looking at these effects, it might be worth implementing them. From what I can tell looking at the docs CUE.NET only has the flash effect, these LFX effects would offer a nice extension to that, but you'd end up having to implement CorsairEffect and all related structs.

For someone creating an app purely focussed at Corsair this would be quite cool, but it would be rather daunting to be dealing with all the structs LFX opens up. Ideally you'd only have to worry about applying effects to the entire keyboard or a keygroup.

Same kinda goes for things like the progress bar. It's really quite easy to implement something like this in C# once you've got your basic lighting going, but applying a progress bar to the entire keyboard or a keygroup would mean less coding for people using CUE.NET

For me it seems like LFX is really useful for people that want to integrate Corsair support into their app/game without really too much fuss.

Of course this kinda goes for CUE.NET as well. At least in my experience when I download a Nuget package for something I want to do some quick setup and see results, expanding CUE.NET with these effects and loading bars would mean more results in with less effort, but once you're already creating your own effects the gain is already kinda lost.

[DarthAffe]

I totally agree with your point, that LFX is a great addon for the existing SDK and increases this "effort - result"-rate you mentioned, but I don't think that this applies to CUE.NET too. Wrapping all the C++-Functions (which are quite a lot compared to the SDK), adding memory-management (which is stated to be done by the user) and finding workarounds for color-blending (since there is no easy way to get the colors rendered by LFX) is way more work and most likely worse code than just implementing all the features in the way CUE.NET is designed (as brushes/effects).

I agree that it would be useful to have more basic-stuff which just works (no matter if it is the SDK or CUE.NET) and I thought about this some time ago. I even thought about implementing the LUA-Scripting so much people asked in the forum. But the be honest: I have no idea what is useful/needed and what not. I don't know what people want to do. I have my own usecases, which are quite limited and since I know how to use CUE.NET and the way it works, I have no problem creating special brushes/events for my specific problem.

I don't know how much people are in this space between CUE.NET as some kind of "low-level-API" and Artemis as a user friendly and easy to use "start and be happy"-solution.

I'd love to fill this gap if there is anything anyone would need :)

But to get back to the original issue: I don't think this can be done by wrapping LFX. LFX is great for people who are using the C++-SDK, but those people don't care about our C#-stuff. In my opinion it's better to try to use only raw SDK-functions (there are still plenty which would be useful and will hopefully someday be introduced in the SDK) and implement all that fancy stuff on top of this.

EDIT: I know that my laziness writing documentation is some problem here ... I'll try my best :p

[RobertBeekman]

First off I don't mind working on some more examples for the docs. I always find learning by example works best for me, perhaps that goes for others as well.

I've been refactoring Artemis' layer system to facilitate multiple layer types using an ILayerType interface. I'm quite chuffed about this one, all you need to do is implement it and add it to the Ninject modules, and you've added a whole new layer type. One thing that came to mind with this is a LUA-layer-type. It'll be a layer type that loads a lua file in which you can use the layer as a canvas to draw on etc. Should be dirt-easy to implement.

But to bring it back to CUE.NET, I'm not sure it'll benefit from a LUA-engine (which is probably why you haven't implemented one) because if you're using CUE.NET you don't really need LUA anymore. It's really something you'd include in something like Artemis, or even a standalone app

What I do think would be a great benefit is having more animations in CUE.NET. Perhaps an approach where effects are simply configurable classes that you can assign to the entire keyboard or a keygroup would work best. These effects would just take care of updating themselves on a certain rate in their own thread, and you could expose some delegates to allow hooking into their OnRender for people that want to do more advanced things.

Going out of your way to implement all the LFX methods is probably going to decrease the library's usability, so creating your own implementation that follows the style of the rest of your library is probably the best idea

And once again, to see these effects in action would probably be a huge benefit to people getting started with CUE.NET, and I don't mind creating some examples :)