Oh, right... boo! :( (more loopers...)

trying to implement some loopers here, in a situation where i want BPM to be sync’d to another person. ALO is the logical looper solution in the MOD ecosystem – it’s well-tested for me now, with internal sync.

problem: syncing to incoming MIDI clock is slightly unstable and ALO immediately dumps it’s loops and resets whenever the tempo changes, so fails immediately because the tempo is wandering around a bit.

hrmmmmmm… any ideas?

I don’t have experience with loopers but maybe @falkTX have something to share on this…

1 Like

There is always a bit of a drift when using MIDI sync, we cannot escape that.
v1.8 made things a bit better, still not optimal though.
But even if timing is better, there will be drift as the MIDI resolution is not very high.

One idea is just to make the MIDI sync less precise on purpose, so that it will stick into a specific BPM and stay there.
As of v1.8 we are rounding to 2 decimal places. So we could offer an option to round to 1 or even 0 decimal places. That should work for this case perhaps…
What do you think? @plutek

2 Likes

sounds like a great solution for when using MIDI sync… i’d use an option to round to 0 decimal places, if it existed!

thanks, @falkTX!

FWIW I’ve update ALO to use rounded whole-number BPM. I haven’t tested in great depth but hopefully it will work for @plutek’s usecase

3 Likes

wow, beautiful!

i’ll report back, once i’ve had a chance to test!

Great to do read this.
I’m just fiddling around with a similar setup like @plutek and just stumbled over the same issue.
I’ll check it out the next days as well.

Sounds like a good idea.

I would add a request if this makes sense for you:
“Ignore incoming MIDI transport Start/Stop commands”

Background:
Like @plutek I just try to setup some stuff with my ModDuo (also including the ALO Looper) where the MOD should be a MIDI clock slave to some master clock.

While checking this out with another musician’s MIDI equipment being the clock master, I learned that the MOD will follow transport start/stop commands for its own transport if these are sent.

My observations:

  • After external transport start from the MIDI master it takes some time until the clock is stable again -> the measured BPM seems to reclock after such an “transport event”, starting always with a low value. Clock seemingly does not restart from its previous value.
    –> ALO Looper Audio will be lost due to resync and changing BPM rates during this process
    –> Other sounds (e.g. triggered from a step sequencer) seem not in sync for some bars
  • Some MIDI equimpment seems not to be configurable to switch of it’s transport commands on their MIDI outputs, but sometimes (like in this case) it seems to be helpful just to have the clock but nothing else - so maybe a good MIDI slave option to have a flag to “Ignore incoming MIDI transport Start/Stop commands”.
1 Like

Hi devcurmudgeon,
Test took some days longer than expected.
I just checked the rounding, but unfortunately this doesn’t work.
Easy test with internal clock:

  • e.g. set BPM to 120.00
  • record something with the looper
  • while running set BPM to 120.01 --> ALO seems to drop the recoded signals due to the change
    Best regards,
    Dan

@Dan_The_Man I’ve tested that and it seems to work for me. Are you sure you’re running the new version?

On further investigation it seems the new version didn’t land in the store. Hopefully that will change when this pull request lands

Sounds great.
I’ll check it out as soon as possible.