Allow for programmatic offset values

[lastcoolnameleft]

I recently encountered an issue where I had everything honed in, but I was actually off by 1 flap. Instead of removing and shifting everything manually, it was easier to just do it programatically. My only concern is that it assumes the user has 4 modules (which is what the walkthrough has, so I figured it was a good assumption).

[scottbez1]

Sorry for taking a while to I respond.

If all of the modules are off by a full flap, would it make sense to instead change the definition of the flaps array in config.h so that your "home" flap (index 0) matches the physical implementation? i.e. if your modules show "a" when homed, then adjust the flaps array so that "a" is first instead of " "?

splitflap/arduino/splitflap/Splitflap/config.h

Lines 26 to 36 in 5ac6205

	// This should match the order of flaps on the spool, with the first being the
	// "home" flap.
	const uint8_t flaps[NUM_FLAPS] = {
	' ',
	'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm',
	'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z',
	'0', '1', '2', '3', '4', '5', '6', '7', '8', '9',
	'.',
	',',
	'\'',
	};

That seems like it would solve the problem without the complexity of an additional offset value, and avoids the ambiguity of what a positive "offset" means (does an offset of 1 mean that the next flap is shown or the previous flap? is a negative offset allowed? etc).

Let me know what you think!

[lastcoolnameleft]

The issue is that some of the flaps are not off at all and some flaps are off by 1. This is because I think I've gotten it in the right hole, but the module doesn't seem to act consistently unless it has all of the flaps installed. Once I've gotten all of the flaps installed, and I've noticed the error, it's often too late. That said, I'm willing to deprioritize this PR if I'm the only one that encounters it. Will leave it open for now and see if there's any feedback from others with a similar problem

Thanks again for your support!

[dmadison]

I ran into this same issue while testing. My solution was to add an etched indicator for the 'home' flap (#102) to avoid this problem during assembly. Especially with the config file idiom I think cleanly adding spool offsets in the firmware is going to be tricky.

I wonder if the sensor adjustment slot has enough play to account for a full flap off in either direction. That would be an easy fix without messing with the code or pulling all of the flaps off the spool.

[lastcoolnameleft]

The etched indicator is an even better solution. I realize that my version was laser cut with https://github.com/scottbez1/splitflap/releases/download/v0.6/v0.6_laser_vector_ponoko_mdf_4x.svg which doesn't have the home flaps shown. I'll close this bug and open one for that. Thanks!