2021.04 Feedback

[X-53mph]

15 minutes ago, Teegarden said:

No clue about this temp file, but don't you have a regular system backup like EaseUS or Acronis that backs up your whole PC installation in an disk or partition image?

Each time I run into this kind of trouble I revert to a recent image from a time I'm sure everything worked and all problems are gone...

Alternatively you can try a registry restore if that has been switched on in Windows:

1. Search bar: type "system restore"
2. "Protection Settings" check under "available drives" if "Local Disk (C:) (System) protection is set to "on" (the configure button lets you set the amount of dis space that can be used for registry backups)
3. In case System Restore was already set to on: select "System Restore" button
4. Click "Next"
5. Choose a restore point from a date where you were sure everything worked fine
6. Click "Next"
7. Follow the instructions on-screen to finish the restoration

This is the moment when I look at my shoes, like a school boy being told off. ?

Edited May 6, 2021 by Philip G Hunt

[Štefan Gorej]

@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

Edited May 6, 2021 by Štefan Gorej
Additional information

[Czeslaw]

4 hours ago, Philip G Hunt said:

is there some way I can do a clean install of the build 2020.08 (which was the last truly stable version I had) or 2020.09 -

I've rolled back from 2021.14 to 2021.01, but when I try to roll back to earlier versions it corrupts my install and I have to uninstall and reinstall CbB build 2021.14 again. Help!

Hey! I have installer version 26.08.0.100, and apdate 26.08.0.120.

Upload to google drive?

Edited May 6, 2021 by Vyacheslav

[X-53mph]

2 minutes ago, Vyacheslav said:

Hey! I have installer version 26.08.0.100.

Upload to google drive?

Thanks for the offer - I got a copy from another member (infinite thanks).

[Andres Medina]

15 hours ago, msmcleod said:

It's not asking you to create a bundle file.

The cwp file is referencing audio files in the "D:\Bundle Files SONAR\Toy Cantando\Serie 2 Patita Lulu\0207 Balones Perdidos Piratas" directory. 

It can't find that directory, so it asks you if you want to create it.

Once it's created, it then (unsurprisingly) can't find the audio inside it.

Oh, my mistake then.

Thanks! 

 

[X-53mph]

15 hours ago, muzdol said:

Update: I contacted AAS team, and they sent me a hotfix in 1 day. (Great CS!)

But... Now i can not load even 1 instance of Lounge Lizard EP-4.

I deleted and re-install CbB several times.... I spent half of yesterday.

I hope this disaster will end soon, because LL EP-4 is my go-to Rhodes plugin..

 

Thanks.

I was having similar problems to you - I uninstalled all AAS instruments and reinstalled from an earlier installer.  Seems to be working now. There was def something wrong with the last AAS installer batch.

[Mark]

On 5/4/2021 at 11:17 PM, Mark said:

Hmm.  This happened on all three projects I set up that day.  Let me dig in, further.  My practice is to import all the new .wavs at 2:01:000 in the timeline (in case I need to slide left or right after importing), if that has any bearing on anything.

Thanks for following up, Jonathan.  I'll report back after some further investigation.

I'm on build 145 now, and today I had the same tempo-reversion issue that I reported earlier.  (And this behavior is new, as of 2021.04)

1. Create a new project using File | New and the basic template I always use
2. Input name, bpm, sample rate into the resulting dialog - the project opens in CbB (note that the tempo is as I assigned)
3. Save
4. Import all audio files via File | Import | Audio - tempo remains as I assigned
5. In track view, click (on the track number, just left of the track name and icon) to select one of the audio tracks ...

Note that now the tempo has reverted to 100 bpm.  Previously, I thought it was after I assigned the selected track to a track folder; but it actually happens as soon as I select a track in the interface. 

So, to correct, I:

1. Return the Now marker to 1:01:000
2. Reset the tempo to my original assignment
3. Re-save the project

Now the tempo "sticks" and is undisturbed when I start to work in Track View.

Of the four mix projects on which I experienced this behavior, three were from Dueling Mixes and today's was from pureMix.  I don't really think it's the audio files ...

--------------------------------------------------------------------------

Update 5/25/21 -- downloaded and installed 2021.04, build 175, perhaps a week ago.  This tempo-changing issue hasn't happened on the new build (and I've imported another 3 projects, since the new install).  Thanks, guys!

--------------------------------------------------------------------------

Edited May 25, 2021 by Mark

[muzdol]

7 hours ago, Philip G Hunt said:

I was having similar problems to you - I uninstalled all AAS instruments and reinstalled from an earlier installer.  Seems to be working now. There was def something wrong with the last AAS installer batch.

Thanks for your advice... But the problem is that.. how can i find older versions?

[chris.r]

16 minutes ago, muzdol said:

Thanks for your advice... But the problem is that.. how can i find older versions?

https://www.applied-acoustics.com/dl/

paste your serial to get in then click 'Show all Windows installers'

[muzdol]

4 minutes ago, chris.r said:

https://www.applied-acoustics.com/dl/

paste your serial to get in then click 'Show all Windows installers'

Wow.. Many thanks!! I'll try older version!

[muzdol]

7 hours ago, Philip G Hunt said:

I was having similar problems to you - I uninstalled all AAS instruments and reinstalled from an earlier installer.  Seems to be working now. There was def something wrong with the last AAS installer batch.

 

11 minutes ago, chris.r said:

https://www.applied-acoustics.com/dl/

paste your serial to get in then click 'Show all Windows installers'

 

It works!!

you guys saved me from massive disaster since my go-to rhodes plugin is AAS LL EP-4! (I heavily use rhodes when i compose)

Thanks!!!

[Noel Borthwick]

12 hours ago, Štefan Gorej said:

@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

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:
 

Quote

Q: Could the host call the process function without Audio buffers?
Yes, the host could call IAudioProcessor::process without buffers (numInputs and numOutputs are zeroed), in order to flush parameters (from host to Plug-in).

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.

[Skyline_UK]

Are there any lengths to which Noel will not go to in supporting us and aiming for perfection?  No is the resounding answer. ?

[Štefan Gorej]

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]

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 :-/ 

[Jack Barton]

 

Ever since I downloaded the update certain menus have become transparent and impossible to see. I've noticed this in particular when trying to add FX onto a track, or when selecting an instrument when adding an instrument track.

In some cases like in the second screenshot, the menu is visible on the far right of the screen, but it's still selected through the transparent menu box.

All my computer's drivers are up to date. Cakewalk is the only program this is manifesting in.

[Ben Staton]

@MrJackBarton

Thanks for the report. We've been doing some more work on plugin menus and will shortly be releasing another build which will hopefully resolve your issues. Stay tuned!

[user 905133]

12 hours ago, Ben Staton said:

Thanks for the report. We've been doing some more work on plugin menus and will shortly be releasing another build which will hopefully resolve your issues. Stay tuned!

@Ben Staton Any chance you could make the DX, VST2, VST3, 32-bit text designations use theme editor colors as in 2021.04 EA 1? 

Edited May 8, 2021 by User 905133
to fix a typo

[Noel Borthwick]

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.
 

[phased cloak]

I loaded a Bandlab project in Cakewalk and I noticed that the notes that I created in Bandlab didn't get transferred and appear in the Lyrics tab in Cakewalk.