Noel Borthwick

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.

The difference is seen in text rendering when you are running with display scaling set to something higher than 100% in Windows. Take a screenshot before and after the change and you will see the text rendered better if you zoom in. Fonts are rendered much crisper. But with some plugin's not optimized you may see some perf issues.

What resolution are you running at and what are your display scaling settings in Windows?

Thanks for the report but this thread is to report issues SPECIFIC to the early access release not preexisting issues. Please post it in the main forum.

No you can only publish the currently loaded project.

This is most likely heap corruption or an unhandled exception in the plugin. In our next update we have enhanced error checking so hopefully it should catch this crash and report it via the crash dialog.

Thanks for the report. This is fixed for the final release