Unintuitive pulloff speed

[kneasle]

If Wheatley is given a peal speed and the user is assigned 1 and 2 then we would expect it to still ring at the expected peal speed, regardless of what 1 and 2 do.

[kneasle]

I think a good fix for this would be to parameterise the minimal dataset size that a regression line can be made from, and increase its default value from the current 2.

Perhaps this parameter would be better as a proportion of the bells in the row. @centreboard, what do you think? Maybe some testing is required.

[centreboard]

Would it work to populate the data set initially with 15 bells that were rung exactly correctly (or to give the effect by some other technique)? So Wheatley is more inclined to be on the beat at the start and then adapts to the rhythm set?

[kneasle]

If Wheatley will wait indefinitely for people to ring, I think this would be OK. But what I've been trying to avoid at all costs is Wheatley overtaking people during the pull-off because he thinks that the other ringers should be ringing quicker than they currently are. The current behaviour of having inertia set to 0 during the pull-off seems to be working well, but it doesn't make much sense if the user sets inertia to 1 for the rest of the ringing and the only human-rung bells are the 1 and 2, since RegressionRhythm 'overfits' to these two datapoints and is then stuck forever on that speed. Hence, I think that my suggestion to simply increase the minimum number of bells that Wheatley needs before the dataset is considered big enough for a regression line to be statistically valid mitigates this issue without risking adding the overtaking behaviour. I'd be happy to experiment with different strategies though, but I currently want to get the RR integration stable before working anything else large.

The main issue with the RegressionRhythm is that (kinda by design) it only updates to speed changes slowly, otherwise it would risk making radical speed adjustments that are probably unnecessary.