Hitting bottleneck controlling close to 4,000 LEDs!

[lucasm]

Hey Rob,

That makes sense, I added a limit and set quantitize steps to 1 however it doesn’t seem to to changing the data type? (I had this as last CHOP in the chain so it was sampling directly from it.)

Also, I’ve had that issue before with other node types where I try to reference a channel or something and it gives me the <class variableType … thing. Is there a different way to reference touch arrays to avoid that?

Snaut,

That’s a pretty awesome trick, would you mind explaining a bit more about why that works?
It brought frame time down to mostly under 10 ms ! well within the 60 fps range.

[michelchrome]

Thanks Lucas for your example, definitely, using one shuffle CHOP (sequence all channels) upstream instead of the reorder CHOP before each output was the best idea.
But look a this .toe, it’s even more quick, I reuse your first ideas to trim the channels and split it up inside of each dmx_outputs COMP

@Snaut, thanks for the tips but i didn’t get better performance with it, the replace CHOP cooking time was around 0,15ms …
LEDmapper_v2.16.toe (8.99 KB)

[lucasm]

Nice! You got that frame time WAY down.
Your file is registering 2-5 MS per frame on my end. Glad that’s working out, good to know an artnet workflow could push the same if not better in terms of speed.

In the spirit of optimization I setup some nodes in my setup that captured the time in milliseconds just before serial data was sent to the arduino and just after the arduino finished it’s draw loop (it sends back a single byte to touch signifying it finished a frame update)

Anyways, I’m sitting nicely just at .017 MS between the before and after. That’s pretty much at 60 FPS.

I think the ws2811 leds flicker a little when updating that many led’s with a fast moving pattern so it has an ever so slight jumpy look but I can only see it with a really narrow ramp animating really quickly across the panel.

[snaut]

The replace is fairly simple operation compared to the select as it literally just has to look if the channel is in the second input and replace the first inputs channel value. The select has to do a bit more work and watch for more changes in its input.

Compared to the trim, the replace is still slow but it was about only 1/3 of the cooktime required by the select CHOP.

cheers
Markus

[rob]

I’ve also just changed the .sendBytes methods to allow passing in an array of floats, so no conversion to ints necessary.
ie: n.sendBytes( *channel.vals ) will work now.

(build 25680+)

Cheers

[lucasm]

Thanks Rob! I’m going to snag that update soon then

Lucas

[ben]

25880 is posted now if you wanted to try this out.

[lucasm]

Hey everyone, been a few months, I just wanted to update this thread again with the final results of all the tinkering and learning

The system totals out to 5,280 led’s, portable, modular, and pixel mapped. I’ve VJ’ed with it a few times, and it works pretty well! Still working on setting up / breaking down quickly but that’s a different subject entirely.

compilation:
[url]16 panel compilation - YouTube

[K5Doom]

This is awesome!

So what hardware would you suggest?

Teensy, Arduino, Pixel Pusher or FadeCandy?
Also, what panels are you using?

Thanks for the contribution!!

[lucasm]

I did Touch Designer → Serial Out → Teensy 3.1 → Octows2811 adapter board → Leds

For the led’s, there’s a lot of routes you can go, I built my own custom panels out of led strips and a custom pcb I made that just made soldering everything really fast:

I 3d printed the diffusers and frames/brackets and other unique pieces and used some fiberboard from home depot.

These guys make some rigid large led pcb’s that look pretty nice if you want something ready to go.
[url]http://rgb-123.com/shop/[/url]

For microcontroller, you could use a lot of different things, I liked the teensy 3.1 and octows2811 adapter board. Really solid performance from that at an excellent price point.

Obviously running serial long lengths is not as ideal as ethernet, but if you go this route, this is a really solid active usb extender cable:
[url]http://www.amazon.com/Monoprice-Female-Extension-Repeater-Compatible/dp/B004PLLA9U/ref=sr_1_10?ie=UTF8&qid=1423812738&sr=8-10&keywords=usb+extension+active+monoprice[/url]

Vj’ed with it a few times and it carries the data reliably and has no problems detecting on the pc side.

The part that I think is most limiting for some is mapping the leds, visually. Especially when you have a custom setup, or custom arrangement.

I uploaded a barebones examples TOE further back in this thread that shows how I do it from A-Z (thanks to everyone here for helping work out the kinks on that!)

Hope that helps!
Lucas

[K5Doom]

Thanks! I have no problem going DIY as I have an engineering background

I’ll probably build something similar in the near future, thank for the info it really helps! I’ll post updates when I have something to show!

[lucasm]

Update time!

