In another thread you had commented that while the controller shows white LED's during programming, white is absent from the timeline editor.
Put some dead or nearly-dead batteries in your controller. The LED's will be pink instead of white during programming mode. Due to the low forward-voltage and high lumens characteristic of red LED's, the red LED tends to overpower the other LED's as the battery drains. Were we to offer white as an option to customers, we would soon receive thousands of support ticket complaints from customers telling us that their controller LED's are pink when they picked white from the color picked in the macro software.
It was not economical to install an additional voltage-booster circuit. For that matter, most voltage-booster circuits require a different chemical composition of battery cell than what Microsoft supplies. I can't remember the specifics (it's all in the datasheets if you want to spend that much time researching it), but the gist here is that the Microsoft packs are ****ty quality, and thus not capable of providing the higher amps required for a booster circuit to boost the voltage well above the forward-voltage of the green and blue LED's. Most voltage-booster IC's provided on the market are compatible with cell phone quality batteries.
A couple months back I tried desperately to boost the 2.3V-2.6V provided by the Microsoft battery pack, but could not, and after heavy research it basically ends up the Microsoft pack cannot be used with the low cost voltage boosters. That's the problem here, while AA's put out a nice 3.0 volts fully charged, and around 2.6-2.7V dead, the Microsoft battery pack only puts out 2.6V fully charged and as low as 2.0 Volts when dead. Hit up the datasheets for most blue LED's and you are not going to find a forward-voltage that low for blue. Hit up the datasheets for 1206-sized RGB LED's (the size required to fit underneath the "light tube" inside the Microsoft controller) and you won't find any LED's that have a forward-voltage that is truly compatible with Microsoft packs.
Therefore we made the decision not to allow white as a color in the GUI software. Since our hardware is not really capable of maintaining a nice true white throughout the entire range of voltages that are coming from customer batteries. 2.0v-3.0v is too wide of a variable range to deal with. There are simply too many variables and curves to reliably produce white over the whole battery range.
Perhaps if I had a whole lab full of technicians in a dark lab who could create highly accurate luminescence vs voltage curves for all of the LED's, we could create some translation curves to dim our LED's to compensate for the variation in voltage as the voltage changes. Ahh, but then you get into another set of issues with analog-to-digital conversion. It is difficult for this particular MCU to accurately determine the voltage of the power source. The MCU does have a 'steady' internal voltage reference that can be used to compare to the power supply, but dig into the electrical specifications of the MCU and that internal voltage reference actually tends to be pretty variable, in terms of the accuracy required to compensate for LED dimming due to variable voltage source!
Again sorry I do not have time to make a proper case for this with charts and graphs and formulas. We need some sort of drawing tool in the forums.