MSuperLooper freezes with Reaper and M1

[mpitkara]

Hi,

I'm using MSuperLooper with Reaper on a MacBook Air (M1 chip). I have a strange problem: when I record a loop and let it play for a few minutes, at some point it freezes for a second or so (stops playing). There are typically two small freezes in a row, then it continues (so it doesn't crash). And the weird thing is that if I let it play after that, the freeze doesn't seem to reoccur. However, if I clear the loop and record a new one, it will always occur again (but again, just once for that particular loop, no matter how long I let it play).

Some specs:
- MacBook Air M1 (16GB RAM)
- DAW: Reaper
- I've tried running Reaper both with or without Rosetta. Overall, it seems to work better with Rosetta (the glitch occurs quicker when not using Rosetta, and MSuperLooper occasionally crashes when not using it).
- The CPU and RAM usage is very low before/during/after the freezes so it's not a performance issue (also, all other plugins work fine).

Obviously this is really annoying, as we're using looping when playing live, so these freezes are not really acceptable. Has anyone had any similar issues?

Thanks!
/ Markus

[martin-meldaproduction]

Hello Markus,

It seems you are the first one reporting this issue in MSL. I wanna ask you these questions:
- which macOS version you are running?
- do you have Melda plugins on version 16.04?
- do you have option "silence when busy" ON or OFF ?(it is in the advanced global settings, you can try experiment whether it helps or not)
- are you able to reproduce the issue in any other DAW? Not sure if you can do this, but it can help to isolate the issue, maybe its only macOS and Reaper related.

Thank you in advance

[mevla]

Just an aside. In my case, in Linux, MSuperLooper's GUI needs to be shown for it to start at the same time as the DAW transport. Otherwise it is doing nothing.

I have the Full Bundle since many years, everything works just fine. Except for this behaviour from MSuperLooper.

DAW is the latest Bitwig 4.4.8, latest yabridge and its recommended wine version. Melda plugins are latest.

When compared to another sequencer-like plugin such as Sugar Bytes's Thesys made for Windows, Thesys works in accord with the transport, no problem at all. Same with other Windows sequencer-like plugins such as SonicCharge's Microtonic drum machine.

As I see it, MSuperLooper has a bug regarding this behaviour. It should start at the same time as the DAW transport no matter what.

Maybe this is related.

[mpitkara]

Hi Martin,
Thanks for your reply. To your questions:

