SUP Import difference vs Data Layer

[nmiller0113]

This is for Gil and Dan as I believe they have spent majority of the time creating this feature.  I want to first state that I know it's not an exact 1 to 1 match between an original SUP and the Import Effects version of the SUP.  I know this was a best effort to match.  With that being said I'm curious if my problem is something that could be corrected as it appears to be an image timing issue.  I don't know but I'm just curious.  Here's the setup.

I used to run a CCR type of tree.  Meaning it wasn't CCR's but it was the same resolution 12 across by 50 pixels high (3 lights per pixel strip).  I would normally just do a LOR Data Layer import and BAM, it would work great.  This year, since I'm significantly changing my tree, the Data Layer import method will not work with the same sequences.  My tree this year will be 16 across by 200 pixels high bullet nodes.  So in order to use the same tree sequences I'll need xLights to do the conversion via Import Effects via SUP file rather than a raw data layer import or the LOR file.

Just to test I set this up in the latest, non-beta, version of xLights using my old tree model to start 12x50.  I purchase a lot of my tree sequences from holidaysequences.com and I'm using their Frozen mashup for this test example.  While the conversion worked for the most part I found one particular time when images stayed on the screen longer than they would in comparison to their raw data layer import partner would.  It may be happening in other parts as well but this was the one I almost immediately noticed.  I recorded it to show my example and comparison.

This first one is the data layer import version that I've used for years flawlessly:
https://drive.google.com/open?id=0B7E6agkvZj6wcmd3d0h0Ml95ZmM

Notice that at 0:24 of the video the Sun in the top right disappears, as it should

In comparison, here's the import effects version:
https://drive.google.com/open?id=0B7E6agkvZj6wdVgyY2hkN2stRnc

Notice that at 0:26 of the video the Sun is still in the top right and does not disappear for an additional few seconds.

This is what I'm reporting and I'm hoping is easily fixed due to some timing change on the image imports.  I obviously don't know how this works in the import process or how hard or easy it would be to fix this but, if it could be, it would be great   Thanks to all the Devs and everything you build for us.  I'm so grateful.  I'm only reporting this with the hope to improvement not just for myself, but for everyone!

I also wanted to note that I've tested this in the latest xLights BETA just in case as well as a couple of older non-BETA versions and it's the same result every time.  I can provide any files (SUP included) needed, directly to the Devs, to reproduce and potentially fix this.

Thanks again,
Nathan

[Gilrock]

I really think that is just a difference in how I coded the Fan effect versus how the equivalent works in SuperStar.  You can see how it starts expanding outward from the center at the end.  That is the tail time.  I don't think there are any timing problems.  It would be easy to check someone just opens the SuperStar sequence and looks at where the effect ends on the grid and add the tail time to it and then compare to the effect created in xLights.

[nmiller0113]

Thanks for the quick response Gil.  That makes sense.  I'll investigate further this evening when I get home from work and let you know my findings!

[Gilrock]

Yeah for that effect I realized some differences well after it was already being used by everyone.  The differences were more apparent when the number of elements is greater than 1.  To fix it I would need to create an alternate mode like a checkbox for a more SuperStar compatible version.  To be honest its not easy to figure out what is really happening to be able to create my own algorithm.  He has each element travelling as its own entity.

[nmiller0113]

Got ya Gil.  I appreciate all the effort.  I did go ahead and check it out between Superstar Sequencer and xLights and the timing of the effects *are* different unfortunately.

In SuperStar it is configured to span from 2:23.450 to 2:26.80

In xLights import it is configured to span from 2:23.450 to 2:30.850

So the xLights import starts right on time but for some reason extends out a full 4 seconds longer than the SuperStar original configuration.  Any thoughts?  I did test and I can manually adjust it and it ends perfectly.  My fear is that there are other places I may not notice right away.  There may be other imports that are impacted similarly, with different effects even, and if I don't notice them right away it could impact the show.  I'm honestly not complaining, just stating my concerns and if it is possible to fix that would be awesome.

If you need I can send you the .SUP file to test with as I know you've worked with Holidaysequences on compatibility with xLights and they're ok with that.  Thank you again for the quick response and your assistance!

[Gilrock]

If you have SuperStar all I need is to see the screenshot of the effect settings.

In SuperStar that effect does not typically end where the end time is listed.  If you single step in SuperStar you should see that at the end of where the effect is there is still stuff happening on the model.  At least that's how all the ones I've used looked.  Maybe you have a combination of settings that works different.  I had to experiment to try to guess at an algorithm for determining the extra length to add because in xLights we can't just say an effect is 3 seconds and then have it do something for 3.8 but that's what he does in SuperStar.  Below is my current formula for determining the extra tail time to add to that effect.  Part of the issue is also like I said that the xLights algorithm is not the same so figuring out this extra time is not precise.  You can see I added a 35ms fudge factor due to the problems in algorithm differences.

int tailms = int(double(endms-startms) * (blade_width * 2.0)/100.0) + 35;
endms += tailms;

[nmiller0113]

Sorry Gil, what a pain to have to match it up when the program you're matching to does not have a good way to timing the ending.

I do have Superstar.  I'll go ahead and get you a screenshot tonight and look at some specifics around when the effect actually ends vs what it says in the config.  Thanks again!

[Gilrock]

I'll be able to open SuperStar and just type in the settings and see what it's doing.

[nmiller0113]

Ok Gil, I've attached the screenshot here.  As you can see, it is going past the timing where it is marked to stop in the effect config.  It is marked to stop at 2:26.80 and it actually goes to 2:26.95, .15 seconds longer than the config shows.  Which is obviously not like the 4 seconds added in the xLights import.  Hopefully this is enough to help your figure out what is happening in the import.  I also PM'd you the .SUP file just in case.  Thanks again!

[Gilrock]

Yeah I got your file.  I can see my formula is wrong for determining the tail length.  I experimented with the parameters and it appears that both blade width and revolutions per second affect the tail length so this might take some time to figure out the right formula.

[nmiller0113]

Glad you found it Gil.  Sorry that it's gonna be a pain to correct!  Thanks again for everything!

[Gilrock]

Not that it will be a big pain to correct but I'm in the middle of a big effort already which also relates to SuperStar imports.  I'm adding support for the Fonts that are built into SuperStar which work well for smaller models.  This will allow me to get exact text matching when you import SuperStar as long as you haven't used custom fonts.

[Gilrock]

Oh and as you can see when using the fonts we embed into xLights you will be able to have each letter be a different color.   Since our palette is 8 colors that's the most you can have and then the colors will repeat.

[nmiller0113]

Nice!

[nmiller0113]

Gil, sorry to bother again. I was curious if you were tracking the issue I reported anywhere so that I could monitor to know when it was corrected without bothering you again?  Thanks again!