Loopy Pro: Create music, your way.

What is Loopy Pro?Loopy Pro is a powerful, flexible, and intuitive live looper, sampler, clip launcher and DAW for iPhone and iPad. At its core, it allows you to record and layer sounds in real-time to create complex musical arrangements. But it doesn’t stop there—Loopy Pro offers advanced tools to customize your workflow, build dynamic performance setups, and create a seamless connection between instruments, effects, and external gear.

Use it for live looping, sequencing, arranging, mixing, and much more. Whether you're a live performer, a producer, or just experimenting with sound, Loopy Pro helps you take control of your creative process.

Download on the App Store

Loopy Pro is your all-in-one musical toolkit. Try it for free today.

Let’s talk about midi sequencer timing

12467

Comments

  • @j_liljedahl said:
    I'll have a look. But I don't have Riffer and can't find Oscilloscope AU on app store. You have a link?

    Please check your inbox <3

  • @_ki said:
    @j_liljedahl Here a link for Oscilloscope & Spectrogram AUv3. I asked AudioModern to send you a promo code for Riffer on their forum.

    Got one, thanks!

  • @_ki said:
    @j_liljedahl I now have two seemingly identical AUM sessions:

    • One based on ocelots session showing timing drift between X0X and Riffer. The drift is 1/16 after around 130 bars

    • One build from scratch with the same plugins, routings, settings - without drift

    .

    AUM X0X/Riffer/Plectrums Session with drift

    AUM X0X/Riffer/Plectrums Session without drift

    Clearing the AUM session and importing the 4 channels of the ‚drifting‘ session (instead of loading that session) will play without drift.

    .

    I attached both sessions, can others please test run them (to around bar 130) to check if they show the same mysterious drift/no drift and perhaps @j_liljedahl could you have a look into the session file where this different behaviour might come from ?

    Are you sure the problem is not in Plectrum?
    I just tried your Drift session, but didn't have plectrum so substituted it with Zeeon with a short plucky sound. After 250 bars still no drift..

    See if you can replicate it with Zeeon or some other instrument known to handle timestamps correctly.

  • _ki_ki
    edited December 2021

    @j_liljedahl Okay, i‘ll try the two sessions using Zeeon.

    Plectrum is a very simple free AUv3 with a noice burst feed into a resonator.

    .

    The „drift session“ still drifts after i exchanged Plectrum for Zeeon:

    The „no drift“ session with Zeeon is not showing drift.

    .

    Speculating: Do you store the bpm as float ? How is that comunicated to the AUv3 midi plugins ? Maybe in one case it‘s 120.005 shown as 120.0 but riffer adjusts to the precicse bpm value ? (There can only be drift, if bpm and play-start is the sole reference used. I assume that x0x sync to bar/beat/whatever send by AUM.

  • Regarding the X0X instances. I do hope that that 808-timing is disabled in the settings...

  • _ki_ki
    edited December 2021

    @Samu Yes, the 808 timing is disabled in all instances/ sessions.

    The main mystery to me is, why is the session based on ocelots original session drifting every time i try it, while the other build from scratch isn‘t.

  • _ki_ki
    edited December 2021

    I just got more and more confusing.:

    • Starting from XoX/Riffer/Zeeon based on oscelots AUM session i checked for the drift (1/16 at around 140bars)
    • Then i removed all four tracks (midi/2 audio/bus) and rebuild the layout - checked for drift and yes, there it still is.
    • Now i pressed AUM clear and rebuild the 4 tracks again - and the drift still persisted (over the clear action) !
    • As last step i loaded my seemingly identical ‚no drift‘ session with X0X/Riffer/Zeeon and … no drift.

    No change to tempo, link or buffer settings. Superweird.

    I can record a sceen-recording if there is disbelief, but since the whole round takes ≈20mins i would need to cut it shorter in lumafusion or let you skip in boring „wait for bar 140“ parts of the YT video :)

  • wimwim
    edited December 2021

    Wow, so complicated.

    It's so much cleaner just to route the plugins to record audio out to two channels panned left and right, then look at the recorded output in an audio editor.

    @_ki - I would test but I don't have the apps in question. I'm only relating how I've tested before.

  • The user and all related content has been deleted.
  • edited December 2021

    @_ki said:
    @j_liljedahl Okay, i‘ll try the two sessions using Zeeon.

    Plectrum is a very simple free AUv3 with a noice burst feed into a resonator.

    .

    The „drift session“ still drifts after i exchanged Plectrum for Zeeon:

    The „no drift“ session with Zeeon is not showing drift.

    .

    Speculating: Do you store the bpm as float ? How is that comunicated to the AUv3 midi plugins ? Maybe in one case it‘s 120.005 shown as 120.0 but riffer adjusts to the precicse bpm value ? (There can only be drift, if bpm and play-start is the sole reference used. I assume that x0x sync to bar/beat/whatever send by AUM.

    It's a 64 bit float, yes. But then, if you double tap the tempo adjuster and write "120" manually, it should be exactly 120. Do you still get drift after this?

    I will investigate when I find some dev time, but I can't think of anything related that's saved in the session file except tempo. And that would survive a session Clear! Very weird indeed.

    Also interesting that I couldn't reproduce it. This iPad is stuck on 48kHz, yours?

  • This is an interesting thread. I have actually noticed timing inconsistencies with EG Pulse. It adds a little bit of swing that I sometimes appreciate and sometimes do not. I think if I ever go back to beatmaking, I’m going to have to choose a different drum sampler.

  • @j_liljedahl said:
    It's a 64 bit float, yes. But then, if you double tap the tempo adjuster and write "120" manually, it should be exactly 120. Do you still get drift after this?

    Already tried that, but it didn‘t fix the drift (even first changed to 50.0 and then back to 120.0 using that tempo dialog). Toggling link didn‘t change the drift of that specific session.

    Also interesting that I couldn't reproduce it. This iPad is stuck on 48kHz, yours?

    My iPad Pro 10.5 / IOS 14.8 device runs at 44.1kzh.

    .

    Could anyone else reproduce the drift behavior (or is it just me with the ‚infective‘ AUM session from ocelot ) .

    @ocelot Did you try to restart AUM and build a sync test session from scratch on your device and does this fresh session also drift ?

  • @Audiomodern said:

    @j_liljedahl said:
    I'll have a look. But I don't have Riffer and can't find Oscilloscope AU on app store. You have a link?

    Please check your inbox <3

    Well done. A great developer supporting another great developer to solve a problem. What a forum.

  • @tja said:

    @wim said:
    Rather than using a script, the way I prefer to test is a known accurate sequencer triggering a sample in a known good player, panned left, and the app to be tested triggering another instance of the same sample/sampler panned right. The resulting mix down from the host makes it easy to zoom in on timing errors.

    I like this method better. Maybe it's just because I don't always trust my code and have even less reason to think a developer would trust results relying on my code. Or my ears for that matter.

    That's a good one.

    Which App is a good player to compare against?

    I use Rozeta XOX, with 808 timing disabled, and the app to be tested driving two Ruismakers with the same preset and the same pad. Or two hammerheads with the same sample. Atom 2 could be used as well, as I think it is sample-accurate. I just fire it off after appropriate cleanup and reboot of the iPad, and come back 30 minutes later to scan the results. Simple and effective.

  • The user and all related content has been deleted.
  • @tja said:
    I also wanted XOX to drive different Pads, but was not able to find a way to do this😅😅😅

    Different pads? I don't understand.

  • edited December 2021

    @_ki said:
    @ocelot Did you try to restart AUM and build a sync test session from scratch on your device and does this fresh session also drift ?

    Yes. The AUM session ("Riffer + Playbeat Drift") attached to my earlier post was created 2 years ago.

    I now use this process:

    • Force-close all open apps
    • Reset iPad memory
    • Open AUM, sample rate=44.1kHz, buffer=512, Metronome=On, Metronome Audio Output=Left.
    • Add MIDI Track, add Riffer (make a simple quarter notes pattern)
    • Add Audio Track, add Plectrum (Riffer as its MIDI source), Audio Output=Right.

    Tests today and yesterday: After ~40 bars, I can clearly hear Riffer>Spectrum start to drift in timing, both before and after AUM's metronome, at 44.1kHz only, with 512 buffer - in AUM only. And it gets worse as time marches on.

    The timing issues aren't apparent in AUM at 48kHz, or in Audiobus or apeMatrix at either 44.1kHz or 48kHz.

    Tomorrow Later this week: I'll use a MIDI monitor and also record the audio output from AUM's metronome and Riffer>Spectrum.

    Notes: The timing issues with the Audiomodern and Cem Olcay MIDI apps isn't as bad as many Windows apps, so as a workaround I record up to 8-bar audio, but I'd like to record 16+ bars without sloppy timing.

    Test Setup: 2018 iPad 6th Gen; 2017 iPad Pro 10.5; iPadOS 15.2 (both iPads); Storage Space: 20GB/45GB+ remaining; Audio: Internal iPad audio, Sample rate: 44.1kHz; no external peripherals used while testing.

  • I don’t know if this true, but a developer recently told me that some of the 44.1khz capable iPads are really running at 48k … and the OS returns some strange buffer timestamps when they run at 44.1k but not at 48k

  • @espiegel123 said:
    I don’t know if this true, but a developer recently told me that some of the 44.1khz capable iPads are really running at 48k … and the OS returns some strange buffer timestamps when they run at 44.1k but not at 48k

    Yes something like this could be it. Did you try 48k @ocelot ?

  • @j_liljedahl said:

    @espiegel123 said:
    I don’t know if this true, but a developer recently told me that some of the 44.1khz capable iPads are really running at 48k … and the OS returns some strange buffer timestamps when they run at 44.1k but not at 48k

    Yes something like this could be it. Did you try 48k @ocelot ?

    Yes. The timing issues aren't apparent in AUM at 48kHz, or in Audiobus or apeMatrix at either 44.1kHz or 48kHz.

    Tests today and yesterday: After ~40 bars, I can clearly hear Riffer>Spectrum start to drift in timing, both before and after AUM's metronome, at 44.1kHz only, with 512 buffer - in AUM only. And it gets worse as time marches on.

    The timing issues aren't apparent in AUM at 48kHz, or in Audiobus or apeMatrix at either 44.1kHz or 48kHz.

  • @ocelot said:

    @j_liljedahl said:

    @espiegel123 said:
    I don’t know if this true, but a developer recently told me that some of the 44.1khz capable iPads are really running at 48k … and the OS returns some strange buffer timestamps when they run at 44.1k but not at 48k

    Yes something like this could be it. Did you try 48k @ocelot ?

    Yes. The timing issues aren't apparent in AUM at 48kHz, or in Audiobus or apeMatrix at either 44.1kHz or 48kHz.

    Tests today and yesterday: After ~40 bars, I can clearly hear Riffer>Spectrum start to drift in timing, both before and after AUM's metronome, at 44.1kHz only, with 512 buffer - in AUM only. And it gets worse as time marches on.

    The timing issues aren't apparent in AUM at 48kHz, or in Audiobus or apeMatrix at either 44.1kHz or 48kHz.

    I see, ok! That’s weird. Does Riffer have any hardcoded assumption of 44.1k, or buffer size, @Audiomodern ?

    And I’d like to understand why it happens only in AUM, but only with some sequencers. @Audiomodern Are you using current beatPosition from the host sync struct to determine time, or something else?

  • The user and all related content has been deleted.
  • @tja said:

    @wim said:

    @tja said:
    I also wanted XOX to drive different Pads, but was not able to find a way to do this😅😅😅

    Different pads? I don't understand.

    I just added some notes and wanted to direct the MIDI to another pad in Ruismaker.
    But that does not seem to be possible - you just need to directly select another instrument in X0X.

    I was seeking a way to configure MIDI port / channel for that and could not find something liek this.

    In short: Ignore my strange question 😅

    You can change the midi note sent for each instrument in XOX. So, for instance to trigger pad 2 from the BD instrument, just change the note from 49 to 51. Use the icon that looks like a star on a circle at lower left corner of the app.

  • edited December 2021
    The user and all related content has been deleted.
  • @Poppadocrock said:

    @_ki said:
    The new PlayBeat 3 also goes into the list of ‚AUv3 generators with sync problems‘. I informed the dev AudioModern on their own forum - perhaps this stirs up some change (maybe also for Riffer)

    .

    If @cem_olcay would fix his midi output code in his AUv3 generators, the list of problematic plugins would get a lot shorter at one strike :)

    A few months ago he actually mentioned to me he was going to look into this in a DM, but I haven’t heard anything since. I do believe he is working on something so he is probably busy. Hopefully he sees this and finds the time.

    I released a new update for SnakeBud today. I’ll update the rest during next few weeks. I’m also working on a new generative sequencer as well. Anyways, hope the update fixes the problem, let me know!

  • @cem_olcay said:

    @Poppadocrock said:

    @_ki said:
    The new PlayBeat 3 also goes into the list of ‚AUv3 generators with sync problems‘. I informed the dev AudioModern on their own forum - perhaps this stirs up some change (maybe also for Riffer)

    .

    If @cem_olcay would fix his midi output code in his AUv3 generators, the list of problematic plugins would get a lot shorter at one strike :)

    A few months ago he actually mentioned to me he was going to look into this in a DM, but I haven’t heard anything since. I do believe he is working on something so he is probably busy. Hopefully he sees this and finds the time.

    I released a new update for SnakeBud today. I’ll update the rest during next few weeks. I’m also working on a new generative sequencer as well. Anyways, hope the update fixes the problem, let me know!

    Update is live, thanks for this!

  • _ki_ki
    edited December 2021

    @cem_olcay Cool, thanks for working on that problem 👍🏼

    .

    Could someone else please do a sync test with snakebud and check the sample-offset eith MIDI Monitor, as i don’t own it ?

  • @Audiomodern @cem_olcay thank you for addressing this. That is awesome news! 👍

  • edited December 2021

    @cem_olcay added sample accurate timing to SnakeBud

    Thank you man. Love your apps. Cheers!

  • @cem_olcay said:

    @Poppadocrock said:

    @_ki said:
    The new PlayBeat 3 also goes into the list of ‚AUv3 generators with sync problems‘. I informed the dev AudioModern on their own forum - perhaps this stirs up some change (maybe also for Riffer)

    .

    If @cem_olcay would fix his midi output code in his AUv3 generators, the list of problematic plugins would get a lot shorter at one strike :)

    A few months ago he actually mentioned to me he was going to look into this in a DM, but I haven’t heard anything since. I do believe he is working on something so he is probably busy. Hopefully he sees this and finds the time.

    I released a new update for SnakeBud today. I’ll update the rest during next few weeks. I’m also working on a new generative sequencer as well. Anyways, hope the update fixes the problem, let me know!

    You da man, man.

Sign In or Register to comment.