Timing marks problem

[BobinWV]

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

[Gilrock]

It's not clear to me how you are creating the timing marks.

[sean]

i made a video showing the issue

https://vimeo.com/125066573

[flyinverted]

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

[jnealand]

i made a video showing the issue

https://vimeo.com/125066573

I have had all those issues occur.  Just another vote for the problem.

[Gilrock]

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?

[BobinWV]

Sorry  for the confusion..yes I was using T to mark the timings.

[Gilrock]

Well this will be hard for me to fix because it's working perfect on my machine.

[Phrog30]

Would remoting (teamviewer etc) in to his machine help any? Just trying to help, sorry if this is silly idea.

[Gilrock]

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.

[Gilrock]

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.

[Gilrock]

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.

[Phrog30]

As always, thanks for the time you spend on this.

[Gilrock]

Ok fix is checked in...balls in Sean's court.