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

12346

Comments

  • StudioESStudioES

    @j_liljedahl said:

    @ocelot said:

    @j_liljedahl said:

    @ocelot said:
    AUM Beta 1.4.0 (262):
    AUM's clock no longer slowly drift out of time after >20 bars at 44.1kHz on the 2017 iPad Pro 10.5 and 2018 iPad 6th Gen.

    AUMs beat clock didn't drift, only currentSampleTime (which should not be used for musical sync purposes anyway). But it now has zero jitter (if Link is disabled) which is nice :)

    It most certainly did. Have a gander at my long post above - or better yet, I'll recap it for you -

    The timing drift was an issue only on certain iPad models using internal iPad audio at 44.1kHz, in AUM only (2017 iPad Pro 10.5, 2018 iPad 6th Generation). Solution for these models is to use 48kHz in AUM, or use Audiobus or apeMatrix at either 44.1kHz or 48kHz.

    AUM, and long audio recordings made in AUM would slowly drift out of sync with other equipment (Octatrack, Akai Force, Model:Cycles, etc.) after >20 bars.

    This is now fixed. Thank you.

    But I didn't fix it. :) I only decoupled the beat time clock generation from Ableton Link (which is based on mHostTime) and instead use an exact sample based clock when Link is disabled. As soon as you enable Link, you will see the same drift again.

    This is because the beat time according to Link can't and won't be aligned with the precise sample time. On some devices and sample rates it's only minor jitter, on others it's large jitter, and on some it even drifts. This jitter and/or drift is present deep down in the CoreAudio timestamps, between mHostTime vs mSampleTime, and the reason it becomes visible with Link is because it's based on mHostTime. Looking at these two clock sources individually, both are correct, they just measure time differently when compared to each other, since their timing is coming from different sources in the device hardware.

    The same thing would happen if the beat clock is derived by following a MIDI clock or any other external sync source (apart from wordclock, where the actual sample time is synchronized).

    So, a sample accurate beat time can only be achieved when there is no external clock source (including Link).

    I thought I did read all your posts above, but I must have missed the part about external equipment. How were those synchronized with AUM in these cases?

    Two methods - audio recordings were made in AUM and transferred to other samplers, and when using AUM with other equipment - manual beatmatching, like old-school DJs.

    It's not an issue any longer, so in my book I'd call it a fix. Not sure if it's this 'exact sample based clock' or what, but again, it's fixed.

  • StudioESStudioES

    @j_liljedahl said:
    The same thing would happen if the beat clock is derived by following a MIDI clock or any other external sync source (apart from wordclock, where the actual sample time is synchronized).

    Are apeMatrix's and Audiobus' clock derived by following MIDI clock? I ask because when syncing those 2 to the Octatrack using MIDI clock, they don't drift. Neither do they when synced via Ableton Link on the Akai Force. Just curious.

  • j_liljedahlj_liljedahl

    @ocelot said:

    @j_liljedahl said:
    The same thing would happen if the beat clock is derived by following a MIDI clock or any other external sync source (apart from wordclock, where the actual sample time is synchronized).

    Are apeMatrix's and Audiobus' clock derived by following MIDI clock? I ask because when syncing those 2 to the Octatrack using MIDI clock, they don't drift. Neither do they when synced via Ableton Link on the Akai Force. Just curious.

    Yes, if you sync AB3 or apeMatrix to MIDI clock, they will derive their beat clock from that. Which means the beat clock will stay in sync compared to the MIDI clock, which is coming from the Octatrack. Same thing if synced to Akai Force via Ableton Link. In both of these cases, the clock will not stay in precise sync compared to a separate time measurement such as counting samples in a recorded audio file, because the clock is not sample based.

    Just to make sure, are you seeing drift if you sync AUM to Akai Force via Ableton Link, and compare the output of the Force with the AUM metronome? (Not Riffer, since in AUM it won't follow the beat clock).

  • StudioESStudioES

    @j_liljedahl said:

    @ocelot said:

    @j_liljedahl said:
    The same thing would happen if the beat clock is derived by following a MIDI clock or any other external sync source (apart from wordclock, where the actual sample time is synchronized).

    Are apeMatrix's and Audiobus' clock derived by following MIDI clock? I ask because when syncing those 2 to the Octatrack using MIDI clock, they don't drift. Neither do they when synced via Ableton Link on the Akai Force. Just curious.

    Yes, if you sync AB3 or apeMatrix to MIDI clock, they will derive their beat clock from that. Which means the beat clock will stay in sync compared to the MIDI clock, which is coming from the Octatrack. Same thing if synced to Akai Force via Ableton Link. In both of these cases, the clock will not stay in precise sync compared to a separate time measurement such as counting samples in a recorded audio file, because the clock is not sample based.

    Just to make sure, are you seeing drift if you sync AUM to Akai Force via Ableton Link, and compare the output of the Force with the AUM metronome? (Not Riffer, since in AUM it won't follow the beat clock).

    Should I use 262 or gold?

  • j_liljedahlj_liljedahl

    @ocelot said:

    @j_liljedahl said:

    @ocelot said:

    @j_liljedahl said:
    The same thing would happen if the beat clock is derived by following a MIDI clock or any other external sync source (apart from wordclock, where the actual sample time is synchronized).

    Are apeMatrix's and Audiobus' clock derived by following MIDI clock? I ask because when syncing those 2 to the Octatrack using MIDI clock, they don't drift. Neither do they when synced via Ableton Link on the Akai Force. Just curious.

    Yes, if you sync AB3 or apeMatrix to MIDI clock, they will derive their beat clock from that. Which means the beat clock will stay in sync compared to the MIDI clock, which is coming from the Octatrack. Same thing if synced to Akai Force via Ableton Link. In both of these cases, the clock will not stay in precise sync compared to a separate time measurement such as counting samples in a recorded audio file, because the clock is not sample based.

    Just to make sure, are you seeing drift if you sync AUM to Akai Force via Ableton Link, and compare the output of the Force with the AUM metronome? (Not Riffer, since in AUM it won't follow the beat clock).

    Should I use 262 or gold?

    Doesn't matter, the sample precise clock im AUM build 262 does not apply with Ableton Link enabled, which must of course be enabled for it to sync with your Akai Force.

  • StudioESStudioES

    @j_liljedahl said:

    @ocelot said:

    @j_liljedahl said:
    The same thing would happen if the beat clock is derived by following a MIDI clock or any other external sync source (apart from wordclock, where the actual sample time is synchronized).

    Are apeMatrix's and Audiobus' clock derived by following MIDI clock? I ask because when syncing those 2 to the Octatrack using MIDI clock, they don't drift. Neither do they when synced via Ableton Link on the Akai Force. Just curious.

    Yes, if you sync AB3 or apeMatrix to MIDI clock, they will derive their beat clock from that. Which means the beat clock will stay in sync compared to the MIDI clock, which is coming from the Octatrack. Same thing if synced to Akai Force via Ableton Link. In both of these cases, the clock will not stay in precise sync compared to a separate time measurement such as counting samples in a recorded audio file, because the clock is not sample based.

    Just to make sure, are you seeing drift if you sync AUM to Akai Force via Ableton Link, and compare the output of the Force with the AUM metronome? (Not Riffer, since in AUM it won't follow the beat clock).

    Thanks for the explanation.

    Okay, this gets stranger by the hour.

    Again, this is on the 2017 iPad Pro 10.5. Tested AUM Beta 1.4.0 (262) at 44.1kHz and 48kHz. Akai Force runs at ? AUM and Akai Force synced via Ableton Link (WiFi). Akai Force doesn't have Sync Start/Stop, so started AUM, then started Akai Force. Recorded AUM's metronome output to Left Input of Zoom H6. Recorded Akai Force's metronome output to Right Input of Zoom. Trimmed audio files so both start at around the same time.

    Results: Near the start of the recordings, AUM looks a bit late, but it's not audible. With AUM at 44.1kHz, both AUM and Akai Force slowly start to drift, but it's not noticeable, since both are drifting by the same amount. With AUM at 48kHz, AUM and Akai Force don't drift.

    AUM at 44.1kHz - At start (AUM Metronome=Left Channel (top); Akai Force Metronome=Right Channel (bottom)):

    AUM at 44.1kHz - After 100 bars (AUM Metronome=Left Channel (top); Akai Force Metronome=Right Channel (bottom)):

    AUM at 44.1kHz - After 200 bars (AUM Metronome=Left Channel (top); Akai Force Metronome=Right Channel (bottom)):

    AUM at 48kHz - At start (AUM Metronome=Left Channel (top); Akai Force Metronome=Right Channel (bottom)):

    AUM at 48kHz - After 100 bars (AUM Metronome=Left Channel (top); Akai Force Metronome=Right Channel (bottom)):

    AUM at 48kHz - After 200 bars (AUM Metronome=Left Channel (top); Akai Force Metronome=Right Channel (bottom)):

    2021/12/26 Test Setup: 2017 iPad Pro 10.5; iPadOS 15.2; Audio: Internal iPad audio, AUM Beta 1.4.0 (262); Sample rate: 44.1kHz & 48kHz; Akai Force; Ableton Link (WiFi).

  • j_liljedahlj_liljedahl

    @ocelot said:

    @j_liljedahl said:

    @ocelot said:

    @j_liljedahl said:
    The same thing would happen if the beat clock is derived by following a MIDI clock or any other external sync source (apart from wordclock, where the actual sample time is synchronized).

    Are apeMatrix's and Audiobus' clock derived by following MIDI clock? I ask because when syncing those 2 to the Octatrack using MIDI clock, they don't drift. Neither do they when synced via Ableton Link on the Akai Force. Just curious.

    Yes, if you sync AB3 or apeMatrix to MIDI clock, they will derive their beat clock from that. Which means the beat clock will stay in sync compared to the MIDI clock, which is coming from the Octatrack. Same thing if synced to Akai Force via Ableton Link. In both of these cases, the clock will not stay in precise sync compared to a separate time measurement such as counting samples in a recorded audio file, because the clock is not sample based.

    Just to make sure, are you seeing drift if you sync AUM to Akai Force via Ableton Link, and compare the output of the Force with the AUM metronome? (Not Riffer, since in AUM it won't follow the beat clock).

    Thanks for the explanation.

    Okay, this gets stranger by the hour.

    Again, this is on the 2017 iPad Pro 10.5. Tested AUM Beta 1.4.0 (262) at 44.1kHz and 48kHz. Akai Force runs at ? AUM and Akai Force synced via Ableton Link (WiFi). Akai Force doesn't have Sync Start/Stop, so started AUM, then started Akai Force. Recorded AUM's metronome output to Left Input of Zoom H6. Recorded Akai Force's metronome output to Right Input of Zoom. Trimmed audio files so both start at around the same time.

    Results: Near the start of the recordings, AUM looks a bit late, but it's not audible. With AUM at 44.1kHz, both AUM and Akai Force slowly start to drift, but it's not noticeable, since both are drifting by the same amount. With AUM at 48kHz, AUM and Akai Force don't drift.

    This is not strange! Your experiment show that AUM and Akai Force are not drifting in relation to each other, since they are synchronized via Link. It also shows that the Link beat time is drifting in relation to the sample clock of your Zoom H6. This is perfectly normal, since your H6 is not synchronized in any way to the rest of the system (Link). And even if you instead of the H6 used a Link-synced host to record the result, it would drift compared to the recorded number of samples, because again Link is based on "host ticks" and not sample time.

    When you're looking at the beat grid in a recorded file, you're actually looking at an ideal beat time defined by sample time. If the recorded sources are not deriving their beat time from sample time (but instead from Link or MIDI Clock), it will drift more or less.

    Also, even at 48kHz you will see the drift between Link and sample time you're demonstrating with your experiment, because two sample clocks will drift sooner or later unless they are sample-synchronized via wordclock. But it might take a very long time to see it.

    For some reason, the beat time from Link on iOS deviates more from an ideal sample precise time on some devices and some sample rates. I doubt there is anything to do about this, since the problem is present already in the CoreAudio system layer. Maybe Link could find some work around to detect and compensate for this, but that should be done directly in Link-for-iOS in that case so maybe it's worth submitting an issue about it on their github.

    By the way, the reason the two metronomes are not perfectly lined up, but has a small constant offset to each other, is because neither Akai Force or AUM has any way of knowing at which point in the signal chain these two signals are mixed, so it does not know the amount of latency to compensate for. AUM follows Ableton's recommendation of including the device output latency (as reported by iOS) when calculating the Link time. So in this particular case I would actually expect them to line up when mixed externally as you're doing, but it seems Akai Force is not including its own output latency correctly in the calculation. It could also be iOS not reporting the exact output latency. In any case, this can be manually adjusted in AUM using the "Sync Offset" setting, to adapt to your particular configuration and setup.

  • wimwim

    This discussion is making me nostalgic for the good old days when people made music. B)

  • StudioESStudioES

    Thank you for taking the time to explain it in layman's terms, @j_liljedahl.

    I wish I'd used 48k in AUM on those specific iPads earlier. I usually just record audio loops in AUM, so LINK is usually disabled, but am glad that it's now better at 44.1, with LINK disabled. Nice to not be limited to 8 and 16 bar audio recordings any longer.

    Word Clock, beat time, sample time, host time...MIDI Clock, MTC, MMC, SMPTE, LINK...

    Uff, that's why I lost a lot of hair working at a TV station years ago. Syncing is a b*tch! (And I'm too dumb and impatient).

    @wim said:
    This discussion is making me nostalgic for the good old days when people made music. B)

    Me too! ...just pulled out my guitar...'hey I bet this would sound good with a tempo-synced delay plugin' 😜

    But aren't we all just trying to get folks on the dance floor, rather than clearing them with sloppy timing?

  • j_liljedahlj_liljedahl

    I've reported this as an issue on Ableton Links github: https://github.com/Ableton/link/issues/110

  • espiegel123espiegel123

    @j_liljedahl said:
    I've reported this as an issue on Ableton Links github: https://github.com/Ableton/link/issues/110

    Do you think the change you made for when Ableton link is off will solve the problems that was discussed a year or two ago of loops required at 44.1kHz being slightly too long or too short while 48K was always perfect?

  • j_liljedahlj_liljedahl

    @espiegel123 said:

    @j_liljedahl said:
    I've reported this as an issue on Ableton Links github: https://github.com/Ableton/link/issues/110

    Do you think the change you made for when Ableton link is off will solve the problems that was discussed a year or two ago of loops required at 44.1kHz being slightly too long or too short while 48K was always perfect?

    Yes, I think so. In the next AUM update, recording a loop should yield a consistent and mathematically correct number of samples, if Link is disabled.

  • _ki_ki
    edited April 2022

    I re-tested the MIDI AUv3 without sample offset and checked the one i newly acquired - here the current version of the list:

    With sample-offset

    • Aphelian
    • Atom
    • Atom 2
    • Autony
    • Cality
    • cycle
    • DigiKeys
    • DigiStix
    • Drambo
    • DrumComputer
    • Euclidean
    • Fugue Maschine
    • Hammerhead (used as midi sequencer loaded in midi slot)
    • Helium
    • Ioniarics
    • LK (only for the note-on, the Note-Off don‘t use sample-offset)
    • midiGATE (forwards sample-offset of its input, tested with X0X) )
    • MiRack
    • Mozaic
    • Octachron
    • Poly 2 (only for the note-on, the Note-Off don‘t use sample-offset)
    • polybeat (only for the note-on, the Note-Off don‘t use sample-offset)
    • Polythemus (forwards sample-offset of its input, tested with X0X) )
    • Pure Acid (used as midi sequencer loaded in midi slot)
    • QuanitChord (forwards sample-offset of its input, tested with X0X) )
    • Riffer
    • Rozeta Arp, Bassline, Cells, Collider, PArticles, Rhythm, XOX
    • Ruismaker Noir (used as midi sequencer loaded in midi slot, updated version)
    • ScaleBud (forwards sample-offset of its input, tested with X0X) )
    • Senode
    • SnakeBud
    • StepPolyArp Unit
    • StreamByter
    • Thesys
    • Zoa

    .

    Without sample-offset

    Midi generators that don‘t set the sample-offset will produce sync-issues.

    • ArpBud 2
    • Axon 2 (used as midi sequencer loaded in midi slot)
    • BeatHawk (used as midi sequencer loaded in midi slot)
    • ChordBud 2
    • Chordjam
    • EG Pulse
    • KB-1 (for ARP feature)
    • MidiEcho (tested with X0X input)
    • MIDI Tape Recorder Fed with midi input containing sample offset
    • Photon
    • Physicles Bouncy
    • Physicles Gravity
    • PlayBeat 3 (Track 1 correctly sends to plugins midi output with sample offset. Tracks 2-8 can only send to AUM destination and don’t apply sample offset)
    • RhythmBud
    • StepBud

    .

    Could not check

    I don’t own the following midi AUv3, so i could not check themCould not check these midi apps as i don‘t own them. But some of the devs already offer AUv3 midi apps with correct sample-offset, so it’s likely they also support it.

    • DigiStix 2 From 4Pockets, dev of Helium
    • Mela 3 (Midi arp module) From Nicolozi Meladze
    • MelodyBud From Cem Olcay
    • midiDREAMs From Arthur Kerns, dev of midiLFOs
    • MidiSTEPs From Arthur Kerns, dev of midiLFOs
    • MIDI Strummer From 4Pockets, dev of Helium

    • NuRack Midi From 4Pockets, dev of Helium

      .

    Changes in this version of the sample-offset list
    New in the list and with sample offset:
    o Euclidean
    o Polybeat
    o Polythemus
    o Senode
    o ScaleBud
    o SnakeBud
    o Thesys

    Fixed:
    o Helium v1.3.4 - Zero sample offset on loop wrap was fixed
    o Riffer v3.1.4 - Now applies sample offset and sends to plugin midioutput

    New in the list and without sample offset:
    o Chordjam
    o MIDI Tape Recorder

    Strange:
    o PlayBeat 3 v3.1.0 - Track 1 sends to plugins midi output with sample offset . Tracks 2-8 can only send to AUM destination and don’t apply sample offset)

  • MisplacedDevelopmentMisplacedDevelopment

    Thanks for this stirling work @_ki . Surprised to see MIDI Tape Recorder in there.

  • _ki_ki
    edited April 2022

    @MisplacedDevelopment Yes, i also wondered when i did the test about an hour ago.

    The timing issues resulting from always using sample offset zero only are mainly noticible with the long buffer size of 2048. MIDI Tape Recorders main difference to other midi recorders is that it doesn‘t change the event order ( which is needed for correct mpe playback) and its main usecase is recording live played input which never is 100% on time - maybe that‘s why nobody noticed the timing inaccurary.

    @GeertBevin My test with XoX sending notes including sample offset beeing recorded and then played back with all notes using sample offset zero shows that there is some room for improvment.

    I didn‘t have the time to take a look at the source code ( https://github.com/gbevin/MIDITapeRecorder ) to confirm the ‚zero‘ parameter.

  • _ki_ki
    edited April 2022

    Hmm, it seems that in MIDI Tape Recorder Plugin/DSP/MidiRecorderKernel.mm line 883 in midirecorderkernel::outputMidiMessages() a sample offset is supplied to the midi output block - so maybe it‘s not correctly recorded from X0X ?

    But i don‘t have XCode or a Mac to step through with a debugger and that’s also the first source of an midi AUv3 i had a look at - maybe i looked at the wrong function :)

  • GeertBevinGeertBevin
    edited April 2022

    ki said:
    Hmm, it seems that in MIDI Tape Recorder Plugin/DSP/MidiRecorderKernel.mm line 883 in _midirecorderkernel::outputMidiMessages()     a sample offset is supplied to the midi output block - so maybe it‘s not correctly recorded from X0X ?

    But i don‘t have XCode or a Mac to step through with a debugger and that’s also the first source of an midi AUv3 i had a look at - maybe i looked at the wrong function :)

    @_ki MIDI Tape Recorder captures, stores, reads and sends sample offsets for each MIDI message.

  • _ki_ki
    edited April 2022

    @GeertBevin But why didn‘t it work in my test scenario ?

    How to reproduce:

    • In AUM set the buffersize to 2048
    • Load a Rozeta X0X instance and set a note at every beat. Disable ‚808 timings‘ in the X0X settings
    • Load MIDI Monitor of the MIDI tools suite from Victor Porof (the only midi logger that displays the sample offset)
    • Press AUM play and use MIDI Monitor to inspect the X0X output. It uses a non-zero dample offset for all notes (except the very first)

    .

    • Load MIDI Tape Recorder and send the X0X midi to MTR
    • Press AUM play and capture 1 or 2 bars on MTR track 1 (maybe adjust loop to 4 beats)
    • Unlink X0X input from MTR
    • Replay MTRs track 1 and inspect with MIDI Monitor

    => All sample offsets of MTR of the recorded X0X notes are zero

  • GeertBevinGeertBevin

    @_ki can you describe your test in detail so that I can try to reproduce your findings?

  • _ki_ki
    edited April 2022

    @GeertBevin More description than in the ‚how to reproduce‘ posting with 8 steps above ? What part should describe in more detail ?

    I attached the AUM session (where MTR already recorded the X0X input), to load it you need

    If you are missing one of the plugins, you probably can ask their devs (Jonatan, Bram or Victor) for a code.

    BTW: I am on an iPad Pro 10.5 using IOS 14.8.1, but for sample-offset testing that shouldn‘t matter.

  • MoogMusicIncMoogMusicInc
    edited April 2022

    .

  • GeertBevinGeertBevin
    edited April 2022

    @_ki said:
    @GeertBevin More description than in the ‚how to reproduce‘ posting with 8 steps above ? What part should describe in more detail ?

    I attached the AUM session (where MTR already recorded the X0X input), to load it you need

    If you are missing one of the plugins, you probably can ask their devs (Jonatan, Bram or Victor) for a code.

    BTW: I am on an iPad Pro 10.5 using IOS 14.8.1, but for sample-offset testing that shouldn‘t matter.

    No that description is plenty. It looks like our messages crossed. I'll try to test and reproduce this later today.

  • GeertBevinGeertBevin

    @GeertBevin said:

    @_ki said:
    @GeertBevin More description than in the ‚how to reproduce‘ posting with 8 steps above ? What part should describe in more detail ?

    I attached the AUM session (where MTR already recorded the X0X input), to load it you need

    If you are missing one of the plugins, you probably can ask their devs (Jonatan, Bram or Victor) for a code.

    BTW: I am on an iPad Pro 10.5 using IOS 14.8.1, but for sample-offset testing that shouldn‘t matter.

    No that description is plenty. It looks like our messages crossed. I'll to test and reproduce this later today.

    I can reproduce it and I have an idea why this is happening, I'll have to take a couple of hours to really look in detail. It looks like a regression that was introduced in one of the last versions. The messages are recorded correctly, somehow they end up having a negative sample offset at output.

  • _ki_ki
    edited April 2022

    @GeertBevin 👍🏼 Thanks a lot for fast investigation

  • PoppadocrockPoppadocrock

    @_ki said:
    As @cem_olcay did send me a promo code (thanks!) i was able to test SnakeBuds sync.

    It applies sample-offset (seen in MIDI Monitor) and stays in sync with X0X in the most problematic setting (2048 buffersize at 441.khz) . I checked if SnakeBud starts to drift in longer sessions, everything was still fine after 100 bars.

    Keep up your good work !

    @_ki said:
    I re-tested the MIDI AUv3 without sample offset and checked the one i newly acquired - here the current version of the list:

    With sample-offset

    • Aphelian
    • Atom
    • Atom 2
    • Autony
    • Cality
    • cycle
    • DigiKeys
    • DigiStix
    • Drambo
    • DrumComputer
    • Euclidean
    • Fugue Maschine
    • Hammerhead (used as midi sequencer loaded in midi slot)
    • Helium
    • Ioniarics
    • LK (only for the note-on, the Note-Off don‘t use sample-offset)
    • midiGATE (forwards sample-offset of its input, tested with X0X) )
    • MiRack
    • Mozaic
    • Octachron
    • Poly 2 (only for the note-on, the Note-Off don‘t use sample-offset)
    • polybeat (only for the note-on, the Note-Off don‘t use sample-offset)
    • Polythemus (forwards sample-offset of its input, tested with X0X) )
    • Pure Acid (used as midi sequencer loaded in midi slot)
    • QuanitChord (forwards sample-offset of its input, tested with X0X) )
    • Riffer
    • Rozeta Arp, Bassline, Cells, Collider, PArticles, Rhythm, XOX
    • Ruismaker Noir (used as midi sequencer loaded in midi slot, updated version)
    • ScaleBud (forwards sample-offset of its input, tested with X0X) )
    • Senode
    • SnakeBud
    • StepPolyArp Unit
    • StreamByter
    • Thesys
    • Zoa

    .

    Without sample-offset

    Midi generators that don‘t set the sample-offset will produce sync-issues.

    • ArpBud 2
    • Axon 2 (used as midi sequencer loaded in midi slot)
    • BeatHawk (used as midi sequencer loaded in midi slot)
    • ChordBud 2
    • Chordjam
    • EG Pulse
    • KB-1 (for ARP feature)
    • MidiEcho (tested with X0X input)
    • MIDI Tape Recorder Fed with midi input containing sample offset
    • Photon
    • Physicles Bouncy
    • Physicles Gravity
    • PlayBeat 3 (Track 1 correctly sends to plugins midi output with sample offset. Tracks 2-8 can only send to AUM destination and don’t apply sample offset)
    • RhythmBud
    • StepBud

    .

    Could not check

    I don’t own the following midi AUv3, so i could not check themCould not check these midi apps as i don‘t own them. But some of the devs already offer AUv3 midi apps with correct sample-offset, so it’s likely they also support it.

    • DigiStix 2 From 4Pockets, dev of Helium
    • Mela 3 (Midi arp module) From Nicolozi Meladze
    • MelodyBud From Cem Olcay
    • midiDREAMs From Arthur Kerns, dev of midiLFOs
    • MidiSTEPs From Arthur Kerns, dev of midiLFOs
    • MIDI Strummer From 4Pockets, dev of Helium

    • NuRack Midi From 4Pockets, dev of Helium

      .

    Changes in this version of the sample-offset list
    New in the list and with sample offset:
    o Euclidean
    o Polybeat
    o Polythemus
    o Senode
    o ScaleBud
    o SnakeBud
    o Thesys

    Fixed:
    o Helium v1.3.4 - Zero sample offset on loop wrap was fixed
    o Riffer v3.1.4 - Now applies sample offset and sends to plugin midioutput

    New in the list and without sample offset:
    o Chordjam
    o MIDI Tape Recorder

    Strange:
    o PlayBeat 3 v3.1.0 - Track 1 sends to plugins midi output with sample offset . Tracks 2-8 can only send to AUM destination and don’t apply sample offset)

    Honestly can’t thank you enough for doing this. It’s very important to monitor these types of things so people have answers to any timing issues they might run into, the actual performance of apps, and weighing any purchasing decisions. Cheers!

  • GeertBevinGeertBevin

    @_ki said:
    @GeertBevin 👍🏼 Thanks a lot for fast investigation

    @_ki Thanks a lot for finding that regression, MIDI Tape Recorder 1.0.6 is now available in the App Store and fixes this issue in my testing. Can you please confirm?

  • PoppadocrockPoppadocrock
    edited April 2022

    @GeertBevin said:

    @_ki said:
    @GeertBevin 👍🏼 Thanks a lot for fast investigation

    @_ki Thanks a lot for finding that regression, MIDI Tape Recorder 1.0.6 is now available in the App Store and fixes this issue in my testing. Can you please confirm?

    Thanks for the update.

    Yea big thanks to all those who meticulously tested out and measured the performance of the apps. Especially @_ki

  • _ki_ki

    @GeertBevin Yay, cool 👍🏼 MTR now outputs sample-offsets - even for already recorded tracks in saved sessions :)

  • GeertBevinGeertBevin

    @_ki said:
    @GeertBevin Yay, cool 👍🏼 MTR now outputs sample-offsets - even for already recorded tracks in saved sessions :)

    Awesome, thanks for testing!

  • martinjuenkemartinjuenke

    Is someone tracking the progress of the missing devs?

Sign In or Register to comment.

© Vanilla Keystone Theme 2024