>  Since Waves did not change their code and the bakers did
 
I note Waves has changed their code as V9r15 was released on Jan 6th 2014 and X3D was released 17th Dec 2013:
http://www.waves.com/downloads/release-notes

Was the issue apparent in V9r14? (I assume it was?).
 
You could test this by reverting to X3C or V9r14 or a combination of both, although to be honest even if you had definitive results it's still no smoking gun as software dependencies are not black and white, which sadly often confuses the end user, but it's something that could be reported that might be useful.
 
Anyway what Sander said...
 
Thanks

I did try it in a prior build of Waves. My buddy was not up to date, but I was. His code was 9.r12 when the problem first arose. As I stated, X3C works as expected with all Waves versions. X3D does not. That seems like a smoking gun to me. Right now, unless otherwise proven different, I think the issue is X3D. 

I have also notified Waves of this issue and waiting to see if I hear anything about it. If I do, I will feedback what I can. 

CakeAlexS
>  Since Waves did not change their code and the bakers did
 
I note Waves has changed their code as 9.1.5 was released on Jan 6th 2014 and X3D was released 17th Dec 2013:
http://www.waves.com/downloads/release-notes

Was the issue apparent in 9.1.4? (I assume it was?).
 
You could test this by reverting to X3C or 9.1.4 or a combination of both, although to be honest even if you had definitive results it's still no smoking gun as software dependencies are not black and white, which sadly often confuses the end user, but it's something that could be reported that might be useful.
 
Anyway what Sander said...
 
Thanks

Your versioning reference is incorrect Alex.
9r14 and 9r15 as noted in the waves link you shared.  ;)

Sanderxpander
There is no PuigChild DLL because Waves works with a shell. However, PuigChild's "about" screen shows me Waves version 9.1.0.9 Build 1363. Which is weird because I have WaveShell version 9.2.
But their versioning is just odd like that I think.
 
EDIT: Waves has had an update specifically to deal with Sonar compatibility which came out just after X3C, and they worked with Cakewalk to get that out. They only started supporting X3 from update C which is stated on this website. They have had a minor update out since, which (AFAIK) only updates their Waves Loudness Meter to a "better" version, which I didn't do. They also brought out one or two entirely new plugins which requires them to update their installer, but I don't think any other plugins were altered.

Yes, there is. It is in the plugin bundle folder.
 
I am not specifically aware of any SONAR update from Waves after X3C to support SONAR X3. I was told that X3C had a fix for the Waves settings issue. Can you elaborate?

I have edited the post (so they treat r's as decimal points), I see you got the point though.
 
> That seems like a smoking gun to me.
 
Conley, if I may be so bold, please let me give you a very basic example of dependencies.
 
The code for the plugin for instance could test for a version of Sonar and then execute different code to suit the version number of Sonar (note this just serves as example but actually we've recently seen an example of this). If the version number of Sonar is unknown to the plugin (i.e. a brand new release of X3D) it could revert to some unknown behaviour as it does not recognise the version. The issue would thus be in something that is hard coded in the plugin, to the end user it looks like something has gone wrong with Sonar when they installed a patch. BTW let me stress I'm not saying this is the issue, merely one example. Another example could be a programming library (such as C++) has been updated. BTW it's important to distinguish between DLL dependencies and coding dependencies although they are all related (it's just a reference to a library and an object in the developers eyes).
 
Unless you have both the source code of the plugin you or I will not know what is going on, and it's the same with Cakewalk because they (probably) don't have the plugin source code either unless they signed an NDA. The behaviour is happening to the plugin so whether it's Sonar code at fault or plugin code that is at fault, the developer of the third party code is the only one likely to find out what the specific issue is at code level.

Alex, Logic would preclude that something broke X3D if it works as expected in X3C. I understand code and release processing of code as well as regression of code. I am waiting for feedback still on my trouble ticket. I know Waves and Cakewalk have a good communication established and we shall get an answer on this soon I hope.
 
Let's just agree to wait and find out what the bakers or Waves confirms and let this thread breathe a little. ;)

Indeed... sure.

Guitarmech111
Alex, Logic would preclude that something broke X3D if it works as expected in X3C. I understand code and release processing of code as well as regression of code. I am waiting for feedback still on my trouble ticket. I know Waves and Cakewalk have a good communication established and we shall get an answer on this soon I hope.
Let's just agree to wait and find out what the bakers or Waves confirms and let this thread breathe a little. ;)

That logic is flawed. While it can be used as a thermometer for general troubleshooting, in the software world you cannot compare two different inter-operating components A and B and conclude that if a problem arises after a change in A it can be implied with certainty that the change in A is the root problem. In this case a change in A to add a new feature exposed a bug in B that causes the problem.
 
I have debugged this issue and the root problem is that the preset mechanism in several VST3 plugins is not fully implemented according to the VST3 spec. Presets can be changed in a bi-directional way - via the plugin UI or from the host UI. When the host sends a preset change request the plugin should change its preset and update its UI and internal state. Conversely when a preset is changed from the plugin UI it is up to the plugin to send a notification to the host to allow it to sync up its state and UI to the plugin. What is broken here is that the plugin's are not sending the notification back to SONAR and this puts it out of sync. Now when you save the project we save the state that SONAR knows about which is incorrect and when you load it back you get the incorrect state that you are seeing.
 
In the case of Waves plugins it appears that they never update the current program state when it is changed from their internal UI. I have reported this to their engineering team for review.
In the case of DMG plugins they do update the current state, but never notify the app so we don't know it was changed.
I have passed on information to both DMG and Waves about how to send back a preset change notification to the host.
See the section on Bi-Directional setting of programs here. 
 
Additionally I have added some failsafe code for the next update to prevent settings being lost even if the preset is out of sync (the UI will display the wrong preset name but the plugin state will always be intact when you load a project). I've also added code to make the bidirectional communication work using a different method. This also translates to VST2 so its nice that VST2 plugins will also stay in sync when presets are changed from the plugin UI.

Noel, should we or should we not rescan, reset and reinstall all our plugins?
 
CakeAlexS' three R's.
 
I keed I keed.

 
Don't worry it's just an alarm clock!