-
Posts
10 -
Joined
-
Last visited
Reputation
8 NeutralRecent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
Based on my actual experience, it looks like the new Sonar is still somehow less stable than CbB running on the same computer. In my particular case lot of projects I did in CbB are unable to load in the new Sonar (crash to desktop on project loading) while these .cwp projects do load ok into CbB. What I've already found it's related to some specific VSTs. In my scenarios, if there are some instances of U-he Hive 2.1 (vst3), the project simply doesn't load into new Sonar, but loads into CbB without any issue. If I create a new project using Hive 2 in the new Sonar and save it, then I'm unable to open it in Sonar, but I can still open it in CbB. When I open these projects in CbB, then disable all the Hive 2 instances in SynthRack, then I can open the project in the new Sonar. Then I can re-enable Hives in SynthRack and continue to work in Sonar. Before saving, I have to disable all the Hives again to be able to reopen project in Sonar. No issues in CbB. So this is probably caused by some changes in VST instances initialization (on project load) in the new Sonar, in combination with some SPECIFIC VSTs. Otherwise I like the new Sonar very much, EXCEPT of this new "feature" that needs to be fIxed ASAP on Cakewalk side. It really ruins my workflow! I can provide minidumps and Windows event log details to some responsible persons, if needed...
-
Thanks for clarification, @Noel Borthwick. It makes sense to me for 100 %. As a software developer / architect for 20+ years, I fully understand these pains and frustrations, that lead from badly designed and/or documented abstraction, APIs especially, enabling developer thing about multiple interpretations of it, not asking the author in many cases. I'm sure that u-he fully understood where the preblem is rooted and fixed this (what is the most important step at this particular moment), even thouht calling it a workaround. ?
-
@Noel Borthwick , I've just received some finding from u-he developers / support, that may be interesting. They believe that this is caused by DAW, specifically the order of calls to plugin from DAW on project load (see below). Thomas from u-he kindly asked me to pass this information to you, hence he has no direct contact to you: "The crash in the u-he VST3 effect plugins happens because the plugin's "process" call is called by the host before calling "setActive", which causes it to be uninitialized. This only happens when loading a project. When you instantiate a plugin manually, Cakewalk will call "setActive" before "process", so everything is fine in that situation. We are pretty sure that the host should call "setActive" before the plugin's "process" call, also when a project is being loaded." This perfectly matches my own observations. If you need more info, he recommends to contact him directly, believing that you still have his email address (or to support@u-he.com if you don't). EDIT: They also did some workaround on their side (within plugins), that should avoid these specific crashes and will be abailable through their next plugin updates. Still believing that root cause is in DAW, see above. Thank you, Stefan
-
@Noel Borthwick I can confirm, that with the provided Cakewalk build 27.04.0.145 and ExceptionHandlingSeverity set to 5, Project with VST3 version of Presswek loads successfully, so no exception caught by Cakewalk. I'll also try beta builds of u-he VST3 plugins without ExceptionHandlingSeverity and confirm (also to u-he) if the've fixed this issue on their side or not yet. Thanks for your assistance, Stefan EDIT: I also tried loading a Cakewalk project with VST3 version of Press werk after updated to Presswek latest beta 1.1.4.11152. When ExceptionHandlingSeverity is not set the Presswerk still causes Cakewalk to crash. So new build of their VST3 doesn't solve this issue. Minidump file attached. _05032021_201459.zip
-
@Noel Borthwick I've already received answer from u-he (they are really quick). They're preparing a new version of Presswerk that should solve these issues. I'm going to test their new non-public beta build today evening with Cakewalk, so I'll let know both them and here.
-
@Noel Borthwick, thanks for your reply. I've updated my crucial projects using VST2 u-he plugins, so no need to roll back anymore (I also like new features of current Cakewalk build). I've reported these crashes to u-he support as well, with explanation and with direct link to my post here (so they can download the memory dump). So hope they can and will fix this on their side. As a side effect, replacing Presswerk and Satin with VST2 alternatives in my projects allowed me to create better mix (we all are still learning)! ? Thanks again, Stefan
-
@Noel Borthwick, the dump file, that I sent in my previous post, was from my "experiment" with .FXC chain loading to already opened Cakewalk project. I'm sending the dump that came from crash during Cakewalk project load. Exact steps were as follows: 1. I created a new, completely empty project, added one bus track 2. Added an instance of Presswerk VST3 to FX slot of this bus, switched the FX chain and the plugin itself 3. Opened the plugin window to ensure that it's successfully loaded and initialized 4. Saved the project as a new .CWP 5. Exited Cakewalk and started it again 6. Loaded .CWP project saved in step 4 => Crash on Presswek VST3, dump file from this cras is attached. So, as I experimented, plugin crashes in this two scenarios: a) When loading .CWP project that already contains Presswerk or Satin VST3 b) When loading FX Chain that contains Presswerk or Satin VST3 into already opened Cakewalk project I also tried following scenario: 1. Created empty .CWP project 2. Added Presswerk VST3 plugin instance 3. Loaded existing preset into it using CAKEWALK PRESET functionality (.vstpreset file) This scenario was successfull, without crash, all parameters values from VST preset loaded successfully into existing plugin. See my attachments. Hope this may help to better understand my specific problem. Thank you, Stefan _05022021_093720.zipPresswerk.vstpreset EDIT: Btw. How to roll back to previous Cakewalk build to be able to load my projects and manually note Presswerk and Satin values to be able to manualy set them the same way in VST2 plugin instances (until solved in software)? _05022021_093720.zip
-
@Noel Borthwick Thanks for your reply. Yes, Cakewalk reported the crash of VST plugin, as you assumed (see my screenshot). As I already mentioned, previous versions of Cakewalk (including the latest preview) did't reported this, started right with this new update. I didn't observe any misbehavior of these plugins within previous Cakewalk versions, but as you stated, it doesn't mean that there were no issues. I also don't observe any problem with these plugins in other hosts / daws, so maybe specific combination of these u-he fx vst3s and Cakewalk? Maybe something specific about how DAW feeds state data to plugin during it's initialization? Anyway, I'm also attaching the minidump file, unfortunatelly, I'm unable to analyze it by myself. I'll also send it to u-he with specific info on DAW (Cakewalk version), so they can analyze this scenarios. From my point of view, it looks like there is some issue with plugin instance state "deserialization" during plugin initialization phase? I also tried this: - Uninstalled VST3 version of Presswerk from my PC (actually moved .vst3 files out of the vst3 folder). - Loaded Cakewalk project containing this plugin into DAW (project did load successfully, with plugin instances placeholders). - I saved FX chain state to fxc file (also attached - FX1.zip), assuming it will save also the plugins state. - Re-installed VST3 files of presswerk while Cakewalk still running, rescanned VSTs, checked Presswek (VST3) is present and enabled). - Loaded FXC file back into bus - it also caused crash of Presswerk VST3 plugin, caught by Cakewalk. Question: Is there anyhow possible for me to restore plugin instance state stored within existing cakewalk project, so I can set parameters of the VST2 instance of this plugin with exactly same values? Unfortunatelly I didn't same the plugin state as standalone preset and I want to try restore Presswerk and Satin settings using VST2 instances. Thank you, Noel, and wish you all the best. 2021-02-25_05012021_191305.dmp.zip FX1.zip
-
The latest version of Cakewalk crashes everytime during load of a project with u-he Presswerk or Sating (both the latest available versions) in FX slots. With previous Cakewal beta / preview everything worked fine. Crash occurs on project load and only with VST3 versions of plugins. When I use VST2 versions, projects load without crash. I also tried to create new project with these plugins - successfully added these VST3 plugins, everything works, project successfully saved, but anly project load attempt causes crash every single try. Other VST3 plugins don't cause crash on project load. In other DAW (Studio One) projects with these VST3 pugins also load correctly. Actually I'm unable to load my recent Cakewalk work where I use these u-he VST3 plugins. I can provide minidump files from cakewalk. I love other improvements anyway! Great work and keep going.