Audiobus: Use your music apps together.

What is Audiobus?Audiobus is an award-winning music app for iPhone and iPad which lets you use your other music apps together. Chain effects on your favourite synth, run the output of apps or Audio Units into an app like GarageBand or Loopy, or select a different audio interface output for each app. Route MIDI between apps — drive a synth from a MIDI sequencer, or add an arpeggiator to your MIDI keyboard — or sync with your external MIDI gear. And control your entire setup from a MIDI controller.

Download on the App Store

Audiobus is the app that makes the rest of your setup better.

Loopy Pro MIDI clock drift problem

edited November 18 in Loopy Pro

Hey,

Been having issue w/ LP loops drifting from their clock source, be it LP as master, external, or Link. Basically, if I sync any external device to LP, the loops eventually go out of time by around 12-16ms, (when you blend the dry back in), regardless of every setting I’ve tried in LP. Is anyone having this problem? M1 iPad Pro, MOTU Ultralite mk5 as well as gen 3 iPad and MOTU mk3, with or without hub.

To elaborate, the dry synced device stays in sync with LP’s metronome, but the actual LP loop begins to drift from it’s own clock/ metronome, so the result is compounded offset (loop gradually falls more and more out of time).

Is there a launch quantization setting I’m missing?

Comments

  • edited November 18

    .

  • edited November 18

    .

  • I've been working a lot with MIDI clock and as cool as it is when working with the hardware club, there are a few general pitfalls.

    First of all, MIDI clock has no time information embedded. It's nothing but a simple sequence of "clock pulses" in the shape of MIDI messages. If just a single one of these messages gets lost (usually by the receiving app skipping a clock message for whatever reason - usually too low priority for clock processing), you already get a certain amount of drift in the range that you've described.

    Another thing I've seen is just plain wrong MIDI clock processing like e.g. in Cubasis 2: Syncing with a looped arranger section via MIDI clock would have Cubasis drift away by the time of exactly one clock pulse after each loop cycle.

    These are just general hints, more information about your exact setup could help pin down the problem.

  • @Illiacsound said:
    ...
    To elaborate, the dry synced device stays in sync with LP’s metronome, but the actual LP loop begins to drift from it’s own clock/ metronome, so the result is compounded offset (loop gradually falls more and more out of time).

    Could you share this LP project?

  • That's strange! Yeah, I'd love to see that project. You could email it to [email protected] if that's easiest. That definitely shouldn't be happening, obviously.

    Is this with 1.0.29, by the way?

    @rs2000 said:
    If just a single one of these messages gets lost (usually by the receiving app skipping a clock message for whatever reason - usually too low priority for clock processing), you already get a certain amount of drift in the range that you've described.

    Actually, LP should account for that.

  • @Illiacsound said:
    Hey,

    Been having issue w/ LP loops drifting from their clock source, be it LP as master, external, or Link. Basically, if I sync any external device to LP, the loops eventually go out of time by around 12-16ms, (when you blend the dry back in), regardless of every setting I’ve tried in LP. Is anyone having this problem? M1 iPad Pro, MOTU Ultralite mk5 as well as gen 3 iPad and MOTU mk3, with or without hub.

    To elaborate, the dry synced device stays in sync with LP’s metronome, but the actual LP loop begins to drift from it’s own clock/ metronome, so the result is compounded offset (loop gradually falls more and more out of time).

    Is there a launch quantization setting I’m missing?

    If the project isn’t synced to anything, do the loops stay synced to the metronome? If not, is it possible the loops aren’t exact multiples of a bar in length.

  • edited November 18

    @Michael said:
    ...
    Actually, LP should account for that.

    I'm sure it does, your sync engine is spectacular for a reason 😉

  • edited November 18

    @Michael said:
    That's strange! Yeah, I'd love to see that project. You could email it to [email protected] if that's easiest. That definitely shouldn't be happening, obviously.

    Is this with 1.0.29, by the way?

    @rs2000 said:
    If just a single one of these messages gets lost (usually by the receiving app skipping a clock message for whatever reason - usually too low priority for clock processing), you already get a certain amount of drift in the range that you've described.

    Actually, LP should account for that.

    Yes, forgot to mention I’m on 1.0.29. Thanks Michael! I’ll send the project over

  • @Illiacsound said:

    @Michael said:
    That's strange! Yeah, I'd love to see that project. You could email it to [email protected] if that's easiest. That definitely shouldn't be happening, obviously.

    Is this with 1.0.29, by the way?

    @rs2000 said:
    If just a single one of these messages gets lost (usually by the receiving app skipping a clock message for whatever reason - usually too low priority for clock processing), you already get a certain amount of drift in the range that you've described.

    Actually, LP should account for that.

    Yes, forgot to mention I’m on 1.0.29. Thanks Michael! I’ll send the project over

    Have you done that yet @Illiacsound ? I don't think I've got it yet...

Sign In or Register to comment.