Noel Borthwick

The thin installer doesn't touch registration of the instruments so its very unlikely. Esp if the OP upgraded from 2021.01

A tempo track is a standard feature in most modern DAW's. Can you explain what you are trying to do? The tempo inspector allows you to work in pretty much the same way as you would in the old tempo view.

MPC beats has preexisting stability issues that have been reported to AKAI. Until they fix this its not going to change. If you send a dump file for the hang I can verify its the same issue. You can also try disabling the strict exception handling in the build posted in this thread just in case its related (unlikely)

Did you try the fix I posted yesterday in the main feedback thread?

@Philip G HuntCan you share a link to the project files with us so we can follow up and troubleshoot?

A few: It highlights the peaks in the waveform envelope better Its quite common in some other DAW’s so there is an expectation of this It looks nice (to some) It’s optional

This is awesome. I wish more plugin developers were as responsive as this. Please let me know how it goes, This is the main point of the improved checking since it improves stability for everyone. BTW @Štefan Gorej did you try masking these errors with the new build I posted yet?

Are you sure this is related to the Cakewalk update? i.e have you verified by rolling back that this problem doesnt occur? Its more likely system related since we aren't seeing this problem.

@Steven de Jong Thanks for your report. Its likely sub optimal UI in Omnisphere. Many plugins do very inefficient drawing and depending on the video drivers this can lead to glitches in audio. This is why in my original message I mentioned UI performance. Ableton has a vastly different architecture for its application UI (a cross platform framework) so its not surprising that some problems you see here may not appear in that app. We have observed very similar behavior in another application we are developing. Unfortunately Windows is a crapshoot when it comes to balancing realtime workloads with a busy user interface, esp with all the variances in graphics API's and drivers. So if you remove Omnisphere (or close the UI) does the problem get significantly better?

I've posted a build that has a fix for this and a handful of other issues. Can you all of you affected please try this and report back? Please also verify that punch in recording and loop recording behaves as expected and that audio is aligned. @DeeringAmps @Base 57 @giovannibuchelli

@Štefan Gorej please try the build I posted above and set the ExceptionHandlingSeverity value to 5.

Hi folks, Thanks for all your feedback. There have been a few reports of record sync, some crashes on load and a few other cases. [Updated to fix punch record issue] Here is a new build 147 that should resolve these issues. We'd appreciate you trying this build if you are affected by any of these problems. Issues resolved: Recorded audio clips placed late on timeline by the ASIO record latency New Preferences | File | initialization file setting to control the sensitivity for error detection. 2020.01 has stricter error checking and as a result some projects with plugin's that internally cause errors errors may not open. You can work around this by adding the option ExceptionHandlingSeverity and set it to a value of 5. After restarting the application this may allow projects that crashed to open. (assuming they opened in a prior version) To go back to the default setting, delete this value (the actual default value is currently 7) Staff View not updating after nudging nodes Loading pre Tempo Track projects by default will not attempt to create envelope shapes from the tempo map. Track View no longer visible in Keyboard Shortcut category dropdown PRV Aim Assist line slightly off when left is scrolled beyond zero Tempo Node delete can delete selected clips

Thanks for the feedback. We'll review and make changes as necessary. PS: We had early access available for more than a week. We encourage users to try the early access since it allows us to get early feedback and make changes before we release.

@Štefan Gorej The stack is identical in the new one as well. You can roll back by following the instructions in the current release notes.

Hi guys, thanks for reporting this. I've identified the change that caused this and will fix it. Its caused because the latency offset is actually being applied twice in this case because of some obfuscated code that was doing this unexpectedly! I'll post a fix for you to test shortly.

@giovannibuchelli & @Patrick Bray I suspect this is a side effect of a different bug fix I did to solve an issue with virtual ports and aux track recording where punch in recording would be late. Can you confirm whether you are doing either punch in recording or loop recording, or if in your test it was just simple recording.

We’ll try and reproduce it thanks. BTW hardware MIDI ports dont have a unique signature in Windows so shuffling devices around lead to tracks getting assigned to different devices. They are just indexed hence its difficult to identify when devices are added and removed. There is really no easy way to get around this. We’ll look into your specific case and see if something can be done with templates. Also if you haven’t changed anything with your configuration the ports shouldn’t change.

@giovannibuchelli can you try rolling back to the prior release and check if this problem still occurs? You can easily reinstall or rollback. See this thread.

Thanks, we have no control over this - its all handled by Windows.

@DeeringAmps We'll investigate this. There were no changes made to recording this release. Which version were you running before you updated? Have you tried rolling back to verify if this is a new issue?

Hmm I stand corrected, I was confusing software inputs like patch points. We could consider allowing hardware input monitoring to be pre input gain but it could be tricky. Recorded audio should always be at the source level so it would sound different post record if we did that.

@Štefan Gorej I’m curious if you insert this plugin in a new project, change its settings, save as a new project and open it does it also crash? You can’t restore VST3 plugin state into a VST2 plugin unless the plugin supports it. Waves support going from VST2 to VST3 but most other vendors do not. I looked at your dump file. Its definitely a crash solely in the plugin caused by it accessing a null location. So the stricter error handling is doing its job in pointing this out and stopping execution. While bugs like this may have sometimes gone undetected in the past in some cases they could corrupt the memory state leading to all kinds of instability in the app. So its critical that issues like this are fixed in the plugins to avoid destabilizing the entire project. According to the dump I don't see Cakewalk loading the project in the stack so perhaps the crash occurred after the project loaded. Was it still loading the project when it crashed? Sometimes its hard to see from the dump since the data doesn't always accurately report the rest of the state. --- Unhandled exception at 0x00007FFC38DF5D64 (Presswerk(x64).vst3) in 2021-02-25_05012021_191305.dmp: 0xC0000005: Access violation reading location 0x0000000000000000. Presswerk_x64_+3d5d64 00007ffc`38df5d64 8b11 mov edx,dword ptr [rcx] EXCEPTION_RECORD: (.exr -1) ExceptionAddress: 00007ffc38df5d64 (Presswerk_x64_+0x00000000003d5d64) ExceptionCode: c0000005 (Access violation) Attempt to read from address 0000000000000000 DEFAULT_BUCKET_ID: NULL_POINTER_READ PROCESS_NAME: Cakewalk.exe ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s. FOLLOWUP_IP: Presswerk_x64_+3d5d64 00007ffc`38df5d64 8b11 mov edx,dword ptr [rcx]

Possibly related to your windows display settings if something changed there.

At 100% I didnt see a visible difference since the option affects display scaling.

What is your windows display scaling set to? If its > 100% then you should see an improvement. Let us know your findings. BTW is it one monitor or two physical monitors with spanning enabled? If so each monitor would have its own resolution irrespective of whether you are spanning.