External sync - request for some additional parameters

edited August 2015 in Support and Feedback

Preface: Loopy is sync'd to RC505. The RC505 plays drum loops which vary in length on a per-song basis. Some songs are sync'd to an 8 measure drum loop, some are synced to 2 measure loop etc. The song form in Loopy is a multiple of the measures in the drum loop.

Without gong into too much detail, I've been experiencing a frustrating problem related to external MIDI sync, but the problem is not loss of sync to the clock - the problem is related to Loopy rotating the play cursor of a loop recording immediately upon exiting record i.e. the recorded loop is rotated (time shifted) on punch-out, but Loopy remains sync'd to the beats. Quite often Loopy rotates the loop by 30% - 50%. Other loops in the recording remain in place - only the loop currently being recorded is affected. This often seems to happen if the overall cycle isn't an exact multiple of the measure length in the RC505.

I hinted this issue in a previous post on August 1 here:


I think it only occurs when sync is external, perhaps further complicated by the master clock coming from another loop station.

The problem occurs no matter which of the 3 options I choose for Count Out behaviour.

So my real, underlying questions for Michael are these:

Can you provide some insight into the logic (IF THEN ELSE?) applied by Loopy when deciding what to do upon punch-out during external sync? Under what circumstances will Loopy time-shift (rotate) the current loop subjected to the punch-out?

The problem could be fixed by a new preference - Sync to MIDI Clock ON, Sync between loops OFF, Loops locked to time (and Clock) as recorded.

IF external sync is enabled AND Count In is disabled AND Count Out is disabled (i.e. manual punch in/out) AND sync between loops is disabled, THEN upon punch out, retain sync to beat clock even though sync between loops is not demanded.

In other words, Loopy should respect the punch in/out points and not time-shift any of the tracks. This would have the effect of keeping the loops in sync to each other if they are well played and in time with the beat clock,without Loopy attempting to time-shift any of the individual loops.

In other other words, even if the user has set the track manager to not maintain sync between loops, Loopy should keep all loops locked to external beat clock as recorded irrespective of the cycle length.

As far as I know, there is no way currently to sync Loopy to external clock without also syncing loops recorded into Loopy. As soon as the "sync loops to each other" parameter is switched off, external clock sync also falls over. I want Loopy to sync to external clock, but to keep each loop sync'd in the exact time location it was recorded in.

Is that possible?



  • An addendum to the above: I actually cant think of a single circumstance where I would want Loopy to time-shift any loop upon punching out of record, so I'm not sure if the current behaviour is intentional in Loopy's code or if it is a bug.

  • edited September 2015

    Second addendum: Actually, I'd forgotten that Loopy sorta kinda seems to do this by design (when count in and count out are enabled?), to enable punch in anywhere besides midnight during a cycle. Upon punch-out, the visual display is corrected by rotation, but the recorded audio remains in time as recorded. That is useful in multiple situations, but the problem I'm experiencing is a shift in the play cursor which accompanies rotation of the loop. Both behaviours are wrong in my case - the recorded loop should not be rotated and the play cursor should not jump ahead/behind the punch-out position (hence this seems like a bug due to unintended consequences of a feature).

    Golden rule (for me anyway) - Loopy should never time-shift recorded audio and play cursor should never jump to a different point in the overall cycle. Play cursor and recordings should remain locked to the beat clock at all times.

  • This is most definitely a bug, @Diggo - cheers for flagging it!

    There's some stuff Loopy does with manual punch in/out, where when the recording ends, it'll see if the loop endpoint is going to be other than at the 12 o'clock position. If it is then it offsets the clock invisibly so that the new loop starts at 12 o'clock. We want that, because it means timed pause/play will occur at the right point in the track.

    That's how it's meant to work. What's happening here, is that the clock can't offset - because it's slaved to an external clock. It just gets reset to the prior offset straight away. Just an oversight on my part, basically.

    I'll make it remember what the offset is when connected to MIDI, so that it sticks, should solve the problem. I'm doing it now, watch your inbox for the Testflight invitation.

  • Okay, fixed and submitted to Apple ready for Testflight testing once they approve. You'll get a notification once it's ready, in a day or two.

  • Fantastic news and greatly appreciated Michael! Did I say yet how wonderful it is that Loopy is well on the way to becoming the best looper on the planet? That's because the creator of the app goes above and beyond to ensure his professional users are looked after and his app continually evolves for the better. Compare that to (say) the RC-505, which hasnt evolved at all since release and hasnt had a firmware or driver update since 2013, despite multiple flaws in the original design (particularly related to MIDI control).

    I'm very happy with the new clocking parameter structures in v1.4.17, no doubt appearing as a result Masterpiece and the Spectacular Sync Engine. These are exciting times!

    To anyone reading this thread, if you havent watched Michael's videos regarding MIDI sync in iOS, do yourself a favour and watch them now:


  • Thanks heaps for the kind words, @Diggo, that made my day =)

  • (FYI: here's the video about sync:)


  • I think it does effect the in app midi clock, I never had sync problems before. Even if I bend it a bit (that a standar procedure for all app within audiobus) it keeps loosing track.
    Nice words indeed and true.


Sign In or Register to comment.