- I'm using Mac OS Monterey 12.6.3
- Yes, I have MSuperLooper version 16.04 (and I'm using the VST3 MSuperLooper16in16out version)
- I had the "silence when busy" OFF when I experienced the issue. I now tried to set it to ON, but the issue persists. So this does not seem to have an effect on this.
- I don't have any other DAW that I could test this on. I do have an old PC somewhere with Reaper on it, so I could try it there. Though I don't have my plugins there and nothing is up to date, so it takes some time and effort.

Are there any other global settings that might affect this kind of behavior?

/ Markus

[Dirk Diggler]

Sounds like an OS issue to me.
Win version with Reaper doesn't have this issue here.

[mevla]

Sounds like an OS issue to me.
Win version with Reaper doesn't have this issue here.

Technically impossible to say so, as far as the observation I made above.

Every other Windows sequencer-like plugin works in conjunction with the DAW transport whether the plugin GUI is shown or not. Start the DAW transport, the Windows sequence-like plugin will start.

Not so with MSuperLooper. Its GUI have to be shown for it to 'wake up' and get the command to start. Looks a lot like a software problem. Maybe a corner case, in a more demanding environment, but a software problem nonetheless.

If that wasn't the case, then the other Windows sequencer-like plugins would behave just the same as MSuperLooper isn't it.

[mpitkara]

I don't have any issues with the the DAW transport described by mevla. With or without GUI, it starts fine. So the problem I described in this thread has probably nothing to do with that. The issue I have (with or without GUI) is that there occurs a glitch after a couple of minutes of looping (stops playing for the loops for a second or so, but then continues with no issues).

[mpitkara]

Some additional info here. I did some more thorough testing trying to see if there is any pattern. Interestingly, the issue seems to happen always after about 4.5 minutes of looping (+- 15 seconds). I tried multiple times with one loop, three loops and five loops at a time, and regardless of the number of loops, it's more or less the same time when it occurs. At least now when I was playing, the cut is actually shorter than a second, and there is also a clicking sound (jus once or maybe twice). Then the loop continues fine.

[mevla]

I don't have any issues with the the DAW transport described by mevla. With or without GUI, it starts fine.

OK ! That's how troubleshooting works.

Cheers.

[mpitkara]

I found a solution for this issue. By default, Reaper saves plugin state whenever there is a change, which allows you to undo changes to plugin configurations. When I disabled this functionality ('Disable saving full plugin state' in the Reaper preferences), the stuttering issue with MSuperLooper vanished. My guess is that when MSuperLooper is running a loop, Reaper thinks that the plugin state is constantly changing (as the pointer in the loop keeps moving). This undo history keeps accumulating, and after about 4 minutes, some buffer gets filled (or something else) which causes the stuttering effect. While undo history is great, I don't need it when playing live, so this works for me .

Anyway, just wanted to let you know, in case someone else is having the same issue with Reaper + MSuperLooper.

[funky lime]

I found a solution for this issue. By default, Reaper saves plugin state whenever there is a change, which allows you to undo changes to plugin configurations. When I disabled this functionality ('Disable saving full plugin state' in the Reaper preferences), the stuttering issue with MSuperLooper vanished. My guess is that when MSuperLooper is running a loop, Reaper thinks that the plugin state is constantly changing (as the pointer in the loop keeps moving). This undo history keeps accumulating, and after about 4 minutes, some buffer gets filled (or something else) which causes the stuttering effect. While undo history is great, I don't need it when playing live, so this works for me .

Anyway, just wanted to let you know, in case someone else is having the same issue with Reaper + MSuperLooper.

ANOTHER EDIT: My problem is solved, see latest post.

Running into the same issue here, trying to incorporate MSuperLooper into live rig with Reaper and this is potentially a deal breaker. (Windows 10, vst3, reaper 6.80). After several minutes of jamming, it seems like the plugin's state data gets to a sort of critical mass and then the whole audio stream completely glitches out for about 1 second, effectively pausing the music and throwing everyone off.

I've seen MSuperLooper's plugin state data as high as 128MB after these glitches happen. My reaper's max undo memory is set to 768MB, which is 3x the default setting ... not sure if any of this is even relevant though

Clever workaround, that "disable saving full plugin state," but unfortunately that messes a bunch of other project-wide stuff up in the process for my rig since it's globally applied to all plugins. Maybe I'll try a "read-only" alternate version of my projects on a portable reaper install with this setting and see how that works. Thanks for the tip!

In conclusion, this otherwise-fantastic plugin does not play well with Reaper at the moment, and that breaks my little heart. Damn shame, because this plugin is such a beast and does more than I could ever want from a looper! Until this is fixed, the plugin is unfortunately too glitchy to use on stage with Reaper. I'm still quite enjoying it regardless.

edit: experimenting with Reaper's "Compatibility settings -> Ignore VST3 setDirty calls" and "Save minimal undo states" settings on the MSuperLooper instance and it seems promising so far. Loops persist between sessions and the state data is still at 1kb after about 5 minutes (as opposed to dozens of MB, even 100+, like before). Will try a more thorough experiment this evening.

(one wildly uneducated guess is that clearing loops/tracks was ballooning this state data, and eventually reaper chokes on keeping up with it in real time)

edit again: nope, that wasn't it. just got a big glitch at 32mb and again at 64mb after a few minutes of jamming in the same session.

[funky lime]

Okay ... I feel dumb. I think I solved the "problem."

I had Reaper set to auto-save projects every 6 minutes as long as the transport is not recording.

So every 6 minutes, MSuperLooper would glitch out as the project was autosaved, mid-loop... saving the project increases MSL's state data size quite a bit if you've got a lot of loops stored. And this sudden big jump from 1kb to 64mb is enough to stall out the audio for a second while everything catches up.

User error! Seems to be working smoothly with auto-save disabled.

Going on 30 minutes now with no "glitches."

[martin-meldaproduction]

Hello funky lime,

I just wanted to ask you some more detailed questions about that, as I had no luck reproducing the issue under the latest macOS Ventura and Apple M1 Pro. I'm very glad to see that you have resolved this on your end. You can also try testing the difference with the option in our plugins: "silence when busy" ON or OFF, as it can make a difference in such scenarios.

Anyway, if there's anything we can do to help you at MSL, please don't hesitate to contact us in the future.

[mpitkara]

Indeed, disabling the auto-save feature also resolved the issue with my Apple M1 (I also feel very dumb now) . While enabling 'Disable saving full plugin state' did also resolve it, it did introduce some issues with other plugins, so I wouldn't recommend using that (there is a warning in Reaper not recommending to use the setting). But thanks funky lime!