Ah, that's not quite what I meant.
As you were talking about the difficulty of storing button presses (for double and halve) I meant setting a new 'length-doubling' parameter to represent
only those button interactions. IE of halving or doubling any established value. The established value is already handled by your existing system
So, this new proposed parameter doesn't need to handle any tricky absolute values such as "15.3.3 " , but a only to provide a relative system, with a 'baseline at value 64, and with each press of double or halve incrementing or decrementing this 'offset' parameter from that baseline.
So for example: if a user records their initial loop using "record four bars then overdub", then at bar 16 presses the 'double' button, then the double button again, the outcome of this whole process would be:
bar 1 to bar 16 : this new parameter = 64 (the centerline or baseline value)
press once : this new parameter = 65 (double)
press again : this new parameter = 66 (double again)
the single digit increments representing a doubling of the initial value. The initial value is not relevant, it could easilly be and loop length of 3.1.2, or 0.0.3 - it would not matter. That initial length is handled by the (already recorded) pressing of the record and overdub buttons, and only the missing functions are handled by my proposed length-offset parameter.
with 64 values in each direction from the center line you have room for most eventualities. Doubling four bars 64 times gives a length of 3.40282367 × 10
^38 bars
Enough for any eventuality I think! (Thanks to exponential doubling of course)
Well, I know it's not a perfect solution but, it would be a lot better than the current situation, which means we cant record our looper performances unless the length stays the same !