@Clashley1 + @21echoes, great info, thank you for the additional insight!
i wrote much of this before your posts, but it sat drafted, so apologies if anything doubles-back.
auto-chop: dependent on the audio clip length, automatically distributes the slices/pads evenly across the total time (when used with ALT+, otherwise just distributes that one pad at its x/16 division). affects start + end point position.
1/16th length: dependent on the system clock, automatically shortens the slices/pads to a 1/16th note’s length. affects end point position. i often use this before auto-chop, and then use the zilchmos gestures for doubling a loop length to get 1/8ths, 1/4ths, etc.
the arp function is just a way to play back your pads/slices, so it’s entirely dependent on the pad/slice positions. if those aren’t all aligned with the material, then the arps won’t be aligned.
if i’m still misunderstanding the issue here, let’s hop on a call – hmu! 
those extra performance details help – just to make sure i’ve got it:
- you’re pointing each bank to each live buffer segment (bank a to segment 1, bank b to 2, 3 to 3)
- you’re setting pad 1 of each bank to the full length of the incoming recorded audio
- you play some audio in
- pad 1 begins playing back the audio you recorded and you begin playing to it (after switching to a new live segment)
- since the playhead of pad (which gives you a definite sense of location) and the record head are not locked to each other, you end up in a zone where you’re committing new audio that’s totally independent from the previously recorded segment
ultimately (and most critically for the situation), the three playheads and the single record head are decoupled in cheat codes by design. the only time when any play/record heads are linked is in [delay]. if it helps to share: the personal musical goal of the live recording components was to feed material on-demand as a reaction to needing new content to be pulled apart, rather than looping that material’s original performance.
i originally thought you were using the script in a cascading sort of situation, where the three banks are pointed to the same live buffer segment. this is how @zanderraymond seems to most often uses cheat codes – pad 1 of bank a will be playing back at 1x, pad 1 of bank b will be playing back at -0.5x, pad 1 of bank c will be playing back at 2x, all playing back the same live-recorded material with different rates + auralization 
the basics of what you’re describing is what one-shot record mode was made to facilitate – it has three launch modes: next beat, next bar, and free. but it doesn’t loop. so perhaps it’d help to have launch modes for the looping recording, so that you can cue up a new looping recording and the record head will start in an expected place? and then you can simultaneously press pad 1 (which will have the long loop) to make sure that it’s playhead starts at the same time as the record head – lmk if this feels like it’d be a good solution?
in the coming update, i’ll also expose the # section of the [loops] page, where you can watch the playheads for all three banks + the live recording segment in one place.
