Regarding the realtime switch - you definitely can achieve it! You’d just need to handle the logic yourself. If you use transport.setLoopRange() and keep track of a counter, you can trigger the jump to the next marker at the end of the last loop. As long as you do it just before the loop point, the transition should stay sample-accurate.
I don’t see how this could work reliably because you’d need to move the markers during the block that is currently and ensure that the block aligns exactly with the loop boundary which in practice it never will.
What you’ll get in reality with this method is little blips of audio from the end or start of the loop section before you move the playhead to the new position.
For this to work properly you’d need to queue the loop position changes to happen on the audio thread but they’re not thread safe to change at the moment.
One thing that might work is to use the TransportControl::setPosition (TimePosition timeToMoveTo, TimePosition timeToPerformJump); function to move the playhead in a sample accurate way and then once that has happened move the loop markers on the message thread. As long as the loop markers are moved before the playhead reaches the end of the new loop end that might work. It’s not exactly clean though.
Ask Jules from 25 years ago when he wrote the logic
TBH I’d like to change it but there’s a chunk of code like in loop recording that takes the loop markers from the start (or it could be end) of the recording and uses them to create takes. If you could jump around that wouldn’t work.
BTW you can play before the start of the loop with rollInToLoop, it’s just the playhead will be modulo’d to the loop range past the start.