Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sync multiple instances with realtime sync or DMX #119

Closed
omski opened this issue Sep 14, 2021 · 3 comments
Closed

sync multiple instances with realtime sync or DMX #119

omski opened this issue Sep 14, 2021 · 3 comments
Labels
enhancement New feature or request

Comments

@omski
Copy link

omski commented Sep 14, 2021

Is your feature request related to a problem? Please describe.
Sync multiple instances as 1:1 copies of the master instance is currently only possible though audio sync which has some limitations.
WLED SR has the audio sync feature but the receiving instances must be WLED SR instances and there is a feature gap between ESP8266 and ESP32 devices.
Currently WLED and WLED SR is not able to sync multiple instances via realtime UDP or DMX.

Describe the solution you'd like
The master instance should create realtime UDP or DMX data and send it to every slave instance. This way you can use 'plain' WLED slave instances to receive effects created by WLED SR.
Sync via sending audio to any slave is fine for creating different effects on the same audio data but this is not needed if someone just wants to copy the effect of an instance to another instance.

Context
This request mimics the ideas from https://kno.wled.ge/interfaces/udp-realtime/ and https://github.com/scottlawsonbc/audio-reactive-led-strip

@omski omski added the enhancement New feature or request label Sep 14, 2021
@atuline
Copy link
Owner

atuline commented Sep 15, 2021

I believe that in order to do this, we would need to control the slave devices much like LedFX controls remote devices and that is to send all of the LED information to the remote device. That's not currently on our roadmap, however we'd be open to a comprehensively tested PR that provided this functionality along with the GUI selectability.

@atuline atuline closed this as completed Sep 15, 2021
@netmindz
Copy link

In effect you mean the option to send e1.31 or one of the other "raw" LED value sync options.

While that's not SR specific, I think you would find hard to get accepted upstream.

For the SR branch the usecase will be restricted to cases where all your devices have the same LED count as using the normal pattern sync + audio data is more flexible than your proposal.

Depending on your physical setup, simply connecting multiple strips to the same controller might be more appropriate, using max485 if you have longer cable lengths

@omski
Copy link
Author

omski commented Sep 18, 2021

It is SR specific as makes only sense with WLED SR because you need audio data to render the effects. WLED has only synthetic effects which are easy to reproduce on different instances with just sending some params. With WLED SR you are furthermore limited due to version compatibility issue in regards to the firmware and the chip used.

My physical setup does not allow for wired connections because the receiving targets are moving. They will be battery driven. For now the limitation of having identical setups is not a problem for me.
But I would propose to split of segments of the master device to several slaves like WLED does this with sync groups.

I might be helpful to imaginate a master instance wich is directly connected to a music source through a line in signal and several moving slave device which are not able to source the audio signal themselves and are space restricted, so an ESP32 chip would be hard to cram into. This is the reason I have to use ESP8266 WROOM 2U as they are have very small dimensions. The master device must not have any LED directly connected at all! It has only matching segment settings for all the slave devices it should drive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants