Because googlecode is being a [REDACTED] and not allowing us to check in tonight,

Because googlecode is being a [REDACTED] and not allowing us to check in tonight, i’m going to instead regale you with a tale of two libraries.

With FastSPI_LED, if you wanted to set all of your leds to blue (a simple task, no?) your code would look like the following (and eat up 13.5kb in your program flash):

#include <FastSPI_LED.h>

#define NUM_LEDS 300

struct CRGB { unsigned char b; unsigned char r; unsigned char g; };

CRGB *leds;
void setup() {
FastSPI_LED.setLeds(NUM_LEDS);
FastSPI_LED.setChipset(CFastSPI_LED::SPI_TM1809);
FastSPI_LED.setPin(4);
FastSPI_LED.init();
FastSPI_LED.start();

leds = (struct CRGB*)FastSPI_LED.getRGBData();
}

void loop() {
for(int i = 0; i < NUM_LEDS; i++) {
leds[i].r = 0;
leds[i].g = 0;
leds[i].b = 128;
}

FastSPI_LED.show();
}

Had to define your own rgb structure, had to do a bunch of manual setup, you couldn’t have more than one controller, it compiled in the code for every other controller under the sun (which was bad, and will only get worse, I have at least 4 new controllers on my list at home), If your strip color order was changed you’d have to manually tweak the order of RGB in your structure. A good thing you could only have one strip, you don’t have to worry about multiple rgb orderings!

Now? Here’s the same code with FastSPI_LED2, Release Candidate 1:

#include <FastSPI_LED2.h>

#define NUM_LEDS 300

CRGB leds[NUM_LEDS];

void setup() {
FastSPI_LED2.addLeds<TM1809, 4, BRG>(leds, NUM_LEDS);
}

void loop() {
FastSPI_LED.showColor(CRGB::Blue);
}

Much simpler initialization, no inclusion of code you aren’t going to use, convenience functions for setting all the leds, color definitions, utility functions for a variety of basic color effects, you could have multiple controllers, easily, etc… etc… etc…

Barring google code falling off the face of the earth, @Mark_Kriegsman and I will be putting up RC1 tomorrow night. RC1 should be mostly final, with the remaining pieces to be fixing any last minute bugs that come up and writing documentation and example code.

This is going to be a large update - FastSPI_LED, with all its limitations was a mere 928 lines of code. FastSPI_LED2, at the moment, is clocking in at over 5000. There’s a lot to document and show off how to use, and I can’t wait to see what people start doing with it!

See also - Vine

You are aware that they are doing away with downloads, yes? It was just disabled …

http://code.google.com/p/support/wiki/DownloadsFAQ

For you guys, I believe you have a reprieve till January 15th, 2014, but after that, no more.

Yeah, @Mark_Kriegsman and I are already talking about where to move to. It’ll likely happen when the final release goes up. I’ve been unhappy with google code for a while now, not being able to access my repository is only the latest bs.

Yeah, github is one option, most likely one at the moment.

Daniel, were you able to fix the paused clock (millis) issue on your side?

Yes - the library will attempt to adjust the clock timings appropriately. It won’t be exact enough that you can run a clock against it, but it’s close enough to, say, stay in sync with a given BPM.

I have discovered that arduinos have terrible clock drift on their own - so if you’re doing anything where the passage of time is sensitive, i’d recommend getting an external clock (e.g. a chrono dot, or the teensy 3 with its option for an RTC crystal)

Github might be an idea if you don’t care for something more than just basic statistics for your project.

What kind of hose (source?) were you using in the example?

Just something along these lines - http://anyvite.com/events/home/sh9pe2qgep

Dan, the link was to some kind of event site, to which one needs to log in. Was that a real response to my question about the type of hose in which you were enclosing lights?

Gah - stupid multi-clipboard - http://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Daps&field-keywords=white+flexible+split+conduit&rh=i%3Aaps%2Ck%3Awhite+flexible+split+conduit - it’s just white flexible split conduit.

Could you say more, like what size of tubing and what kind of pixels you are using (eg: 12 mm tubular pixels in 3/4" ID white tubing, or the square housing pixels in 1" ID tubing etc). The comments on Amazon indicate that some brands are opaque white and some are translucent. Apparently the translucent allows wire color to show through. I’m assuming that you are using a translucent white, but it’s possible that you found that “opaque” is a better diffuser and lets enough light through. Thanks

Actually check with Mark - he’s using it with his lights at home - I just know the basic idea behind it (I’m currently using different materials with my own projects) - I believe they’re tm1809 strips at 30 leds/meter with the waterproof tubing on them. I don’t know whether he went with translucent or opaque.

@Mark_Kriegsman pinging mark so he can give you the exact specs (though I suspect it’s the local hardware store special)

I’ll get the specs as best I can in the morning, but generally: “opaque” white tubing (which is actually translucent) is what I’ve had good success with so far. I’ll post pics tomorrow if I can.

@Mark_Kriegsman Do you remember what diameter tubing you used? I know how wide the strips are but different diffusers need different amounts of distance to the strip.

im using the old library for 6803, but at the same time the new color functions .
everything works fine, but I have to change the LED color order , and the old definition :
struct CRGB { unsigned char b; unsigned char r; unsigned char g; } shows and error as CRGB has already been defined on other library . Then my question , where should I change the code in order to make it work as BRG , and modifying as less as possible?, thankyou