Noel Borthwick

Perhaps you should contact iZotope about performance issues with their plugins. We can't solve those.

@Thomas Roller Where did you get this information from EastWest?

John ASIO is not an option when using USB input only devices. It should be fine to use WASAPI in this scenario. If there is a problem we need to fix it not work around it.

@immrama technically the issue is masked Only Motu would be able to actually fix the underlying problem which was flagged with the higher ExceptionHandlingSeverity. But its good that the problem is resolved for you.

@Fabio Rubato please try the build we posted yesterday that has relaxed some of the error checking. This should resolve your issue if it worked in the prior release. This doesnt fix the crash which is in the iZotope code but will mask the error most likely. You should send them the dump file for them to analyze. Insight crash: Unhandled exception at 0x00007FFA685E5AD1 (kernel32.dll) in Untitled_05062021_154914.dmp: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF. > kernel32.dll!IsBadReadPtr() Unknown Non-user code. Symbols loaded. [Frames may be missing, no binary loaded for iZInsight.dll] Annotated Frame iZInsight.dll!000000003892251a() Unknown Non-user code. No matching binary found. The waves error is also similar. I will pass this on to them for debugging. Unhandled exception at 0x00007FFA685E5AD1 (kernel32.dll) in Untitled_05062021_155320.dmp: 0xC0000005: Access violation reading location 0x0000000000000130. > kernel32.dll!IsBadReadPtr() Unknown Non-user code. Symbols loaded. [Frames may be missing, no binary loaded for WavesLib3.105_10.0_Win64.dll] Annotated Frame WavesLib3.105_10.0_Win64.dll!00007ffa23d27335() Unknown Non-user code. No matching binary found.

@M CTo clarify, in WASAPI shared you can use a completely different audio device as input from the audio output device. This is one of the advantages of WASAPI mode. However we don’t support using multiple different output devices at the same time. Let me know what specific combinations are not allowed. If you post a screenshot of your audio settings it will be clearer.

@DescendingIntoVertigo while that is a legitimate crash please try the new version scook linked to. The 2021.01 release had better crash detection and its possible that it is catching issues that you may not have seen earlier. In Update 1 I have changed this to be opt in so some issues may not get reported. Let me know if this changes anything.

@Nilo777 we’ll have to work with you collect some information. Ben has sent you a PM so please follow up since we need to understand what is different on your system leading to this issue. You can also run MSINFO32 and collect a log of your system configuration and send it to us.

The FXRack menus use similar UI to the arranger so that part is not surprising. Did you report this issue previously? Anything customized differently in Windows with fonts etc that you are aware of? Finally have you tried the early access update 1 build posted today yet?

Hi @Nilo777 what language are you using and what version of Windows are you running?

Thanks for reporting it. Yes the notes were not being read properly. Its fixed for the main release now. Note that these are the project notes read from the revision description and Not the lyrics from within the revision editor itself. While I can read the lyrics in BandLab, they are stored at the song level unlike Cakewalk that stores lyrics at the track level. So there is no easy way to map lyrics going back and forth.

The latest early access build should fix the menu display issues

Which module was crashing can you send the crash dump?

Thanks to @David Baay for helping isolate the punch issues. We have fixed all reported issues in the early access Update 1 released today. We'd appreciate anyone who had the punch and record compensation issues to retest and check if they are solved.

Try this build that we posted. Post feedback in the main 2021.04 feedback thread instead of making new threads.

Please try the latest early access Update 1 preview that we posted and report back. Please post feedback in the main 2021.04 comments thread instead of making new threads.

Did you open the project or Import it? The notes are transferred to the Project Info that you can find in the Browser. Not lyrics - notes are not lyrics.

Hi all, We just posted a early access build for 2021 Update 1 that we plan to release next week. We'd appreciate it if you could try this build and let us know if it fixes any of the listed issues you may have encountered. Thanks for all your help in reporting issues.

Well everything is a workaround depending on who’s perspective it is :) The whole idea of parameter changes being tightly coupled with the process call is a terrible design that leads to problems like this. In VST2 there was no such dependency. While it makes sense to send parameter queues during the process call there should have been a clean independent API to set parameters independent of processing. Instead they hacked that into a “dummy” process call. This is why so many issues arise. I had crashes from day one where plugins were crashing when we passed null pointers even though the spec says its OK to do that. In fact I asked Steinberg to add this as a unit test to their VST3 plugin validator, but of course many developers don’t test with that :-/

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.