billp

Is this what you are looking for?

Here's a screen cap. As soon as I click in the time line, the mouse pointer is locked in that range. The two toast messages don't show, both of which are audio engine dropouts (12) "[Internal] Internal audio buffer memory limit overflow." As soon as the second toast clears, the mouse is active again.

@msmcleod

The scrub tool always works fine in PRV. The problem is with track view. If you switch from PRV to track view with the mouse in scrub state, and click in the track view time line, it can freeze. About half the time, if you wait long enough, it recovers with a series of audio engine dropout messages, spaced several seconds apart. Otherwise you need to kill it. This has happened to me since at least v8.0 and with and without the standard MS mouse driver. 

The scrub tool does work in track view on audio tracks. A project with only audio seems not to have this problem. I find it happens only when I'm using VI's. Next time it happens I'll get a minidump.

It would be ideal if the mouse mode could be set to shift to some other tool mode when you switch from PRV/scrub to track view.

I thought this would be easy: just put each pair (input monitoring and record button) on each track into their own groups so that they toggle together. Tried it, but it locked up CbB and had to kill it from task manager. Maybe something to investigate.

I know this won't help you, but it happens to me too, being a heavy PRV user, particularly when I click on the timeline in track view. It is irritating, so irritating in fact, that I finally trained myself to hit the "S"(elect) key whenever I switch to track view...most of the time. Every time I think I should make a vid and submit it, but then I can't reproduce it.

15 minutes ago, Glenn Stanton said:

i would try out the Ozone to remove it (in the past when preprocessing files i would use Sound Forge to kill the DC offset and set levels etc). now i mainly use RX-7 to perform my preprocessing on files.

I have Ozone and RX 10. I ran it through Ozone just now and it doesn't detect an offset. It appears to be doing essentially what Will suggested above, i.e., applying a filter.

33 minutes ago, sjoens said:

FWIW, There are areas where Sonar/CbB has trouble displaying things graphically accurate, but I don't see that happening here.

Don't know if you can see it in the video, but I think you are right about the graphic accuracy. You have to watch this fully expanded to see the detail. Visually, the offset at the beginning doesn't change while the resolution goes between low and high. I think it should be magnifying the deviation from the center line when it goes to high res. Instead it just varies somewhat randomly. It's pretty small in any case and I suspect that only my dog is going to detect it.

