Hi Velcrome, I did think about plugins for it, but had a load of things all to do concurrently last month, so never did!
https://github.com/scanlime/fadecandy this has also been released which is another project based on the OCto library, it uses less leds per output but gives better color and fades, I havent tried it much yet. I've been trying to get it to compile on my rPi to no avail, 1 Pi could control multiple teenys so could work out cheaper than lots of ethernet ports, I did try a bit of udp into teensy, but the buffers get overloaded, I think the udp library is a little iffy from what I could google (arduino's)
I'll check out your plugins though, cool stuff :D

http://www.flickr.com/search/?q=paradox%20fellfoot

heres some pictures of my LED's at a tiny festival my friend runs...
Hung off nails *blush* it is no budget ;)

hi catweasel,

the home of pancosmic pyromanticism? haha, that sounds fun.
our work was shown at gamescom in cologne as part of the xbox presence. it totalled about 5k of leds and 8 teensies.

on a side note:
anyone attempting a project like that, make sure you are aware of the electrical demands of an installation like that. if your wires are too flimsy for the massive currents that can build up, you loose too much voltage to maintain stable pwm.
ground ripple proved to be a problem too till we rewired almost everything.

the teensy part is quite straight forward, though, thanks to the incredible work of Paul Stoffregen

you can pipet colors and cons them as much as you want, as long as you make sure you fill each individual teensy board to a color slice count of 1024.

if you channel the filled color spread into my module, the precalced data will come out of it spreaded. use that as input of the RS232 and spread the COM-Port input as well.

if a teensy operates on slave mode, it needs a connected master teensy on pin 12. only then it will push the pwm data, otherwise it will keep the last frame. this is to ensure framesync if you use multiple teensy in one big matrix.

as for the strip length: try it, i dont know if it works. probably not. i always filled it up, just to be sure.

i added a new version. please download and test and let us know if it works.

Did you change the LED count in the firmware too?

TeensyCount is not needed anymore because it is implied in the color slicecount. But you have to make sure LedCount per pin in the patch and the firmware match.

hey friends, hey @Alec

I finally found the time to fix the issues that were related to strip lengths other than 128. As a side product, it is all a single plugin now with a noticable performance gain.

Please note, that I still don't see a need to follow Paul Stoffregens example to split strips into substrips that somehow have to follow an arbitrary interleaving system. Instead, just freely patch the spread of Pipet coordinates according to your physical layout.

This allows for arbitrary coordinate based color picking from a EX9 or DX11 renderer.
In my experience the Sync at pin12 ("SlaveMode") is not needed as long as your framerate is high enough.

Set the Strip Length both in the VideoDisplay.ino file and the patch to the maximum physical strip length (if you have some 56er, some 108 and a single 128 -> pick 128) and the rows to 8 (always). This might sound wasteful, but at least it is safe, because any superfluous data through the teensy will be ignored by the strips themselves.
Make sure to fill up sufficient color slices in the input spread.

Pro Tip: You can use the accompanied Splitter (Raw) to package smartly for other protocols (like artnet's 510byte), or even cut out parts that you are sure you don't want to send (this and a + (Raw Advanced) would be a performant way to handle custom situations similar to the one from @alec).

Hey Velcrome, hey Catweasel.
There was a further development of FastLED library and now it can be used in conjunction with Octows2811 for apparently faster communication:https://github.com/FastLED/FastLED/wiki/Parallel-Output#making-octows2811-faster-with-fastled
The library includes an example code that makes use of it.
Apart from it I also found another arduino sketch that is used to communicate with TouchDesigner.
Unfortunately I could not figure out what is needed to be changed in your plugin/patch in order to make it work.
Maybe you can have a quick look into it?
I am not sure if this is worthwhile but any performance gain is a good thing.
This is the link to the sketch I found. https://www.dropbox.com/s/badm3dl4hg2ethn/ledPixelController_400.ino?dl=0
Thanks for the help!

Hey Catweasel how many leds could you drive via art-net? Do you use more than one universe? If so what node do you use? Could you elaborate your setup please?

I decided against Artnet and made my own UPD based packet system. Each packet prepends a byte indicating the position of the "stripes' chunk" and a flag, if it should refresh all LED or not. The chunk design is prepared in a way, so OctoWS2811 can use a single fast memcopy, instead of going through SetRGB for each led (much more like catweasels first contrib on this page).

Each chunk describes 8 stripes by 32 LED, and we commonly use 8 chunks for a total of 2048 LED per teensy. Eight teensies can be driven at 60Hz now.

Oh, the things we do for Fusion...

Hello friends!
I would like to manage 7,200 diodes.
For this I need 8 teenagers and OctoWS?
Will the computer and vvvv cope with this?

Thnak you velcrome
I think 25fps is not bad for simple task?

I've found that by using a shared texture and then pipeting that in a 2nd instance of vvvv, you get much better performance, I use the dx11 one of course :)
While we are show and telling, http://www.colour-burst.com/2015/11/frequency-response-1/ this was 20 universe with 4 teensy, I've now started using a version of the BlackLED https://github.com/vertigo-dk/BlackLED but using FastLED instead of octows, and I can get 8 universes from one board. Not as many as the vertigo-dk guys :(

Also wondering about APA102 LEDS.