ETHREAL1

Ya that' what I was thinking as a work around but it would be nice if you could just tell iCue as much... also the strip only has input but I was hoping that something like this; would work. EK-Loop D-RGB 2-Way Splitter Cable – EK Webshop (ekwb.com)

I have been thinking about switching my system to a full custom water cooling loop. I currently have a Corsair Commander Core XT as my iCue controller and would like to use just it. My case is the Fractal Design Torrent Nano and it has a built in 6 LED ARGB strip on the PSU shroud. I have currently been using a 3-Pin adapter to have the Core XT control that strip. If I get a Hydro X CPU block, GPU block, and pump I can no longer use the strip by the looks of it. What I was wondering is why? Why could I not just have the strip before the CPU block (that has to be the endpoint) and set the number of LEDs in the strip? Why are both of these options not available? So TLDR could ARGB strips be added to the Hydro X configuration in iCue. And could we please be allowed to set the number of LEDs on a strip.

I don't see the relevance to what I'm saying. I am just talking about while the headset is charging with the system fully off. You can just use Dolby Atmos Via the Dolby access app... I do this all the time. I think it is paid but is like $5? and is linked to your MS account and works on Xbox as well. I am fully aware. But what I propose is that the fall back should be black not white in firmware. There is already the charging light when its plugged in so why does the RGB need to be blaring WHITE???

Oh I know that is what is happening. And I'm saying that either there needs to be a way for the Commander Core XT to still receive that data or there needs to be a way to set a hardware profile that either has a static or probe based curve that is save to the Commander Core XT. Oh I have the CPU cooler fans controlled by the MB as iCue occasionally crashes. (Have a custom scheduled task to restart iCue on crash but it has to wait like 30 seconds) But the CPU is an OCed 5950X and is a bit of a furnace. With just the CPU fans under a full HEVC handbrake load it still reaches 90C. But with the case fans going its a meager 75-80C. Even with just a 20% duty cycle I can get it down to 85C. P.S. I have built numerous systems. 12 in fact. I only ever reach out to support or forums when it's something completely out of my control.

<value0> <enabled>true</enabled> <temperature>55</temperature> <rpmPercents>0</rpmPercents> </value0> <value1> <enabled>true</enabled> <temperature>56</temperature> <rpmPercents>20</rpmPercents> </value1> <value2> <enabled>true</enabled> <temperature>65</temperature> <rpmPercents>20</rpmPercents> </value2> <value3> <enabled>true</enabled> <temperature>70</temperature> <rpmPercents>30</rpmPercents> </value3> <value4> <enabled>true</enabled> <temperature>75</temperature> <rpmPercents>50</rpmPercents> </value4> <value5> <enabled>true</enabled> <temperature>80</temperature> <rpmPercents>75</rpmPercents> </value5> <value6> <enabled>true</enabled> <temperature>85</temperature> <rpmPercents>100</rpmPercents> </value6> Ripped right from the cooling profile. Have one for CPU and GPU both the same curve just different sensors.

I mean exactly that. I want the fan curve to be based off of CPU and GPU but have it switch to off there thermal probes or to just a different static curve when it losses iCue contact. but this is not possible.

I have a Virtuoso headset. I like quite a lot with two exceptions. One is that there is no hardware lighting profile. This is very annoying as when you charge the headset with the system off the headset blares WHITE all over my room. This can make it quite hard to sleep. I would like to be able to set this color. Or at the very least it needs to be made black. The other issue I have with the Virtuoso headset is the non replaceable battery. But I digress.

I have a Commander Core XT. I have all my fans connected to it. I have a fan curve that that uses 0 RMP mode for all said fans. When I lock my system my fans stop even if the CPU is under full load. Either iCue needs to be able to control the fans even with no user logged based on last cooling profile or a way to set a hardware profile needs to be made.

