Noel Borthwick

Thanks for the information that's useful. I'll get in touch with them and sort it out. The information quoted is not quite correct however, so I'm clarifying in case some other VST developer reads this. We're not calling process to actually process audio. The VST3 SDK allows the host to call process to transfer parameter state to the plugin. In this case we are calling process using the documented workflow to transfer parameter changes. I'm quoting the FAQ from the VST3 spec below: The idea is that the process call is not only used for processing. Its also used to send parameter changes. When we load a project one of the things we do is set the default VST3 program change number. The u-he plugins expose this as a parameter so we set that parameter and then flush that parameter via the process call to notify the plugin of the state change. The plugin is mistakenly assuming that this is an audio processing call. Its not necessary to activate the plugin since audio processing has not yet started. I have had many discussions with Steinberg about this since it has been the source of innumerable problems where developers don't expect this behavior. IMO this part of the API is very non intuitive and a poor design choice since many developers do not expect this. Its also really poorly documented. FWIW the code in question I'm using to flush parameters came directly from the VST SDK so its not like it was my decision to do it this way In any case it seems like u-he is considering handling this. I'll touch base personally as well.

The crash is a null pointer access in the plugin. You should pass that on to them. Unhandled exception at 0x00007FFB6BC5AC4D (Presswerk(x64).vst3) in _05032021_201459.dmp: 0xC0000005: Access violation reading location 0x0000000000000000.

@muzdol You are running the 04 release right? The crash dialog looks different. Have you tried the build that I posted here and setting the ExceptionHandlingSeverity to 5? You can also set it to 1 and attempt inserting that synth.

We’re still collecting info and working on other fixes so it will be some more time.

We'll look into why frozen tracks aren't uploaded as audio. Thanks.

@Jacob Winkler do you have the high DPI setting enabled in preferences? If its not enabled there should be no change.