Thanks Glenn. I did find this and eventually got it to work. My main concern was that an audio file that imported into Audacity (which I don't normally use), came in with no DC offset, but the same file imported into CbB had DC offset in the imported version.

I've since discovered that Ozone has a built-in filter for this. I haven't yet verified that it actually corrects it.

I'm actually starting to think that this could be a display issue. Check out the low res and hi res screenshots below. At hi res, the offset is almost not visible, but at low res there is a noticeable offset.

Low Res                    High Res

Thanks a lot Will. I'll try that. 

I'm definitely out of my depth here.

One of my collaborators told me that a wav that I sent him was reported by Logic Pro to have a DC offset problem. This project started with an AIFF generated by Logic that he sent me, and which I imported into CbB.

After digging into this a bit, I can see a very small discrepancy between the original AIFF file as imported into Audacity, which looks correct, versus the same file imported into CbB, where there is a slight negative(?) offset from the center line on the right side of the stereo image. The first two screenshots below are of the right side of the stereo image, one from Audacity and one from CbB. The left side does not show this same characteristic.

The third screenshot is of the wave file that I sent him, which I reimported into CbB. It has a more dramatic offset issue and on both sides of the stereo image.

I tried various things, like changing the import bit depth to 32, but it did not change the outcome. I also tried using the DC Offset correction tool in CbB, but it didn't have any effect on the original AIFF. It DID have an effect on the reimported wav. It corrected the DC offset on the left side, but added that offset to the right, so that the right side was even more offset.

My projects are all 24-bit/48K, if that makes a difference. My audio interface is a BF Pro. I'm using the latest rev of CbB.

I'd really appreciate it if anyone has some insight into this. I had to expand the screenshots to see the detail.

Look here:

If you have not recorded volume or any other automation attribute, then when you display the automation, it will always create a single straight line of automation set at the current level/value of the automated attribute.

In your case, as an example, if the volume is set at -INF, you will get an automation curve (line) at -INF when you first display the automation curve.

On 2/21/2022 at 5:11 AM, IgoRr said:

A friend of mine just wrote to me, he was trying to copy some MIDI tracks (clips) from one project to another (empty), when doing a Paste Special in a new project, and when specifying the destination "new track", the Cakewalk instantly crashes. I checked the same thing on my computer - everything is happening. If I perform the same Paste Special operation on existing tracks, everything works fine. He has Windows 10 installed, I have Windows 8.1 Pro x64. I have a mini dump file about this crash, I can send it if necessary.

Please check if this is happening to anyone else.

I'm having a similar problem, specifically (copy/paste special, although it doesn't matter whether it's a new or existing track) and frequent c0000005 errors in general just entering notes in PRV. They have always been frequent and are more frequent (like multiple within a couple of hours) with this latest release. They are usually the error shown in the image below and can occur in either Cakewalk.exe or the kernel.

My specs briefly:

• Win 10 Pro x64 
• i7 7820X octal @3.90Ghz
• 64GB memory
• Babyface Pro (ASIO/2048K buffer)

Th

On 2/21/2022 at 12:43 AM, GreenLight said:

If you right click, can you select Freeze from there instead?

Thanks for answering GL. All of the options on the popup menu, except the options, are disabled. There are two other libraries in the synth rack that are in same condition. I haven't found a common attribute that might account for this behavior though. All three unfreezables are Spitfire bespoke libraries, but I have other SF bespoke libraries in the project, one of which is frozen and one which has an enabled freeze button...so that's probably not the root cause.

I probably should have posted this here instead of in "Questions". I have a synth whose freeze button is inactive/disabled. The synth has midi data and an output track (see below) and plays just fine.  I'd like to freeze this guy as it's a bit of a resource hog:

I reported something like this a few months ago. I find that once I select any bus or main, the inspector will not switch to a midi track when I select it in the PRV until I go to track view and select either an audio or midi track (rather than a bus). These behaviors are probably due to the same fundamental problem. Wish I could offer you a solution.

There is midi data in the track and audio is produced.

I have a couple of synths whose freeze buttons are inactive. They are just typical VSTs, nothing special. Other synths in the project have normal freeze buttons and the freeze function appears to work. Is there a setting or some particular set of attributes that prevent a synth from being frozen?

I've written a few CALs. It's kind of like LISP and not for the faint at heart. I don't recall there being an array feature. 

I'm guessing you are in part changing the start times of the notes to "humanize" them. If it were a single line (with no keyswitches) a CAL script could maintain the overlap by lengthening an advanced note, and lengthening the note preceding a delayed note, both by the amount that you shift the "current" note, for notes that originally overlap. You wouldn't need an array for this. You'd need to save a reference to the modified note event when you move to the next one so you could refer back to it.

If you have keyswitches that need to precede or follow a note for hammer-ons, slides,  voice changes, etc. (like Ample guitars for example), you may need to correct those manually so that they move relative to the notes they are intended to affect. There would also be a much more complex issue with polyphonic passages where overlaps are all over the place.

I'm two-blocked now with other programming but if I get a chance, I'll try to do this.

This problem may have been identified and solved. See final couple of comments in this topic:

This is great news. I've sent several dumps to tech support, almost all resulting from copy/paste of midi.

So far that's proven to be a black hole.

I'm not sure what the proper protocol is for getting this issue resolved. As I expected Win update had no effect. I have several minidumps (and many more "poof it's gone" experiences) all pointing to Cakewalk.exe, all address exceptions. These seem to be occurring under a variety of circumstances, but very frequently copy/pasting midi in PRV, the latest when I had just opened the project, selected, copied and pasted. Although I've had my share of blowups over the last 20+ years, this has reached a new level.

My machine specs are in the original post.

I would really appreciate it if someone could point me in the right direction.

Thanks Mark.  It's been awaiting restart since early today. I'll give that a try.

Recently I've been plagued with address exceptions (c0000005d). They occur mainly in Cakewalk.exe but occasionally in the kernel. There is no particular sequence of events or project that causes them. They usually occur after a period of midi editing in the PRV. Since the crashes are happening so often, I've set the ErrorDetectionLevel to 7 and have been able to capture a few mini dumps when CbB doesn't just disappear, which also happens.

Does anyone have any suggestions on where I might look for self-induced problems?

Here's some background:

• Projects usually have 3-4 instances of Kontakt with a few VI's in each, between 10-20 midi tracks on average.
• CbB normally uses about half or two thirds of my 32GB of memory and maxes out at about 15-20% CPU per task manager when the projects play.
• I'm up to date on Windows updates, drivers, and firmware.
• Memory has been checked and is sound.
• Latency monitor has no complaints

Specs:
A nice little machine built by Jim Roseberry
Windows 10 Pro x64 Version 10.0.19042 Build 19042
Intel(R) Core(TM) i7-7820X CPU @ 3.60GHz, 8 Core(s), 16 Logical Processor(s)
32GB RAM
RME Babyface Pro @2048 buffer size

I'm using it successfully. Did you try using both the VST2 and VST3 versions? You may need to go to preferences > VST settings and uncheck "Hide related VST2 plug-ins" in order to see both.