The Beats interface definition of findNthBeat is that if you are on a beat then for n = 1 and n = -1 then you get dSamples back.
https://github.com/mixxxdj/mixxx/blob/master/src/track/beats.h#L73

There are also tests that checked this that are now broken :)
https://github.com/mixxxdj/mixxx/blob/master/src/test/beatgridtest.cpp
https://github.com/mixxxdj/mixxx/blob/master/src/test/beatmaptest.cpp

The reason I wrote it this way is so we have symmetry between forward and backward movement and I also wanted code to be able to tell when it was on a beat. So that left me with the behavior in master:
```
beatlength=100
firstBeat = 0
findNthBeat(100, 1) == 100
findNthBeat(100, 2) == 200
findNthBeat(100, -1) == 100
findNthBeat(100, -2) == 0
```

This prevents code all across Mixxx re-implementing the same "am I on a beat" code -- probably buggily. Now client code just has to look at return values of findNthBeat to determine that.

Your change makes it work this way:
```
beatlength=100
firstBeat = 0
findNthBeat(100, 1) == 200
findNthBeat(100, -1) == 200
```

So the -1 direction is now jumping forward by 1 beat. For it to have symmetry I think it should work this way:
```
beatlength=100
firstBeat = 0
findNthBeat(100, 1) == 200
findNthBeat(100, -1) == 0
```

So to change this I think you need to update every use of Beats b/c they're all based on the assumption that you get the current sample back if you're on a beat for ```abs(n) == 1```. I think this bug is more a case of the beatgrid code not taking this behavior into account.