Hi @Art Munson The problem isn't solved its only masked and could happen anytime randomly. This is definitely a crash in the plugin. We got the plugin from the vendor and were able to reproduce the crash. We'll send the details to them to investigate on their end. Its a deep stack that shows the plugin crashing when we load its state. The exception happens always in the debugger for us. With the ExceptionHandlingSeverity set to 5 for us it wont crash (at least outside the debugger) but that is not guaranteed. This is the main reason why we are now flagging these intermittent crashes more deterministically to allow faults to be found and fixed. In this case only the plugin vendor can address the problem. The partial stack for the crash is as below. STACK_TEXT: 00000000`00148380 00007ffa`854111e9 : 00000000`00000000 00000000`00000000 00000000`00000000 00007ffa`00000000 : KERNELBASE!RaiseException+0x69 00000000`00148460 00007ffa`8541121b : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : clr!NakedThrowHelper2+0x9 00000000`00148490 00007ffa`85411225 : 00007ffa`2689e75b 00007ffa`26965300 00000000`250a1420 00000000`00000000 : clr!NakedThrowHelper_RspAligned+0x1e 00000000`001489b8 00007ffa`2689e75b : 00007ffa`26965300 00000000`250a1420 00000000`00000000 00007ffa`83e359c0 : clr!NakedThrowHelper_FixRsp+0x5 00000000`001496d0 00007ffa`85416824 : 00000000`00149d30 00000000`00000000 00000000`00149a10 00000000`00000000 : clr!CallDescrWorkerInternal+0x83 00000000`00149710 00007ffa`855874c2 : 00000000`00000000 00000000`00000000 00000000`00149900 00007ffa`26232a08 : clr!CallDescrWorkerWithHandler+0x4e 00000000`00149750 00007ffa`85587935 : 00007ffa`26232a08 00000000`254f46c8 00000000`00000000 00000000`00149a30 : clr!CallDescrWorkerReflectionWrapper+0x1a 00000000`001497a0 00007ffa`843ad884 : 00000000`0014c440 00000000`0014a0f0 00000000`250ae660 00007ffa`8439fe00 : clr!RuntimeMethodHandle::InvokeMethod+0x465 00000000`00149dc0 00007ffa`843c51f2 : 00000000`00000000 00000000`0014a340 00000000`00149f20 00000000`250ae0b8 : mscorlib_ni+0x59d884 00000000`00149e30 00007ffa`2658e15a : 00000000`254f41a8 00000000`0014a230 00000000`0014a500 00000000`0014a340 : mscorlib_ni+0x5b51f2 00000000`00149eb0 00007ffa`85416913 : 00000000`250ae0b8 00000000`250a2478 00000000`254f41a8 00000000`00000000 : 0x00007ffa`2658e15a 00000000`00149f00 00007ffa`85416824 : 00000000`0014a340 00000000`00000000 00000000`00000000 00000000`0014c1e8 : clr!CallDescrWorkerInternal+0x83 00000000`00149f40 00007ffa`85571b27 : 00000000`00000002 00000000`0014c1e8 00000000`0014a230 00000000`00000000 : clr!CallDescrWorkerWithHandler+0x4e 00000000`00149f80 00007ffa`854c09dc : 00000000`0014a340 00000000`0014a128 00000000`0014a448 00000000`0014c1e8 : clr!DispatchCallDebuggerWrapper+0x1f 00000000`00149fe0 00007ffa`854c1899 : 00000000`00000002 00000000`0014a128 00000000`0014a100 00000000`0014c1e8 : clr!DispatchCall+0x79 00000000`0014a0a0 00007ffa`854c3223 : 00000000`00000051 00000000`ffffffff 00000000`00000000 00000000`00000001 : clr!CrossDomainChannel::MarshalAndCall_Wrapper+0x33b 00000000`0014a3c0 00007ffa`854c132a : 00000000`00000000 00000000`132de490 00000000`00000000 00000000`0014a418 : clr!MakeCallWithAppDomainTransition+0xe8 00000000`0014a4b0 00007ffa`854c0d3f : 00000000`12c53430 00000000`12c53430 00000000`00000001 00000000`0014c440 : clr!CrossDomainChannel::MarshalAndCall+0x4e8 00000000`0014c230 00007ffa`854c0cd7 : 00000000`71000000 00000000`12c53430 00000000`00000002 00000000`0014c0dc : clr!CrossDomainChannel::ExecuteCrossDomainCall+0x50 00000000`0014c270 00007ffa`854c0ba5 : 00007ffa`25ff6ac8 00000000`00000000 00000000`254f3e30 00007ffa`83e35dd8 : clr!CrossDomainChannel::CheckCrossDomainCall+0xb7 00000000`0014c2a0 00007ffa`85414b25 : 00000000`1303d5a8 00007ffa`85414835 00000000`0014c2e0 00007ffa`85411028 : clr!TransparentProxyStubWorker+0xc5 00000000`0014c4a0 00007ffa`25ef76da : 00000000`250ae110 00000000`250a2430 00000000`25288a50 00007ffa`83e35dd8 : clr!TransparentProxyStub_CrossContext+0x55 ........ 00000000`0014cc00 00000001`4059d485 : 00000000`00000000 00000000`23f30d10 00000000`0014cd90 00000000`23f2e0c8 : Cakewalk!CPlugWrapper::call_dispatcher+0xaa 00000000`0014cc40 00000001`4058cd6e : 00000000`00000000 00000000`0014cd90 00000000`23f2e0c8 00007ffa`ea3a2980 : Cakewalk!CPlugWrapper::SetChunk+0x45 ...... ...... 00000000`0014f300 00000001`40f80753 : 00000001`41fd5610 00000001`40f80740 00000000`00000000 00000001`41baa290 : Cakewalk!CCakewalkApp::OpenDocumentFile+0x4cb

@Keith Lane details about capturing a hang dump are in my signature

Are you still using the realtek asio driver? Which version of Cakewalk are you running?

If it's exiting the app with that value set to 5 then the chances are that the same would occur in the previous release and it's a plugin bug. Are you sure this is a new issue?

@David Baay is that new to this release though? FWIW Im not seeing any issue with a punch region starting at time zero. The recorded clip is placed exactly at time zero. Please post a recipe if you are seeing it.

Hi Folks, Here is a new build that fixes the remaining sync issue with punch recording. Please try it and report back. If you can please test cases with normal record, loop record, punch record. With punch record also test combining it with loop record and try variations where the loop region intersects or fully encloses the punch region. Lots of permutations to test @Base 57 @David Baay @DeeringAmps @John Vere@giovannibuchelli

@Art Munson This crash isn't directly in the plugin. I'm making some changes to avoid some of these internal exceptions being caught. For now you can try the build I posted here and follow the instructions to disable the strict checking.

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