audio-reactive-led-strip icon indicating copy to clipboard operation
audio-reactive-led-strip copied to clipboard

Discrepancy in ESP8266 FW and LED.py

Open otcbl1nk opened this issue 6 years ago • 3 comments

Looks like with the latest update LED.py is no longer sending valid data for the ESP8266. This is resulting in everything being pretty broken. Might want to update the ESP8266 files to account for your new changes (or switch LED.py back which is what I did to unblock)

otcbl1nk avatar Mar 02 '18 03:03 otcbl1nk

Sorry, branch muddle. I'll sort it.

On Mar 2, 2018 03:22, "otcbl1nk" [email protected] wrote:

Looks like with the latest update LED.py is no longer sending valid data for the ESP8266. This is resulting in everything being pretty broken. Might want to update the ESP8266 files to account for your new changes (or switch LED.py back which is what I did to unblock)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/not-matt/audio-reactive-led-strip/issues/4, or mute the thread https://github.com/notifications/unsubscribe-auth/Ae5azI_k83l9BrTT4zvVNxnySmzLzdPlks5taLrogaJpZM4SZWI5 .

not-matt avatar Mar 02 '18 03:03 not-matt

Awesome, keep up the good work.

Side Note: One thing I think you should be conscious about with the multi-device support is reducing the computation as much as possible. It currently looks like everything is essentially being processed independently. For running on a desktop this isn't an issue, but my plan is to run this on a RaspberryPi that acts as the coordinator broadcasting to ESP8266s. The RaspberryPi is already pretty close to being maxed out, so I would expect (have not tested) that using once as a controller for multiple strips wouldn't be feasible. Would be great to factor things out such the processing the audio and building visualization are separated as much as possible with most of the computation on the audio processing side. Thus, driving multiple LEDs doesn't require more and more computing power.

Thanks!

otcbl1nk avatar Mar 02 '18 03:03 otcbl1nk

Yes, I have considered multiprocessing this on a Pi, and will add that functionality in if I think it's required. I'm running this on my Windows PC but have a Pi I want to set up for this specially.

On Mar 2, 2018 03:35, "otcbl1nk" [email protected] wrote:

Awesome, keep up the good work.

Side Note: One thing I think you should be conscious about with the multi-device support is reducing the computation as much as possible. It currently looks like everything is essentially being processed independently. For running on a desktop this isn't an issue, but my plan is to run this on a RaspberryPi that acts as the coordinator broadcasting to ESP8266s. The RaspberryPi is already pretty close to being maxed out, so I would expect (have not tested) that using once as a controller for multiple strips wouldn't be feasible. Would be great to factor things out such the processing the audio and building visualization are separated as much as possible with most of the computation on the audio processing side. Thus, driving multiple LEDs doesn't require more and more computing power.

Thanks!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/not-matt/audio-reactive-led-strip/issues/4#issuecomment-369810290, or mute the thread https://github.com/notifications/unsubscribe-auth/Ae5azN7xD7oXR9CzsQKGbkGoNH-Lncf-ks5taL3_gaJpZM4SZWI5 .

not-matt avatar Mar 02 '18 03:03 not-matt