Noel Borthwick

Yes there are plans for MIDI. Taking raw MIDI across is relatively easy but clearly preserving any sonic compatibility if the MIDI is triggering synths is problematic since BandLab has built in instruments and in CbB you could be running any number of VST instruments.

"Please be aware that should you continue to use the discontinued version(s), you may be at risk of potential claims of infringement by third parties.”" This sounds to me that there is some legal issue with older versions and they are essentially washing their hands off the liability. I doubt anything would happen to actual consumers using old versions they bought but you never know with patent trolls.

Correct but the user should still have access to command center and be able to download the last shipped version of Session Drummer. I updated my post to avoid confusion.

Crashes in the VC runtimes doesn't mean the VC redist is at fault. Its normal for an operation from the C runtimes to be shown in the crash if the crash site is in that function. In this case its crashing in a memory copy function. That doesn't mean the bug is in that function specifically but that there is a faulty memory copy or that data is being overwritten.

Hi @Shaade your dump file shows the crash was caused by a memory overwrite in Session drummer x64.dll and not in Cakewalk itself. Also you are running a really old version of Session Drummer dating back to 2009 and not the last version that was shipped with SONAR. The version you have is: SessionDrummer x64.dll *c:\program files\Cakewalk\vstplugins\Session Drummer 3\SessionDrummer x64.dll 1.00.0.222 12/3/2009 2:20 AM Please update to the latest from Command Center (you should still have access to this if you had SONAR earlier) since this is likely the root cause of your issues. Let us know if it resolves your issue. The current version is as shown in my screenshot.

Can you please send me the minidump file for the crash so we can investigate?

Please send me the minidump. The path should normally be shown when the crash occurs. If it's crashing inside Cakewalk we can normally see what operation causes it.

If you share a link to the project file or the minidump file we can take a look.

It's been double fixed I think you may see a fix from our end sooner however. I assume you are talking about the issue with MIDI analysis hanging Cakewalk and creating region effects sometimes skipping analysis. Thats what I am referring to. Any other fixes would have to come from Celemony.

Thats the same issue that @Detwoen had and has been fixed some time ago. It will be in the next update.

Not sure its the same. Yours was related to opening the normal template correct? That has indeed been fixed. The OP's issue is with a specific project file.

Yes please send a link so we can look at it.

@smoddelm if you have a copy of the problem project could you send us a link to download it and take a look?

Hi @David A. White I'd be surprised if the metronome had anything to do with it since many use a count in while recording. As Jon asked what happens if you have the audio metronome selected but turn off the metronome count-in on recording? Do you have a different audio interface by any chance to try? We no longer have any TASCAM gear to test with.

Send me a link to the project file and I'll see if it gets modified for me. BTW make sure you are running the latest release version since there was a bug fixed in the last release relating to this.

I think the conversion happens once per file and then stays in a memory cache. I believe we cache upto 16 previews after which it will import again. The files are created whenever the source format is not native such as a different sample rate or a non wav file such as MP3. The temp files should be destroyed when the project is closed. Regarding the sample rate conversion popups on closing, thats some unintended stuff happening when closing the preview files. We can look into preventing that.

Keep in mind that changing to offset mode itself doesn't change the existing mix in any way so there is no data loss. All it does is configure the mixer so that the gain controls now affect an "offset" gain stage on top of any existing levels you have. All offset gains starts out at unity so it will not affect your mix at all until you change something. Iow the normal gain staging and envelopes all stay intact. Offset mode is typically used to fine tune an existing mix which already has automation.

Does it really sound like it is zeroed out or do the faders just look that way? The offset mode tip is a possibility. See if the volume values have a + next to them.

That is correct

To clarify, it has nothing to do with the edit filter showing Clip Gain. The problem is the way you were selecting data. You were selecting the ENVELOPE and not the clip and that caused the issue. As long as you click on the clip to select it before bouncing it makes no difference if the edit filter is showing clip gain. The keyboard shortcut will be automatically blocked since I'm disabling the command itself when there isn't a proper selection. In the problem case its really not doing a bounce to clip so the length is the track length. The change will be in the next release...

Man you guys sure find obscure weird cases The problem only happens if you right click to select AND then choose the bounce to clip operation from the top level menu. The issue is that right click selection is selecting envelope nodes and not the clip itself. The bounce to clip operation should not be allowed in the UI under that state but it was not grayed out in the menu. When the command executes because no clip is actually selected it gets confused and ends up doing some default operation. I've fixed it so that a bounce is disallowed in this case. You should click on a clip to select it or do any kind of normal selection (not right click selection) before doing a bounce. FWIW right clicking a clip and choosing bounce to clip from the clips menu automatically selects the clip so most users would never see this issue.

For the person with the rdas1089 listed in the crash thats the Roland driver crashing and there may be a compatibility issue causing it. We don't have any way of addressing driver crashes unfortunately. If you send share a link to the minidump from the crash I may be able to see what operation is causing the crash. For Larry, are you still crashing after updating Cakewalk? If so if you share your minidump file it may throw more light on the nature of the crash or if its caused by a system related problem like what msmcleod suggested.

Correct, the metronome is disabled during all bounce operations so the only way to capture it today is by recording it via an aux track.

The first thing I would try for troubleshooting is to Restart your PC, then launch Cakewalk and create a new project with the blank template. Add a single audio track arm it and try and record. Does recording work? If not there is some instability with audio on the system. Also make sure you have ASIO selected assuming you have an ASIO driver. If you are still having issues we can certainly help troubleshoot it.

I've been working closely with Celemony to get to the bottom of some of the instability with detection not being triggered in CbB. We believe its fixed - Using a test build from them I can't repro the issue where it would hang on MIDI detection or not detect blobs after creating a region effect. I can't speak for release schedules but I believe good news is on the horizon. As to why it could appear to be fixed without any changes from us, this could be because race conditions behave in unpredictable ways. A subtle change in the timing of operations can mask the issue. This is likely why this issue has lingered on so long because it was hard to repro for some people.