Thanks for checking it out
Both apps take some advantage of the current 16-step limit in terms of the data types they use, but this only really matters in terms of the way Hemisphere applets save and load their settings. Each applet is allotted 32 bits for all of its save/load storage. ShiftReg actually stores its full register, so it'd need another 16 bits on top of what it already uses (to store the current 16 bits, P and scale values.) I think that could be done with some hacking of the suite's storage but I haven't plumbed into that sort of thing yet
I'd be curious about TB-3PO extending its step count. The main advantage of using a seed and deterministic random algorithms to generate the pattern is that all you have to store is the seed and it can recreate all the pattern data automatically. Its random generation is already split up over a couple of interrupt calls so it doesn't use up too much of the compute time and it might not be a big deal to just have a second set of these run for the backside 16 steps. TB-303 already doesn't store its current step count because there wasn't room to begin with I'll have a play with it at any rate, thanks for the suggestion.