Signed-off-by: jhinklejr <joe@joehinkle.com> #1441
Conversation
|
There is definitely a lot of potential overlap here with stuff that would be "nice to do" with FPP as well. I think I need to think more about how to abstract some of that out so it's more usable for both. For example, your concept of "attached" controllers would be nice to have for FPP. Right now, if you select to upload the UDP outputs to an FPP instance, it gets ALL of them. There isn't a way to only upload the UDP outputs for a specific subset. I really think some of the "controller type" selection and some of that really should go up a level and be part of the Setup tab. The entries on the setup tab should be able to have a controller type (and additional metadata related to that) which could then drive some of this. I definitely need to think more on that. For the most part, I like most of the stuff here. The concerns I have are more around #3 and #4 in your list. #3 somewhat makes sense. When uploading stuff, it's nice to setup a playlist entry that makes sure the audio and fseq files are properly matched. This has always been an issue with FPP which is why the FPP connect stuff allows appending entries to playlists. I don't really intend for full "playlist management" capabilities for FPP to live in xLights, just the ability to add what is being uploaded to a playlist to make managing it from the FPP UI easier. My bigger concern is with #4. xLights really shouldn't be about setting up schedules and such. That's likely something the UI on the controller itself (or customers website) should better handle. For the most part, xLights should be mostly about generating the content and configuration that is needed, but scheduling that content has, for the most part, been completely outside the scope. The generated PCM/WAV/FSEQ files should also be considered temporary files (use the xFileName::CreateTempFileName) and removed after upload. That said, until you get the upload working, I understand why they are kept around. :) Definitely do NOT store them under the Show folder anywhere. Anyway, that mostly my initial thoughts mostly from watching the video. Haven't really dug through the code much yet. |
|
I have not taken a look yet ... and wont get a chance until this evening ... but in general I agree with Dan's comments about abstraction. I am really not keen to have UIs proliferate for controllers. We should have one UI for the concept and then possibly multiple behind the scenes controller specific implementations of the concepts. |
|
The UI is really inconsistent with the rest of xLights. If we want to represent the controller topology I think it needs to be some sort of canvas drawing type approach ... lists and modes and roles etc etc gets really confusing very quickly. A diagram would be a much much simpler way to represent all of this. Specify on your callouts above. #1 ... I dont understand why i need to identify your controllers. Surely xLights can work that out (if they are online). If it has to be manually entered it would be a property of a controller on the canvas #2 ... the canvas makes this easier to use #3 ... this is not xLights concern. #4 ... this is not xLights concern #5 ... this sounds very similar to what Dan has done for FPP ... and should be done on upload #6 ... This should be in the upload code to the controller. A dynamic reformat for upload using proper temp files as Dan says. #7 ... Whatever we do here has to be standard across all controller types. My gut preference would be to store it in the networks file ... but in a controller independent format. #8 ... There should be one Easylights file ... like there are for all other controllers. Any UI should be generic across any player type device. #9 ... and once done they should be deleted so they dont clutter up folders. |
I am submitting this pull, not as a commit or merge, but as a request
for review.
I would like to extend xlighs capabilities to users of my EasyLights
controllers and the proposed changes here submitted for your review
performs most of the UI to accomplish that.
EasyLights controllers can synchronize with each other and play audio
and lighting channel data from SD cards. In addition, depending on the
channel requirements of non-EasyLights controllers that acquire their
data via E131, they can become part of the EasyLights StandAlone group by
attaching them self to an EasyLights controller who will send them their
required E131 data.
The changes to xlights accomplishes the following:
Identify which of the E131 or DDP controllers are actually EasyLights
controllers and select which model they are so their capability can be
established.
Identify any non-EasyLights controllers that are to be attached
and verify that channel demands allow attachment.
Enable the user to compose Play Lists. (my format is different
than what xlights currently uses).
Enable the user to compose a schedule for each day of the week by
identifying which Play Lists are to be used and the times/loops performed.
Extract from the "xlights main" fseq, the channels required for
each EasyLights controller and any attached controller and build unique
fseq files for each.
Extract the PCM data from the audio file used in the xlights fseq files and
generate a "wav" file.
All EasyLights data is contained in a folder under the "Show" folder.
All EasyLights cpp/h files are contained in a folder under "controllers"
Once the user has generated his required fseq and wav files,
(this code is not implemented yet) - wired or wireless UDP communication
will transfer the required fseq and wav files to the appropriate
EasyLights controller.
10: Please excuse my coding style, I will update it to the current style xlights is working to.
I have included a short video that shows the proposed changes in action.
It can only be reached by using the link below.
https://youtu.be/7d5ok4WoK3s
Please provide any comments of the proposed changes stated above.
Thank you in advance for your consideration.
Joe Hinkle