Thomas Happ

I just had it happen to another track while editing a completely separate track. So I guess it has nothing to do with *what* I'm dragging or messing with, just as long as I'm dragging something. It says my engine load is only 15% and the performance bars on the top are nowhere near peak, but I'm not sure that is accurate given how far multithreaded CPUs have advanced since that UI was written.

Well I'm not dragging the note past the end of the loop point, but I'm dragging them while the playback is currently looping. This happens with any note size, though usually I'm using 1/16th - 1/4 notes. Or are you saying that if I drag the note *while* the current transport time loops? Because cakewalk plays the note as a preview, and then before I let go of the mouse, the cursor goes past the loop end, and forgets to clear it once I release the mouse click? In that case it would be solved if I could disable the feature where it previews a note when you click or create a new note, but I don't think there is a way to do that.

This is a problem I get with U-he Diva but I've occasionally gotten it with other plugins. Basically if I am playing back while creating and dragging around notes (I often am looping over a couple of measures while I do this, trying to find the right sound) it often seems to never receive the "note end" event and I have to stop playing in order to keep them from playing. It's very annoying. Does anyone know a workaround?

Just wanted to note that two days ago I got a Clarrett+ 4Pre. It's powered by an ac adapter, not the bus. No crashes or having to restart the interface so far, though there have been a couple of audio dropouts when I was just scrubbing around. I found out right away that the Clarrett+ interfaces don't have loopback, a feature I haven't wished for in a long time but I needed it yesterday; I plugged the spidf output into the input to get around that. Edit: Left Cakewalk open for a couple nights in a row and it finally crashed, but the interface did NOT crash. Pretty good eh? Also the spidf out is a handy way to connect to my home theater receiver that the Motu M4 lacks.

Well I guess it was a fluke that switching to 2.0 completely fixed it - it reduced the crashes by maybe 75%; it used to be that switching to a sampled drumkit in Punch was enough to crash it 100% of the time, but now it's more like 25% of the time, which is better, but still not fixed. Unfortunately this didn't fix it for me, either. I'm thinking I'll get a Clarrett + 2Pre and use the included power supply so it doesn't rely on bus power.

So last night cakewalk didn't crash for the first time in a while, which I'm chalking up to using USB 2.0 instead of 3.0. Possibly the MOTU drivers just weren't tested in that scenario, or maybe my specific computer's USB 3.0 hardware has some problem.

Holy cow, it really does need to be on 2.0 and NOT 3.0! At first I tried going from a blue 3.0 port to a teal 3.1 port, but same problem. Then I stuck it on the uncolored port (which appears to be intended for the mouse on my PC) and it works - at least for the easy test case of making it crash switching kits in Punch. We'll see what happens when I leave cakewalk open all night.

Thanks for that, it turns out that my firmware was indeed out of date, but updating it doesn't solve the problem. Or, maybe it solved part of it - I used to get an audio engine dropout warning whenever it crashed but now Cakewalk just continues playing but no sound comes out (and the meters on the front of the M4 are at 0).

I have it plugged into a USB 3 port because I figured more is better, but since this is a USB 2 device maybe that's causing an issue? I've disabled selective suspend but it didn't help. I really don't think it could be power management since the LCD is lit up it must be receiving enough.

Okay maybe I'll give that a shot. I've had it about 2 months. I should have returned it in 30 days but I hadn't been writing music for a couple of years so I took me a while to see a pattern to the crashes. Ironically I got windows 11 because it is supposed to make better use of the i9-12900K's many cores , but I do have suspicions that this tech could be a problem for MOTU and/or cakewalk.

As said in the title, my Motu 4x4 (or at least its drivers) keeps crashing. Basically it'll get an "Audio Engine Dropout" and then all sound stops working across the computer. Buffer size doesn't matter. Sometimes it will start working on its own again after a few minutes, other times I need to turn the interface off and on, other times I need to reboot the computer. I can trigger it most easily by loading up Rob Papen's Punch 2 and switching between kits with lots of samples, but it happens randomly at times as well, and I can't leave cakewalk open overnight or it will happen then. While it may be at least partially a Cakewalk issue as well as a Motu issue, I feel that an interface should be reliable enough not to get crashed by a DAW. Does anyone have recommendations for similar interfaces that are good but more reliable? I'd prefer not to have to get an RME since I feel like it is way more than I should spend, but I do want something that won't crash all the time. I'm on CBB version 2023.09 build 062, Windows 11, i9-12900K 3.19 GHz, 32 gb ram. EDIT: It appears the problem is reduced but not completely solved by plugging the M4 into a USB 2.0 rather than a USB 3.0 port.

Oh yeah, I did notice that. Oh! And one more thing - if do the Shift-M trick, and then use Undo, it sets everything back, except any notes that disappeared remain disappeared. So it seems that "Undo" doesn't truly save project state so much as perform the math in reverse. I've since gone and cleaned up the file so I'm reluctant to try and mess it up on purpose again. But I found also that this problem happens to the end of the clip - notes that I previously cropped out past the end of the clip by shortening it sometimes appear again as a tiny sliver at the end.

Thank you so much, this MOSTLY works, probably close enough for me. I discovered there seems to seems to be some kind of ordering or floating point error where the first note of some clips get cut off; they have the same starting time (in the interface) but it detects the note as starting outside the clip (before and after shown in these screenshots). I'm thinking that when it divided the start time in half the clip start ended some tiny fraction ahead of the note but so small it doesn't the time difference in the interface. The workaround is to stretch the clip slightly to the left, causing the note to reappear, and then put it back (with snapping on so it goes to exactly the measure start). Probably preaching to the choir I feel like this is really non-intuitive and there should be a checkbox or something next to the tempo to fix clips/events while you adjust it.

I have a project that I've been importing audio of various BPMs and changing the tempo to match. Somehow, I ended up with 190 bpm even though it should be 95 bpm. I *thought* that the way around this was to change the tempo, select all, then Process->Length and stretch Start Times and Durations by 50%, but when I do that, the midi notes seemingly stretch out of the clips - like the clips aren't following the notes and the notes go outside of them? Not only does it look bizarre but the notes no longer play. I provided before and after screenshots to show what I mean. I found that if I bounce all my clips and then stretch, it works, but I have lost all my careful linking of clips that I use to make sure when I change one, I change them all.

Thanks. It looks like in the case of ZebraHZ, but not Massive, using the vst2 instead of vst3 plugin doesn't populate the dropdown with nonsense, so it will be a while before I run out of space.