Adam

You’ll see in the OP that I have already tried raising the buffer.

No: I’m not stretching the clip. I’m just dragging the groove clip so the loop is repeating across more bars.

yep: I'll give that a try. And yes, I am capturing midi via a drum controller. The thing is, I've been doing this for quite a while; with the new update, I'm suddenly having all the issues I've mentioned. I'm hoping @Noel Borthwick might chime in here.

Yep: I know this trick. I'm talking about extending midi groove clips, not audio.

Nothing difficult in terms of testing. Track some midi, turn it into a grooveclip loop, and, extend it. When I do that I can feel my system start lagging around 2-3 minutes of extending that groove clip loop (I can tell, as, I notice the movement of the drag start stuttering, whereas usually, it just extends no problem. No, I'm not stretching midi or anything like that; just extending grooveclip loops so they're running over a longer time period. Seems to be put huge strain on the system.

some more testing this morning before my next session; if I open up a new session with SD3, no issues. I play a few bars into it, and, no problem. But, if I drop in, say a 7 minute loop into the midi, then, suddenly everything becomes sluggish. As soon as I start dragging out the loop beyond a few minutes I can feel the lag introduced. I just found a temporary solution: I'm dragging the midi into the SD3 midi player, and, removing it from Sonar midi and the issue goes away. It appears there is some new code around midi that is buggy: again, I've been using Sonar the same way (using SD3 to create multiple loops) for years and this is the first time I've had an issue.

just updated the driver (was a year old); went back into a session, attempted to split a single midi track and I'm getting a 'this application is not responding' message.

I was using the Fields of Rock SDX and triggering it via an SPDSX Pro, which inputted midi notes into Sonar itself. It doesn't matter which pack I'm using though; the default pack was just as slow. I usually use SD3 in multitrack mode with each instrument sending to its own track (split mode) in sonar (so I had split 12 stereo tracks all with midi in them). This was causing crashes (doesn't usually). But, even running just one track I was getting very slow performance and super slow saves. It's definitely only happening after the latest update I installed that same morning.

Yes: it is. I'll check that. Thanks.

Since updating to Sonar 2025.09 build 036 x64 I’m getting constant crashes and extreme MIDI sluggishness with Superior Drummer 3 (a new issue; worked fine on previous version). Editing MIDI (cutting/resizing) hangs for 20–30 s; saving takes minutes. Crashes show Unhandled Exception C0000005 in CPumpOutputThread; audio keeps playing but I must force-close Sonar. Happens even in a blank project with one SD3 instance and one MIDI track. Audio-only projects are fine. Tried: fresh RME HDSPe MADI FX driver/firmware, raised “Prepare Using” buffer — no change. Is this a known regression in 2025.09 with MIDI/SD3? Any workaround or should I roll back to 2025.08? I've attached dmp files. regards, Adam P.S. this was a nightmare for me today; I am a professional and my client was left waiting for probably 2 hours total in a full day of tracking; I was setting up drum loops for him to track acoustic guitar live, but, clearly, that was a massive headache with multiple crashes and super slow save times. I worked around it by bouncing out drum takes, but, even that was painfully slow going. Mystic Lady_09272025_135809.dmp Mystic Lady_09272025_135809.txt

I have tried everything in this post and not a single thing has worked. In previous versions, I could just change the filename to match the template file, as many have suggested, but, this does not work in the latest version of Cakewalk Sonar (2025.02). I wonder why they make this so difficult.

Thank you, @SteveC! Great that there is a dedicated menu for this feature now!

Hey all, I’m using Cakewalk Sonar 2025.02 (Build 31.02.0.049) and having an issue with GrooveClip looping. When I convert an audio clip, I get this stuttery, volume-pumping effect on each beat — sounds like some kind of automatic gain shaping per slice. In older versions of Cakewalk you could open up the loop slice view and directly edit or delete slices, adjust timing, and tweak per-slice gain. Now, I can’t seem to find any way to access or edit slice points or their settings. Has this feature been removed, hidden, or replaced with something else? I’ve checked AudioSnap and GrooveClip menus but don’t see any options related to slice editing. Anyone know how to work around this or if there’s a new method for editing GrooveClip slices? Thanks in advance! Adam

Update: the intermittent issue was still present in sessions created in the older Cakewalk by Bandlab software. All new sessions created on the latest version of Sonar don’t have the issue. Very relieved.

Thanks for the note, but just to clarify — the RME HDSPe MADI FX is indeed 24-bit at the hardware level, like most high-end interfaces. The 32-bit showing in the transport isn’t the converter resolution — it’s the recording format, which is 32-bit float. That’s pretty standard for modern DAWs and ASIO drivers, including with RME gear. It gives more headroom and avoids clipping issues in post, especially useful with complex routing or analog inserts. It’s not affecting the fidelity or the core conversion path at all — just a flexible internal format for processing and recording. No need to change it unless you’re working in a strict delivery environment or want smaller file sizes — otherwise, 32-bit float is actually preferred. Cheers, Adam