Sean Meighan
Software => Bugs in xLights/Nutcracker => Topic started by: BobinWV on April 15, 2015, 10:36:42 AM
-
Having problems with timing marks. NC4.0.20
Open New Sequence..select song..timing track is created....add some models and when I play the song timing is entered but the connecting links between the timing marks is hit or miss.
I went back to NC4.0.17 and timing marking works perfectly.
BobinWV
-
It's not clear to me how you are creating the timing marks.
-
i made a video showing the issue
https://vimeo.com/125066573
-
I had the double timing mark issue on one computer but not another. A work around is to lower the keyboard repeat rate in Windows control panel. The double timing marks when pressing "t" while playing issue went away.
-Steve
-
i made a video showing the issue
https://vimeo.com/125066573
I have had all those issues occur. Just another vote for the problem.
-
I'm at work I can't watch videos. The original description didn't say how you were creating the timings. It said "when I play the song timing is entered". Does that mean you hit 't' while the sequence was playing? Does it work ok when the sequence isn't playing?
-
Sorry for the confusion..yes I was using T to mark the timings.
-
Well this will be hard for me to fix because it's working perfect on my machine.
-
Would remoting (teamviewer etc) in to his machine help any? Just trying to help, sorry if this is silly idea.
-
It's happening to Sean also. The best I can do right now is I'll try to inspect how we make the decision whether to connect to the previous timing mark because that's what isn't happening.
-
And I'm pretty sure what change I did that caused this. The problem is the change I checked in was fixing another bug that nobody had reported. Without that change you could keep hitting 't' and get a whole stack of timings in the same spot.
-
Ah I finally figured out how to recreate it. I installed the release version. Another case where it works great in the debug build but not in the release build. This is caused by something I had worried about but convinced myself it was ok. I'm doing a comparison of two floating point values which is normally a no no due to this exact reason. For some reason the comparison is failing even though the exact same X position is being fed through the calculations. So the comparison fails due to a floating point precision difference. Not sure why this only occurs in release versions. Probably something to do with the extra optimizations that occur for a release build.
-
As always, thanks for the time you spend on this.
-
Ok fix is checked in...balls in Sean's court. ;)