Live Looper cutting off last bar in new firmware [FIXED]

I am not 100% positive this is a S2400 problem but I only started seeing this with the new Firmware update so I am starting here.

My setup is a Squarp Hapax sequencing samples from the S2400 as well as other synths on other Hapax tracks. My intention is to then use the live looper from the S2400 to throw in some bass or guitar. In many cases (but not always which is frustrating) the looper will appear to record properly but on playback the last bar is cut off. When this happens it happens for every subsequent loop that I create until I turn off the Hapax and start a new Hapax project.

Is there some midi message I could be sending or setting I could have (in the new firmware) that could be causing this? Anyone else experiencing this?

All this clocking the S2400 from the Squarp?

I can’t offer any ideas on the specific combo you have but I wouldn’t even begin using the looper if i was clocking the S2400 from an external source via midi clock, in fact I will probably never clock it via midi clock full stop.

If you are clocking via the analog clock in then it should in theory be solid, but I haven’t tested that yet. I will do soon.

1 Like

Interesting, thanks for this perspective. Prior to the update I haven’t had much issue with S2400 and midi, if that is indeed the issue. The Hapax is newish to my setup but I was using the Squarp Pyramid without issue using this setup. Prior to the S2400 update I hadn’t seen the issue either with the Hapax. I guess I would also expect that if the problem was clock related it would show up in other ways and not just a very repeatable and exactly cut off bar (like starting at the wrong time or sync issues). Also, I wonder how much does the looper itself relies on midi/clock outside of the timing starting and stopping?

I guess I could try switching to using the 2400 for master clock but I like having all of the sequencing/timing data in one place. It would suck if the solution to my problem is to have to choose between external sequencing my drums or using the looper. :frowning:

Re midi clock - it is known for its jittery nature and if the timing of a loop is altering even by 100ths of a second I could imagine this introducing issues at the level of audio recording in the S2400.

To be clear though I am not saying this is the cause, its just that midi clock is generally not 100% stable (although there companies and products that claim to resolve jitter in midi clock).

If you want the most reliable clocking of the S2400 I would try to sort out some analog clock solution and use that option on the S2400. I think this was also recommended by the Isla team, can’t remember where I heard/read that though.

1 Like

What you can do is reload last year firmware and do a comparison to make sure it is a problem with the new firmware.

By the way, what are your settings for the live looper and the bpm of your project? It is a basic question I know but depending on the bpm, the numbers of bars and the stereo/mono setting it is possible to have a number of recordable bars shorter than the number of bars of the pattern.

And in the live looper mode, if you press the Level button you can see the waveform of the live loop. So you can guess whether it is a recording problem or a playback problem after recording.

1 Like

Thanks for the reply, I will try and get back into my studio in a bit here and take a look at the settings and the wave form. I did play around a bit with the new settings and started getting the distorted sound problem that I saw some people reporting so I stayed pretty close to the default. I will report back.

Good to know. Will keep this in mind and see if I can figure out something that takes the midi clock out of the equation (at least for troubleshooting if nothing else). Although I don’t relish the idea of trying to sync all of my equipment to an analog clock - it feels like a gateway to eurorack!

OK so I think there is some validity to the tempo/settings theory. I created a simple 1 bar pattern on the Hapax running at 86 bpm and have the live loop config set on the 2400 like the following:

Type: Mono
Banks: 1(D)
Loops: 2

When I run my pattern (sending transport and clock to the 2400) and record a 4 bar loop the 4th bar is cut off.
When up my tempo to 100 and re-record the looper track runs for slightly longer and then cuts off.
When I up my tempo to 120 the loop doesn’t cut off.

Looking at the waveform it appears to be recording but not playing back the full loop. Going to post this comment and then upload a video of what I am seeing.

Banger alert!

More info. I have reconfigured my setup to take the hapax out. I first tried to do a beat entirely within the 2400 and that seemed to work (although I am now seeing another weird thing where the looper records but won’t play from the buffer - it only plays when I store it via the A button).

I also reconfigured to use my Keystep as the clock and same issue as the Hapax. Works at the 120-ish BPM gradually cuts off more and more of the loop buffer as you decrease the BPM.

Prior firmware with Hapax setup performing as expected. This is at 94 BPM but same results if I slow things down to 86.

Given that this problem doesn’t seem to be present in prior firmware and is happening across multiple MIDI control devices I am going to re-classify this as a bug. Mickey or whomever please feel free to de-classify this if this is an expected behavior or user error but I am unable to figure out a way to get external sequencing to work properly with the looper.

1 Like

This issue only arises when you are slaved to the Hapax, you don’t encounter this issue when the S2400 isn’t slaved correct?

Correct. But not just Hapax. Same with Keystep Pro. I haven’t tested with other MIDI clock sources.

My guess is that this is not depending on midi sync or a simple master synced setup. I got into a similar situation and my S24 is midi sync master.

The situation made me pay more attention to the way the machine calculates the remaining time/bars to record into the looper. When I add the C bank, the total number is doubled. When I switch from mono to stereo, the number is halved. This makes sense.

But now, when I half the number of loopertracks from 8 to 4, I expect the available time/bars to double. But this is not the case, at least not in the project I’m in. My guess is that the math is not correct (I’m quite sure) and this introduces the problem when we record into the loopertrack.

The amount that is off equals 1 track, so this probably means an (index + 1) or (index -1) situation in the formula for calculating the free remaining figure.


If it is relevant, I have an MRCC as a midi hub connecting all of the devices as well as a midi pedal controller setup to trigger the looper (although I didn’t use that in these videos, the looper was triggered manually using the pad).

All of these configurations work fine in prior firmware.

This tracks with my situation as well. Thinking it best to optimize the number of looper tracks allocated I immediately cut mine down to 4.

I didn’t try any of the above scenarios before making that change so I cannot verify that the problem didn’t exist before doing the reconfigure down to 4.

I can say that after reloading the new firmware my looper setup was still set to only 4 loops. I reconfigured to add back in the other 4 and the problem didn’t go away.

@syah71 The size of each loop = Total-RAM / (number-of-loops + 1). The +1 is for the record buffer.

1 Like

Damn, syah71 called this one perfectly.

@aleksklax How so? They said the math wasn’t right, but it is.

1 Like