Noel Borthwick

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.

I don’t see why you shouldn’t be able to mix live inputs rather than recording. (Not being able to hear your mix through headphones in a live room is a different physical problem of course) While track volume affects the post FX gain, Input gain will affect the pre FX gain. If I understand what you want, you should be able to set the input gain levels to mix all your live input levels to what you want. Alternatively if you want to mix post FX use track volume. @David Baay Input gain does affect live inputs since its applied immediately after the inputs and pre fix bin. Take a look at the signal flowchart.

Which version of Cakewalk are you running?

An aux track is a patch point connected to the track input. Therefore aux tracks need to have monitoring enabled just like normal audio tracks. Please refer to the signal flow chart. PS: Please translate to english before posting if you want replies since this forum is in english.

Look at the crash dialog does it say the plugin crashed? If so you should send the dump to u-he. We're catching more crashes in plugins now so if the plugin does something bad it will be reported. Prior to this the application could randomly be shut down in this scenario. About loading in another daw, please read the faq on diagnosing crashes. Please also send a link to the dump and we can follow up with them if necessary.

Dropouts on opening projects are not something to worry about. Well look into masking these in a future update.

It was only done this week so it's after the EA. I run at 2K (1440p) at 100% scaling and didn't notice a difference until I changed the scale to 150%. Since it's new we didn't enable this by default so any feedback is useful.