It should be the SIRi 22...Wouldn't worry about it, I was going to upgrade my GPU with my monitor, but I've delayed that because of Project: TEC. I can certainly wait to get an "Iris 22" button
-
Save 15% on ALL SFF Network merch, until Dec 31st! Use code SFF2024 at checkout. Click here!
Small Update
Support for Cues is now implemented. Here's a short demo:
It's a little hard to properly film this, I'll have to experiment a bit. In this case I tried to have the LEDs out of focus to make the colours mix better. Defusing the light with paper leads to a very strong glow around each LED and for some reason causes very noticeable flicker. Neither is visible with the naked eye, but on video it just looks awful.
Filming directly alleviates this, but you can see that the bright cyan and yellow in the third animation are very washed out. A proper camera probably wouldn't hurt, either.
Mildy interesting side note: This implementation doesn't use floating point arithmetic for efficiency reasons. This is important as we have to calculate a full frame as often as possible each second. The Ramp Parameter that you can set in the Iris Visualizer is not stored on the Iris 16 as a value between 0 and 1, but between 0 and the Cues duration. For every arithmetic operation I need to make sure that the intermediate result is a positive integer. So division is always the last step in any calculation as it comes with a probable loss in accuracy which would be amplified if I then executed further operations after it.
Next steps in the firmware are support for Schedules and thus Periods - which means I'll need to do some work involving dynamically-sized arrays - and implementing a Mass Storage driver.
When my 3D-printer arrives I also want to experiment with transparent filament for light guides/diffusers. The LEDs currently are almost not diffused at all, which makes the colour mixing unsatisfactory, and I think there's some experimentation required to get a good result on this.
Support for Cues is now implemented. Here's a short demo:
It's a little hard to properly film this, I'll have to experiment a bit. In this case I tried to have the LEDs out of focus to make the colours mix better. Defusing the light with paper leads to a very strong glow around each LED and for some reason causes very noticeable flicker. Neither is visible with the naked eye, but on video it just looks awful.
Filming directly alleviates this, but you can see that the bright cyan and yellow in the third animation are very washed out. A proper camera probably wouldn't hurt, either.
Mildy interesting side note: This implementation doesn't use floating point arithmetic for efficiency reasons. This is important as we have to calculate a full frame as often as possible each second. The Ramp Parameter that you can set in the Iris Visualizer is not stored on the Iris 16 as a value between 0 and 1, but between 0 and the Cues duration. For every arithmetic operation I need to make sure that the intermediate result is a positive integer. So division is always the last step in any calculation as it comes with a probable loss in accuracy which would be amplified if I then executed further operations after it.
Next steps in the firmware are support for Schedules and thus Periods - which means I'll need to do some work involving dynamically-sized arrays - and implementing a Mass Storage driver.
When my 3D-printer arrives I also want to experiment with transparent filament for light guides/diffusers. The LEDs currently are almost not diffused at all, which makes the colour mixing unsatisfactory, and I think there's some experimentation required to get a good result on this.
Reducing the camera shutter time will induce flickering (chopping up a PWM signal), so instead if you have any ND filters, or even sunglasses, though should reduce the brightness of the LEDs and prevent them washing out without shortening the shutter time.
Goddamn sunglasses are such an obvious solution. Thanks a lot for the explanation!
Holy crap! I picked a bad week to be absent; so much has happened so quickly! First of all, I'm glad to hear that it'll be clicky, that's of a stupid level of importance to me.
Second of all... Is there any amount of money that we could throw at you to make this plug into (read: replace) Asus Aura Sync? The idea of Aura Sync is cool, and the hardware side of it works flawlessly, but the software side of it is... Lacking. Badly.
It hasn't been updated in a long while and has features missing that, a) seem very obvious, and b) are simply extensions of already existing features in other modes, so shouldn't be missing because of any technical issues. Oh, and c) really poor documentation. Other than that, I love it.
Your software solution already seems to be head and shoulders above anything else out there; I'd really love to have it be my sole solution.
Second of all... Is there any amount of money that we could throw at you to make this plug into (read: replace) Asus Aura Sync? The idea of Aura Sync is cool, and the hardware side of it works flawlessly, but the software side of it is... Lacking. Badly.
It hasn't been updated in a long while and has features missing that, a) seem very obvious, and b) are simply extensions of already existing features in other modes, so shouldn't be missing because of any technical issues. Oh, and c) really poor documentation. Other than that, I love it.
Your software solution already seems to be head and shoulders above anything else out there; I'd really love to have it be my sole solution.
Holy crap! I picked a bad week to be absent; so much has happened so quickly! First of all, I'm glad to hear that it'll be clicky, that's of a stupid level of importance to me.
Hehe, you should probably stay clear of custom mechanical keyboards then
Second of all... Is there any amount of money that we could throw at you to make this plug into (read: replace) Asus Aura Sync? The idea of Aura Sync is cool, and the hardware side of it works flawlessly, but the software side of it is... Lacking. Badly.
It hasn't been updated in a long while and has features missing that, a) seem very obvious, and b) are simply extensions of already existing features in other modes, so shouldn't be missing because of any technical issues. Oh, and c) really poor documentation. Other than that, I love it.
It would be possible to make an adapter that allows plugging the Iris into an RGB LED strip header to read out the colour and display it, so it could easily be controlled with Aura Sync. One could also use one of these to control and RGB LED strip with the Iris 16, so if that's all you want, we can definitely make it happen at some point.
But, for USB devices and on-board LEDs it gets trickier. Even if I could interface with all the custom and undocumented API of Aura Sync stuff (which would probably take a significant amount of work just for reverse engineering), the Iris 16 itself does not have enough processing power to do any of this on its own.
The only replacement for a system like this is a new piece of software that re-implements the API and just does it better. If a fan does that, probably not an issue, but a company coming along and doing this while also supporting competitors products, it risks a lawsuit from ASUS. I don't want to be that company.
I appreciate that, but how would my current solution work for anything but the Iris 16 itself? Or are you talking more about the general concept that I'm using to encode lighting effects? Because that is also tailored to LED rings and strips, and would have to be re-thought for something like a keyboard.
Hehe, you should probably stay clear of custom mechanical keyboards then
It would be possible to make an adapter that allows plugging the Iris into an RGB LED strip header to read out the colour and display it, so it could easily be controlled with Aura Sync. One could also use one of these to control and RGB LED strip with the Iris 16, so if that's all you want, we can definitely make it happen at some point.
But, for USB devices and on-board LEDs it gets trickier. Even if I could interface with all the custom and undocumented API of Aura Sync stuff (which would probably take a significant amount of work just for reverse engineering), the Iris 16 itself does not have enough processing power to do any of this on its own.
The only replacement for a system like this is a new piece of software that re-implements the API and just does it better. If a fan does that, probably not an issue, but a company coming along and doing this while also supporting competitors products, it risks a lawsuit from ASUS. I don't want to be that company.
I appreciate that, but how would my current solution work for anything but the Iris 16 itself? Or are you talking more about the general concept that I'm using to encode lighting effects? Because that is also tailored to LED rings and strips, and would have to be re-thought for something like a keyboard.
Nah, I'm happy with my custom-capped Leopold for now. What I'm trying to do is ditch aura sync entirely - I'm not at all worried about controlling usb devices, just the Iris 16, an RGB strip, and maybe onboard motherboard LEDs.
I was under the impression that programming the Iris 16 was something done on the computer, and then you could load a pattern into its memory if you were using it for a different project. Is that not the case?
As for Aura Sync, I suppose that makes sense. They do seem to be fairly open with the tool, given the Aura SDK that they offer, but that's not the same as letting you reverse engineer it from the ground up. I guess I'll start investigating that blinkstick.
The onboard LEDs will be the biggest issue, because they can usually only be controlled by the mainboard manufacturers software.
Every kind of "dumb" LED could easily be controlled by the Iris 16 directly, but there's no software support for this right now, and for strips you'd need an adapter like the one linked above.
Yeah those are a pretty good option as well, the Blinkstick 2.0 Release Candidate software looks pretty cool.
Taking a look at the FAQ (PDF Download), it's by far not as open as you would first assume.
That is indeed correct. You generate a configuration file in a web-application and can then drag-and-drop that onto the Iris 16 (I'm working on the latter part right now).
What I was talking about is that the structure of these files is inherently designed for LED strips/rings, I don't know that it would work very well for anything with two dimensions like an LED matrix or a keyboard. But as you're only talking about LED strips, I could absolutely see this system work for them.
But, let's talk about what you actually want to do:
What kind of LED strip do you want to use anyway? A "dumb" one that can just display any colour you like? Or one with addressable LEDs? Are you concerned about syncing the Iris 16 with the LED strip at all? What kind of effect are you thinking about? Something simple like breathing or blinking?
Okay, that all makes a lot of sense. I'm certainly not looking for anything terribly fancy - just using dumb strips for backlighting. The most is probably cycling through a custom set of colors, or adjusting colors based on reported temps (but again, using custom colors.)
The dream would be something like Aura Sync's music mode, but with actual control over the colors and beat, instead of the presets you're locked into. (And yes, with all the colors synced.)
Speaking of expanding the Iris Ecosystem, I would absolutely love to have some RGB Hardline Tube Fittings. If all goes well with getting the buttons machined, it feels like a logical step
Dumb strips are absolutely doable! I need to check but I am fairly certain that I have three PWM outputs on the GIPOs. I'll see when I have time to implement this, but there's nothing complicated about it on the firmware side.
Only thing to think about is how the user selects that colour. One way would be to have it display the same colour as one of the buttons LEDs, or they could set a dedicated Cue for it.
Yeah that's a cool feature. I'd probably implement this as a kind of "dumb" mode where the Iris 16 only stores a pattern, but the colour and brightness is decided by the PC. This would require a separate program to run on the PC, so it's a bit of development work and I'll put it in the backlog for now.
Speaking of expanding the Iris Ecosystem, I would absolutely love to have some RGB Hardline Tube Fittings. If all goes well with getting the buttons machined, it feels like a logical step
Hm, not sure about that. First there's always the concern about fittings leaking, the risk of making those is a lot higher.
I guess you're talking about something like the TT Pacific fittings? Because those seem like "dumb" LEDs as well, should be very easy to control. I'd rather go into making a super awesome internal RGB controller that can control all those devices rather than making them myself. That's something I'm much more able to compete in against the big players. Every time these companies make an RGB controller, it's super locked in and mostly compatible with their own stuff. I wouldn't do that because I don't have an ecosystem to lock anyone into, and I'd make everything open source again so its easy to create stuff that is compatible.
Fair enough
my thought was mostly just that fittings are round and Iris is round, so maybe effects could be synced in some kind of "dumb" fashion. An internal RGB controller that's open source would be pretty awesome too!
Ah interesting, I didn't think about that. Though I do think that the aesthetic effect individually addressable LEDs have is quite different on hardline tubing, so a simple rotating dot for example might not be as cool looking as it does on the Iris 16, but something like flame-like flickering that speeds up or gets brighter (and thus longer in the tubing) with higher flow rate might be very cool. Definitely something to consider for the future
Last edited:
Curiosity
Too busy figuring out if I can to think if I shoul
Platinum Supporter
Bronze Supporter
M...M...M...M...Multi-Tier...Subscriber...
- Apr 30, 2016
- 724
- 838
I'm glad to see everything is going well!
I'm excited to need to modify my korkin to fit the 16mm, I think I'll fit.
I'm excited to need to modify my korkin to fit the 16mm, I think I'll fit.
I can't wait having the prototype! I know I am in the hat where you will pull some to deliver the first versions of Iris and that is awesome
I have some questions tho. as of now to me it looks like the patterns can be pre-programmed.
1.) how much time does it take to program the controller and start the new pattern?
2.) is it possible to run the LEDs with the previous program during re-programming?
to my usage I would like to display "real time" data on the LEDs. so maybe the most fluent solution for me would be driving the LEDs from the CPU directly. Do you think it could be possible? like keeping the USB interface but adding kind of a 'direct-drive' mode to the controller where e.g. a daemon running on the host controls the LEDs. changing between the modes by just clicking would be heaven itself
Not a secret, Iris would be kind of a network monitoring magic eye here.
Sorry if these ideas are already discussed, I might have missed them.
I have some questions tho. as of now to me it looks like the patterns can be pre-programmed.
1.) how much time does it take to program the controller and start the new pattern?
2.) is it possible to run the LEDs with the previous program during re-programming?
to my usage I would like to display "real time" data on the LEDs. so maybe the most fluent solution for me would be driving the LEDs from the CPU directly. Do you think it could be possible? like keeping the USB interface but adding kind of a 'direct-drive' mode to the controller where e.g. a daemon running on the host controls the LEDs. changing between the modes by just clicking would be heaven itself
Not a secret, Iris would be kind of a network monitoring magic eye here.
Sorry if these ideas are already discussed, I might have missed them.
Tbh, I really like that idea. But couldn't you run it over USB? I'm not sure how much latency that adds.
Do you think you'd be able make it monitor the temperature of the CPU or GPU.
Last edited:
Similar threads
