Better understanding of what's in an FSEQ

[nmiller0113]

I was speaking with David this evening over email regarding ZCPP as it is a very interesting subject to me and I'm trying to understand how it all works down to the FSEQ level.  In my basic understanding I *thought* that an FSEQ file only contained a block of absolute channels.  As such, I assumed that all my FSEQ's would just work regardless of the protocol in use to communicate and stream this channel data to a controller.  I've also brought this up to Dan in the FPP forums as he's talked about adding it to FPP possibly, and in that case xLights would *not* be the player.  David mentioned to me I'd need to rebuild all my FSEQ's if I switched to ZCPP, so I'm trying to understand why since it is just a mapping of channels from the player to the controller...at least as far as I understood it from Keith's video.  My point being, I'm obviously missing something around what is in an FSEQ...since if it was just a block of absolute channel data and the player and controller, in my case the FPP and F16v3, could read that block, then why the need to rebuild the FSEQ's?  So...that leads to my real question...is there any place where I can read more about what *all* is inside an FSEQ and what is the structure?  I think a lot of us could benefit from this information.  Thank you!

[dkulp]

This is not a fseq issue, it's a zcpp issue and I'm trying to get Dave and Keith to fix it.

With zcpp, xLights will ONLY allocate channels for the stuff physically connected to the F16.   If you only have 100 pixels total connected to port 1, then xLights allocates 300 channels and that's all thats in the fseq.   If you then connect 100 pixels to port 2, xLights then allocates another 300 channels and you have to rebuild everything.  There is currently no way with zcpp to say "this F16 will require 16K channels sent to it, reserve that".  Also it's very specific in that it chains from one model to another across the entire controller leaving no channels "free".   You cannot say "I'm not using port 2 right now, leave 300 channels there just in case".    All the used channels are compressed down.  If you then decide to use port 2 for something, you configure it in xLights and zcpp allocates new channels and you have to rebuild everything.    Basically, you WILL need to learn how to use batch render a LOT right now.

By the time this gets released, I hope to have some of it fixed.   With the FPP 2.0 release, I haven't had much time to dig into the zcpp stuff.   However, before it is implemented in FPP, it's going to have to have several changes.   The configuration part is way to restrictive of a protocol for any real world use.   Thus, there HAS to be a way to bypass that part of the protocol and use real configurations.   

[Gilrock]

I really don't see the big deal.  Who cares if a controller doesn't reserve extra space.  If you add channels in xLights you gotta render everything to pick up the new models and effects no matter what.  The way its always been.  So it would just reconfigure all the controllers.  I personally just configure everything manually so I don't need any of this but there sure is a lot of public whining going on about the ZCPP protocol when Keith gave Dan an opportunity to collaborate privately.

[dkulp]

I really don't see the big deal.  Who cares if a controller doesn't reserve extra space.  If you add channels in xLights you gotta render everything to pick up the new models and effects no matter what.  The way its always been.  So it would just reconfigure all the controllers.  I personally just configure everything manually so I don't need any of this but there sure is a lot of public whining going on about the ZCPP protocol when Keith gave Dan an opportunity to collaborate privately.

Gil, it's not just re-render everything. If you have a "mixed" environment of some zcpp and some not, you may need to go reconfigure everything on all the other controllers.   If it starts changing channel numbers on matrices or similar, you may need to go to every non-zcpp controller and reconfigure a bunch of things.   That's part of the issue.

Even if you configure everything manually, the extra protocol efficiency of the "DDP like" parts of zcpp can be a help.   It's easily 15-20% less data being transferred on the networks.   (higher percent if you use universes < 512). 

Anyway, as you stated, much of this is for Dave, Keith, and I to work out prior to making it all publicly available.   It's somewhat a shame that he made the video prior to dealing with some of this, but it is what it is.   

[Gilrock]

Well I'll let you guys sort it out.  I just get frustrated because I need you guys to help me finish 3D so stop wasting time on that ZCPP stuff....lol.

[nmiller0113]

This is not a fseq issue, it's a zcpp issue and I'm trying to get Dave and Keith to fix it.

