I was just browsing the source and noticed there was an XBMC add-on and an android app. I haven't test the android app yet, but the XBMC add-on works great! It allows you to load a different profile for default, videos, and music. I've got it setup to load liquid color full time, but switch to Ambilight when I play videos or milkdrop(music visualizations). This keeps the lights on when I launch WMC for live TV. Enjoy!

I have a problem with lightpack. I have everything working with colorswirl and and processing. But Lightpack won't work, the RX light on the arduino lights up when I press the "turn on lights" button in lightpack so it is communicating, but the led string does not light up.

CONTRIBUTION: Please try out my very-much beta program RPMLight.It is working well at 4FPS with 50 lights that are the 3-wire WS2811 bulbs.My sketch for WS2811 bulbs (FastSPIstream.ino) is included (the FastSPI library is not).

If someone can tell me what bytes boblight or LightPack sends, then I can update the sketch and people should be able to use these existing programs with cheaper 3-wire WS2811 bulbs. I will still continue to update my program. 1) Trying to use different API calls for faster performance (goal is to get minimum LAG, not FPS... 4FPS looks fine if lag is less then 250ms, but 30FPS is ideal if it does not lag response time). 2) Trying to design best looking color assignment for each bulb (how big a square [or triangle] to average [or max] to determine the color of each bulbe). 3) Planning on adding all sorts of non-adalight features (light in response to sound output, playback/creation/recording of "demo" files).

No downloads? Really? It should work with the normal WS2801 bulbs that everyone has too (you may have to change one variable in the sketch for the FastSPI initialization).

Here is an updated version that runs a full 30FPS with nearly zero noticeable lag.