I wanted to drop back in here and put out some updated info on driving led’s with TD, over serial to teensy. I had a few pieces of mis information from before and there’s been a few updates on fastLED octows2811 librarys over the months that make things faster!

Current figures:

• TD 60 fps
• Serial over usb (for multiple teensys use a multi-tt hub)
• Teensy 3.1 running a fastLED/OCTOws2811 mixture (more on this below if you’re curious)
• 3,680 ws28xx leds per teensy 3.1 (460 per pin) also @ 60 fps

Dependancies: (also attached for conveniance)
Arduino Libraries:
[url]https://github.com/FastLED/FastLED/tree/FastLED3.1[/url] -attached-
[url]https://github.com/PaulStoffregen/OctoWS2811[/url] -attached-
[url]https://www.pjrc.com/teensy/teensyduino.html[/url] (addon for arduino IDE)

Arduino sketch:
-attached-

Touch Designer Barebones example
-attached-

Notes:

You can scale this solution by adding more teensys running the same code to the mix. I have not reached an upper limit but haven’t tested it too much yet, but I imagine at least 3 or 4 teensy’s total could be done with out dipping below 60 fps, perhaps more.

Eventually the USB host card will reach it’s max, and / or TD will choke on sending that much data out via serial, but i’ve found that with the modifications the dev’s helped put forward in this thread you will probably hit a hardware wall before a software wall !

For those integrating this into already complex / heavy networks, it may be wise to offload the communication part to another touch designer process and use a sharedMem chop or spout in/out to offload that work and keep speeds up!

A little info on why / how the led counts have increased with this solution:

The reason the octows2811 library works so damn fast is due to the r/g/b data being formatted in a special way that the teensy’s DMA engine can push out natively, so no bit banging, which means hardware can do it’s thing on 8 strips in parallel. However! The .setPixel() command used previously has been somewhat slow, so Daniel Garcia at fastLED has written some backend code that does that translation much faster using some of fastLED’s code.

more info:
[url]https://plus.google.com/communities/109127054924227823508/s/octows2811Demo[/url]
[url]https://github.com/FastLED/FastLED/wiki/Parallel-Output[/url]

I’ve been researching pixel controllers and various software / hardware configurations, and have not found anything like this before. Paul, Daniel, and everyone at Derivative have made this a painless and extremely elegant (and cost effective!) way of building / controlling custom led art, displays etc.

Thank you for that Hope this helps some of you looking for a solution and missing bits and pieces of how to make it all work.

Lucas
OctoWS2811.zip (171 KB)
FastLED3_1.zip (250 KB)
ledPixelController_460.zip (832 Bytes)
ws2811-12-12b_DrivingSolution_BareBones.1.toe (5.74 KB)

[lucasm]

@SCare

that issue was a thing of the past, check out the latest TD file I attached, working example should have everything you need to get going.

[mpinner]

@lucasm
thanks for providing the detailed example and recount of your experience.

im currently evaluating teensy serial vs beagle opc and mostly trying to get the fastest framerate possible with 1000s of leds.

is there a reason you used fastled instead of paul’s octows2811 library directly?

[lucasm]

Let us know what you find out!

Yeah the devs on fast led wrote some code that allows fast led to prep the drawing buffer of the octows library faster than the built in .setpixel() command can. Which effectively merges the best part of both libraries.

I elaborated a bit on my update a couple posts back on this page.

[mabrodeur]

Hi!

Thanks lucasm for this nice solution.
On my side I can’t send the data by serial. Do you know how I could convert your code to work over udp?

Thanks a lot

[lucasm]

create a udp Out node, and an execute DAT (if you want to execute every frame), and in the execute dat you’ll need to get the contents of a chop channel and assign it to a python list.

Then to send that byte array/list through the UDP out node you’d need something like this (replacing the psuedo names with your UDP node name, and python list respectively.)

name_of_Python_Byte_Array = name_of_chop[channel_indicie].vals
op(“UDP_out_node_name”).sendBytes(*name_Of_Python_Byte_Array)

NOTE: the " * " sign is neccesary, it’s called the splat operator I believe, it basically takes a list and breaks it’s contents down into separate arguments which is what .sendBytes likes (correct me if I have this wrong!)

[jasonhaggerty]

Bit of a late comer to this awesome post, but I just wanted to say thank you!

[guggmann]

hey, first of all thanks for the great stuff!
i’m quite new to td and i’m using a macbook pro… and somehow this patch doesn’t work there.
i think the serial is sending some strange things. On a windows machine everything works just fine.
Does anybody know if there is any difference in the serial output?

[rob]

We’ve just made a fix to the MAC serial library which was cutting off messages longer than 1K in length.
Look for it in builds 2018.22930 and later.
Cheers