With zcpp, xLights will ONLY allocate channels for the stuff physically connected to the F16.   If you only have 100 pixels total connected to port 1, then xLights allocates 300 channels and that's all thats in the fseq.   If you then connect 100 pixels to port 2, xLights then allocates another 300 channels and you have to rebuild everything.  There is currently no way with zcpp to say "this F16 will require 16K channels sent to it, reserve that".  Also it's very specific in that it chains from one model to another across the entire controller leaving no channels "free".   You cannot say "I'm not using port 2 right now, leave 300 channels there just in case".    All the used channels are compressed down.  If you then decide to use port 2 for something, you configure it in xLights and zcpp allocates new channels and you have to rebuild everything.    Basically, you WILL need to learn how to use batch render a LOT right now.

By the time this gets released, I hope to have some of it fixed.   With the FPP 2.0 release, I haven't had much time to dig into the zcpp stuff.   However, before it is implemented in FPP, it's going to have to have several changes.   The configuration part is way to restrictive of a protocol for any real world use.   Thus, there HAS to be a way to bypass that part of the protocol and use real configurations.

Thanks Dan, that makes perfect sense.

Leaving xLights completely out of this, maybe that will make my questions clearer, I'm trying to understand this from the perspective that *if* FPP ever supports even just the streaming portion of the ZCPP package...I'll call it package since it seems be made up of 3 parts, discover, configuration and data stream...excuse me if I'm completely off in that explanation If FPP ever did support just the stream portion for sending the pixel data from the FPP to an F16v3, as an example, I was trying to understand why my FSEQ's would need to change at all if none of my channel mappings changed...and not asking this because I don't want to take the time to recreate the FSEQ's, I'm asking because I'm trying to make sense of it.  My assumption is being based off the FPP reading the absolute channels in the FSEQ and sending that data to the appropriate controller via ZCPP based on the theoretical ZCPP configuration in FPP mapping of x channel range to xxx.xxx.xxx.xxx IP...I'm assuming that's how the configuration would work in FPP based off of Keith's video on ZCPP in xLights.  Then the F16v3 would receive the ZCPP data stream and, in theory, know that absolute channel x maps to string port x, obviously manually configured in the controller because we're only using the ZCPP data stream in this example.

This example is purely based on my assumption and ignorance of how the ZCPP data stream works and how it is received by the controller and then interpreted, but in its simplest form I'm trying to understand that if ZCPP is purely operating as a replacement for E1.31, for the data stream portion, everything else could theoretically operate the same in the way we map the absolute channels to ports...and thus...no need for a change to the FSEQ.  Sorry if I've dug too deep, too soon

[nmiller0113]

I really don't see the big deal.  Who cares if a controller doesn't reserve extra space.  If you add channels in xLights you gotta render everything to pick up the new models and effects no matter what.  The way its always been.  So it would just reconfigure all the controllers.  I personally just configure everything manually so I don't need any of this but there sure is a lot of public whining going on about the ZCPP protocol when Keith gave Dan an opportunity to collaborate privately.

Gil, it's not just re-render everything. If you have a "mixed" environment of some zcpp and some not, you may need to go reconfigure everything on all the other controllers.   If it starts changing channel numbers on matrices or similar, you may need to go to every non-zcpp controller and reconfigure a bunch of things.   That's part of the issue.

Even if you configure everything manually, the extra protocol efficiency of the "DDP like" parts of zcpp can be a help.   It's easily 15-20% less data being transferred on the networks.   (higher percent if you use universes < 512). 

Anyway, as you stated, much of this is for Dave, Keith, and I to work out prior to making it all publicly available.   It's somewhat a shame that he made the video prior to dealing with some of this, but it is what it is.

Gil, I'm definitely not whining about this at all...in fact I'm excited about this...I too configure everything manually and planned to continue that...I *only* want to take advantage of the data streaming efficiency.  So I'm trying to get ahead of the curve and really understand how it works.  Sorry if I came across as whining Oh and sorry to steal valuable developer cycles from your awesome 3D layout updates!

Dan, sorry for the peppering of questions I started since watching Keith's video and hearing about similarities to DDP.  I also had another post regarding DDP support on the F16v3 controller http://falconchristmas.com/forum/index.php/topic,9317.msg86456.html#msg86456 well before Keith's video came out, that went unanswered.  So when I heard about it being similar in efficiency to DDP and would be supported on the F16v3, I got excited...maybe too exited I'll stop bothering with any further questions until you Dave and Keith work it out further...just know I'd be happy to beta test for you all as I'm excited about this...which you already know