PROGRAMMERS: I looked at the source code for Light pack (still haven't figued out the protocall though), and saw how it captures the screen. Their winAPI calls and pixel-color averaging are better then what I had in my 0.1 beta code, but this new version is miles ahead. I use CreateDIBSection to capture the initial screen-shot (very slow on Win7/8, but fastest method possible) then capture 50 portions of that with more CreateDIBSections (on XP you can do these directly from desktop). Then I use StretchDIBits to resize each portion to a single pixel (1x1 bitmap) and apply that color to the correct LED. It is soooo fast (especially on XP)... way faster then manually adding/averaging pixels (even using scanline). When playing a movie on Win8, my response-time (lag) seems way better then what I have seen from others on YouTube. I'll post a vid as soon as I get my 128-LED strand (this 50 strand doesn't fit around my 150" projector screen). NOTE: My math auto-calculates averaging squares for any number of bulbs, and it still seems lag free running at 128!

Next version will have a new UI, but I don't think anyone can get the screen-capture/averaging code much better then this version on a windows machine.

Sound to light would be a nice feature. Also if yours would be able to capture OpenGL games.

Otherwise i'm happy with Lightpack that does 27 FPS (Aero has to be disabled, otherwise its really slow) with 50 lights on my PC. And i like that its very easy to customize the light positions. And even calibrate the slightly different color tone of my 2nd LED strang.

EDIT: Sorry, I now realize you are not the maker of light pack... never mind. Hopefully he will chime in here. Your setup is a little too custom for my program in its current state (bottom row with larger squares is not supported). For people using a single strand equally spaced around their TV: Please give it a try! For anyone else even without LEDs, feel free to try it just to see my pretty boxes change color at 30FPS even with Windows 7/8 Aero Enabled.

I looked around in your Google code. You should try using StretchDIBits to shrink to 1px instead of counting them. Mine works fine with Aero at full speed now (capture screen once, then recapture off that for the frames, and shrink them to 1px)

So I don't have to figure it out from your code, can you tell me the byte-structure yours (and boblight) sends? I want to make my WS2811 arduino code compatible with existing software.

Also, you can try out my software even without lights... the preview thing is pretty cool (set bulbs to 50, BGR, 0-shift, not reversed... then the 50boxes will match the edges of the screen). I want to add features for number of averages too, so you can just turn on the sides, or make it all 1-color average, or do all 50 individual leds as-is. When I was counting pixels I had a bunch of averaging math that would average pyramid's around the bulb instead of squares, but shrinking a square to 1px is soooo much faster. I've thought of counting MAX color too instead of averaging, or maybe MAX averaged with AVG. Any insight on what winds up looking best that you can give me? (Right now I average a rect that is 120px x 30px for the top and bottom, 60px by 120px for the sides, and 60x60 for the corners... all dynamically adjusted based on LED # and screen-resolution, assuming 16x9 screen ratio... these numbers are just how the math turns out for 50 leds). That math was chosen for my pyramid code... now that I am shrinking to 1px, I can easily change those squares to anything (I think I'll make the top and bottom 60px now instead of 30). Your color-widget thing is pretty cool, but I do not plan to copy it, I just want settings for the math, and let it auto-configure from there.

The gap below is for the stand of my montitor. I dont use a wall mounted TV. And since it stands on my desk i did not put as much LEDs on the screen bottom as i put on the sides and top.

I positioned the light capture fields exactly where my LEDs are positioned to get the most accurate detailed response (which i think is important for 50LEDs on a 30" screen, in Starwars lasersword fight scenes the light beam really "extends" out of the screen accurately :) ). Also the size of the light capture field should be in a good balance with the screen resolution. 60 pixels is too small on a 2560x1600 screen and might produce twitchy colors because it reacts too the smallest light/color changes in the source material. Also dont forget there are 16:10 displays out there.

But anyway, if your program supports OpenGL and D3D capture (which Lightpack doenst) i would give it a try for lighting up my games. Even if its not as accurate as Lightpack.

But i think you should at least add the feature that the user can decided how many LEDs are on each screen side and leaving a gap for the screens stand. Also i think the color calibration feature is important..since different strands can produce different color tones...or sometimes even only a single LEDs is off.

I'm using WinAPI calls, so I think the same limitations apply. You could try it and see if my colored boxes work or not (if you can see my program while running your OpenGL game). My calls to the desktop seem to always get the primary monitor, even though my second monitor is to the left of it.

I will probably add support for multi-monitors and maybe skipping the middle bottom 1 or 2 pixels (or just being able to turn off any pixels you want... wasteful yes, but ensures a properly spaced grid without the user needing to custom set-up each bulb).

Supporting 16x10 should be easy enough... I let people enter a ratio to do all the math instead of hard coding Top = NumLED / 3.125 (for 16x9).

The pixel size were examples that depend on resolution and NumLEDs. 1920x1080 with 50 leds works out to 120px between each LED, so from every edge I was doing 60px left, right, and in. I will probably change it to go deeper, so it averages a 120px square. Probably make that a user-adjustable slider too.

I don't know much about adjusting color and gamma. I could easily have an addition and/or multiplier to the byte before sending (ie: LEDred = ScreenRed * x + y). I need to look at the LightPack source again and figure out what he is calling "gamma".

Anyway... I look forward to tuning what looks best once I have mine installed (still waiting on that 128 strand from china). Then I will do a proper v1.0 release with the new UI I am working on and a video of mine working.

rpmccormick wrote:I will probably add support for multi-monitors and maybe skipping the middle bottom 1 or 2 pixels (or just being able to turn off any pixels you want... wasteful yes, but ensures a properly spaced grid without the user needing to custom set-up each bulb).

Nothing wasted here..just customized for the use with my desk monitor.

I wasn't saying you were wasteful, I was saying that if I made it just disable the bottom-middle LEDs that would be wasteful. Actually, if you want to skip the bottom 2, you could just set my app for 52 leds and move the shift the first pixel over one... then it would be sending data as if the last 2 leds in the chain were there, even though they are not.

Here is my first one... I'm in the process of making 10 of them right now. No showing cords... just a black plastic frame, with led's glued in to it, and a tiny lighter-sized box in the bottom-middle with a miniUSB and a 5V power input. Double stick tape on the back of the plastic frame, so it is ready to stick on, plug in, and enjoy. Any one here interested?

It should work for 46"- 70" TV as-is (it is just slightly bigger then perfect on my 52" with a wide boarder). I can do custom ones too... bigger requires more bulbs (or maybe just skipping some in the bottom middle), smaller I'll cut a few bulbs off. It updates at 30FPS with nearly 0-lag at 1920x1080 on my old AMDx2 2.8GHz using about 11% cpu... and that is with Aero enabled in Win7.