General discussion of development

[not-matt]

Please leave any thoughts or comments on the movement of the program here.

[not-matt]

Oh that should be fine, give it a shot and let me know what happens!

On Sat, Jun 23, 2018, 11:34 blassbasti notifications@github.com wrote:

yeah true if you have strips with a different length it wouldn't work that way!

in my case i would address 6 strips with 72 pixels each, so it should work, shouldn't it? I really appreciate your eager working on this project!!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/not-matt/Systematic-LEDs/issues/3#issuecomment-399663649, or mute the thread https://github.com/notifications/unsubscribe-auth/Ae5azCJ5GFKMn413HpAs0ExqtPyky0whks5t_hnGgaJpZM4SZ0Ls .

[Moonbase59]

Hey! I wonder if this project should be steered into a slightly different direction. Don’t understand me wrong, it’s absoluteley awesome (though I cant get it to work under Linux and have to use the previous adaption https://github.com/not-matt/audio-reactive-led-strip), but I have some ideas of my own and would like to share these and discuss:

1. I always like things to adhere to some standards, so my lights are either controlled via Home Automation (mostly MQTT, some ZigBee), or by the more professional DMX512 (mostly E1.31, in my case) protocol. Your software, briliant as it is, has some limitations (like 256 LEDs/strip on a microcontroller), and uses its own protocol.

2. I’d love to see the two parts (the great audio controller part vs. the LED strip controlling) to be more separated and, preferably, use a protocol like E1.31.

3. We already have great light controllers that can even do DMX (E1.31) and MQTT so I can use my strips for normal lighting using home automation and simply switch them over to a DMX-based show whenever needed. See https://github.com/forkineye/ESPixelStick for instance.

4. DMX solutions seem to lack a little on the "live audio control" side, so your audio controller would be a perfect fit if it could output E1.31, for example. It could then output to the pixelstick or any other DMX device, and you could concentrate on the real great part, i.e. the audio controller and effects stuff.

5. It would have to be determined if DMX over E1.31 is actually fast enough to do whatever you do today, regarding audio effects. I did some testing with QLC+ and xLights and I think it might be feasible.

6. Separating audio control, protocol, and output devices this way would make Systematic-LEDs even more versatile and also more easily allow for controlling more than one device.

7. And it would make all of our investments in LED strips and other lighting equipment much more awarding, since we could alternatively use the same devices for a) "normal" lighting (smart home), b) DMX-based shows, and c) the kind of audio-reactive party/club lighting you provide.

What does everybody think? (Well, you asked for it ;-))

[Moonbase59]

@blassbasti: I wouldn’t go for general multicasting, especially not within the home network. DMX using E1.31 can do that, and I’ve seen awful network congestion, even on special separate show networks, up to failure of multiple devices during a show.

The idea behind multicasting is great, but if you start having a few more devices you risk to seriously flood the network, which can lead to lost packets, devices not getting their data in time, or even sudden reboots of some devices that can’t handle the load. Too sad, really.

I even use unicast in show networks now.

[ahodges9]

My entire setup is E1.31 based (ESPixelStick to be precise) and your vison aligns closely with my goals. I use HomeAssistant to control the ESPixelSticks typically (Just recently got in my firmware changes into the official forkineye repro that adds much better MQTT support!) and want to extend upon that to have HomeAssistant to be able to talk to a dedicated RaspberryPi to enable network driven effects (i.e. synced non-reactive effects, more complex effects than ESP01 can handle, audio reactive effects, and video reactive effects).

As for E1.31 I have hard a PR (#18 E1.31 Support) active here for a while that adds E1.31 support and it works great from my testing (oddly better than pure UDP). E1.31 is 100% capable of support this as is basically just a few extra bytes of header info and a little more processing on the client side. It has a ton of benefits such as packet drop detection and cross device synchronization. The only issues I have found are with DMX512 specifically where the 512 channel limit means some of my strips span universes and thus require two packets giving it more overhead and higher risk of dropping a complete frame. Larger universe sizes is on my list of things to look into though.

As you have noticed, I have already started my own controller "LedFx" that moves towards headless controller ready to be driven by other homeautomation platforms. I just got initial REST and Websocket support that should be fairly easy to integrate with most applications. It is still missing a lot of these effects, but does have a few proof of concept audio reactive ones. If you have a large E1.31 network it would be great to get help testing performance. I only have 4 controllers spanning ~1500 channels which isn't much compared to others

[Mattallmighty]

Hey Team,

I have been trying to create scenes/preset at the moment. What I am thinking on is hat can press a keyboard shortcut or button highlight below.

What will happen is it will load the save file or scene/preset.

Also another option, is when you add the deice, you can say slave RGB making the transitions between lights seamless.

Im not a programmer, but learning. Keen to know your feedback?

[blassbasti]

@Moonbase59 well i use a seperate network just for the visualization. since i have only 7 (1 laptop, 6 ESPs) devices connected to it there shouldn't be any bandwidth issue i think!

[Yariv-h]

Would be possible to add support to WS2811 with the upcoming roadmap features?