xl/nc release 4.1.2

[sean]

Latest releases are found at http://nutcracker123.com/nutcracker/releases/
Issue Tracker is found here: https://github.com/smeighan/xLights/issues

XLIGHTS/NUTCRACKER RELEASE NOTES:
---------------------------------
4.1.2  Jun 4, 2015
    -- enh(gil)   Lots of improvements to cell selection...still need to fix issue with off screen effect selection.
    -- bug(gil)   Add protection around calling cell selection logic with uninitialized values to prevent crashes.
    -- enh(gil)   Grey out the Create Random effects option if there is no selection.
    -- enh(dkulp) Add setting for Render at save.   Turning off will save the fseq in it's current state.
    -- bug/enh (dkulp) Lots of work on SingleStrand Chase effect to get it to work better with small models and single color models and grouped arches.

[JonB256]

    -- enh(dkulp) Add setting for Render at save.   Turning off will save the fseq in it's current state.

Thanks for this one. Saves me about 30 seconds on Saves when I really don't need to update the FSEQ file.

[gerry]

    -- enh(dkulp) Add setting for Render at save.   Turning off will save the fseq in it's current state.

Thanks for this one. Saves me about 30 seconds on Saves when I really don't need to update the FSEQ file.

What would be an example of not requiring the fseq file to be updated ?
Is it when you are just sequencing and not testing the output on actual lights ?

[Gilrock]

Most of the time I really just want my XML to be saved because that has all the effect definitions and I can always open that back up and generate the sequence.   We are constantly rendering your effects to the object that ultimately gets written out to the fseg file.  But sometimes there could be an effect that was only partially rendered or possibly not combined with a data layer.  When you hit render all it re-processes everything and so did the old save.  But the new save will save the XML and it will store whatever we've already rendered to the sequence data object to the fseq file.  I think a goal is eventually we run threads in the background at a low priority that try to make sure everything is up to date and then saves will be close to instantaneous.

[JonB256]

The fseq file is good for several things for me - It actually stores all the light data for playback in Preview and it can be transferred to my Raspberry Pi to display my show.

If I am not worried about the Preview tab being up to date or not ready to use my Pi, rendering and saving the fseq is a waste of time.

[sean]

Gil and Dan; constantly improving. Last year in xl 3.6, my saves took a few minutes (24k channels). 4.0 multithreaded engine dropped that down to 10-30 sec range. Now their goal is my 24k channels will save in < 1 sec. We should create more goals for them


Sent from my iPhone using Tapatalk

[Gilrock]

I've noticed the stability of the program seems to have greatly improved with the last release.  I didn't have a single crash on exit last night and usually I get one every 2 or 3 times I close the program.  I think it's due to the popup dialog asking if I want to save changes.  That must change something in Windows that prevents those mouse events from firing to the grid on close.  Maybe because mouse focus changes to that dialog.

[gerry]

The fseq file is good for several things for me - It actually stores all the light data for playback in Preview and it can be transferred to my Raspberry Pi to display my show.

If I am not worried about the Preview tab being up to date or not ready to use my Pi, rendering and saving the fseq is a waste of time.

Thanks  for your reply, and to Gil too.

I think that where youll are with this speed is stupendous - I used LSP ..... Would have so so loved a render later button there.

[plaberge]

Nice to have the speed improvement! Without the background threads, I can, however, already imagine the posts about the fseq loaded on a FPP not matching what they see in the sequencer...

[dkulp]

I've noticed the stability of the program seems to have greatly improved with the last release.  I didn't have a single crash on exit last night and usually I get one every 2 or 3 times I close the program.  I think it's due to the popup dialog asking if I want to save changes.  That must change something in Windows that prevents those mouse events from firing to the grid on close.  Maybe because mouse focus changes to that dialog.

It's likely due to the popup, but not how you think.   When you hit the quit button, I now call CloseSequence as that's where the popup occurs.   Thus, the entire sequence is closed (and thus all the data removed and cleaned up) prior to the grid being destroyed.  Any mouse events and such that then come in are ignored cause there isn't an open sequence.  :-)

And yes, things are WAY WAY more stable all around.  I actually did a couple hours of sequencing last night and other than some selection logic issues, a couple of bugs in the single strand effect rendering wrong, and some problems with single frame effects, it didn't crash.

[JonB256]

Could the Preview page do a date/time comparison of the Fseq file and XML file and show a caution?

"The File you are viewing is not the latest rendering"

[Gilrock]

I'm not sure if it's hard to do but I think we should have a rendering progress bar and whenever you make a change we start to fix the render with low priority threads and then you would be able to look at the progress bar to know if render is complete. If it is then a save would be super speedy.

[Gilrock]

Regarding crashes on close I thought we were always closing the sequence in exit and calling stop now. The crashes on windows for me were usually a mouse hit test trying to run after the sequence had been closed and destroyed the objects.

[gerry]

I've noticed the stability of the program seems to have greatly improved with the last release.

Absolutely agree. Used to crash 9/10 times when saving (windows), but with the last two releases this issue is gone. Lovely to work with now ..