Things are getting even more interesting. and in the process may have found a temporary solution. It appears to also matter if the iCue windows is currently open or not. If I have a profile open in iCue and it has the wrong DPI profile if I change it and the change what iCue profile is being displayed the then DPI change will not be saved. But if you change the DPI profile, close iCues window, reopen the iCue window the DPI profile will be updated in the general profile. This also means however that you have to disassociate iCue profiles from programs so that you can close iCue and save the profile.

Searching for the ID for the profile that should be "active" finds nothing. iCue is not updating profile data. However, changing the "active" DPI profile in iCue does update the DPI database and what profile is considered "active". I have also noticed that when swapping between profiles quickly then DPI databases "active" flags can get delayed or even missed witch is likely the issue that I am having. The profiles not saving and the DPI file being written to to slowly. OK Corsair, I've done a LOT of investigating. Time for you to FIX IT.

Interesting development. I think iCue is not properly updating profile data. I have the DPI database on the bottom left, the iCue profile top left, (yes I'm sure this is the correct profile) as you can see in iCue when I manually activate the Division 2 DPI profile it is not updating the saved profile. I have highlighted the relevant DPI ID. the ID still saved to the iCue profile is the ID that is correlated to the "Default" DPI profile that is also listed in iCue.

In other news there has been another development.... For whatever reason every time switch profiles a new set of my custom cooling curve profiles gets made on my commander core XT.... And I can not delete them..... I think Corsair has something majorly wrong with profiled database management.

I think the way it is with the DPI having there own profiles is always how iCue has worked. Now before iCue with what was is.... corsair engine or whatever it was called I think it was baked into the general profiles. I've used iCue as long as it has existed. I think this is basically the same bug. I also see that behavior but the DPI amounts also change with them.

Hello, Love the usefulness of iCue. But I have run into a roadblock. I often use iCue to fix what I think are bad game input designs. One such example is Halo Infinite Campaign where I have macros for swapping to and using equipment as one keystroke instead of having to swap to and then use equipment over two keystrokes. Fast forward to (or go back in time?) to The Division 2. I have found that I really want the grenade behavior to be that when I press and hold X to show the throw guide and then when I release X to then throw the grenade. Unfortunately the game does not allow for this behavior. Also unfortunately iCue does not allow me to add this behavior either. But if one could assign more than one action to a single key then it would be possible. I could have one macro be the pressing of the X button in game and have it trigger while the key is pressed and then have a second macro set to press left click on key release. I also have some DPI related stuff that I would like to do while changing profiles also bound to the same key. So when I press the M key to bring up the map I want it to change the DPI and the profile to change what some of the other keys do. All this could be fixed by allowing multiple actions per key.

Ok, So after my experiments I have concluded that for whatever reason DPI profile relation to general iCue profiles is to blame. More specifically when switching between profiles with different DPI profiles. In fact I discovered that if switch quickly between multiple profiles all with different DPI profiles the DPI relations will get swapped. AKA if you have say P1 with DPIP1, P2 with DPIP2, and P3 with DPIP3 and you quickly swap between the 3 profiles you can end up with say P1 ending up with DPIP3 for some reason. This happens even if you don't change any settings by the looks of it. It also seems to do the same with the mouse acceleration. If one profile has or even at one time had it on and you switch profiles there is a chance that when the DPI profiles get swapped the state of the mouse acceleration can also be changed. So what was happening to me is definitely an iCue bug. It can also be reproduced on a machine that has never had iCue installed before that has had 3 profiles made and 3 different DPI profiles. I would post a video of this happening but it looks like these forums don't accept video files. In short, iCue mouse settings are broked to crud and it needs to be fixed. What I propose as a fix is to have the DPI profiles simply be part of the general profiles instead of having there own subset of DPI profiles. The only times I have had DPI profiles shared is the default, and Borderlands 2-3. in both cases what I do is just copy the entire profile and then modify it to fit the games needs. There is no reason the DPI settings have to be a separate profile database.