Noel Borthwick [Cakewalk]

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.

You guys are pretty cool, I know plenty of developers who would just send an email to the third party and tell them to fix it without much explanation at this point (maybe just point the object call or something), let alone attempt to debug it from the back end or put in preventative code. Thanks for the detail.

No but you need to sacrifice a chicken exactly while scanning that plugin :)
 

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

Noel Borthwick [Cakewalk]

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.

Thanks for the clarification Noel! I look forward to the next patch.
 
I did not see a direct answer that  addressed the X3C worked with all the tested versions I had and X3D didn't work. I am glad that there will be an additional layer of checking though. I have also reported it to Waves.
Thanks again for your time and nailing down this issue!

I had communication with the Waves people during X3B and those issues, they followed up with an email after X3C released, saying they had a new installer/version out that was now officially compatible with Sonar. Consequently, they updated their compatibility list to include X3C. So that's where I got that info.

I didn't realize there was a DLL inside the bundle file, never thought to open it.
Anyway, my real question was if you can reproduce your error (which as you indicated earlier is NOT just the Sonar menu thing) with a plugin that's in the Horizon bundle. E.g. all of Renaissance and the oldies, either of the Riders, one of the mastering or restoration tools, Kramer stuff, V-Series, vintage compressors...?

Guitarmech111
Thanks for the clarification Noel! I look forward to the next patch.
I did not see a direct answer that  addressed the X3C worked with all the tested versions I had and X3D didn't work. I am glad that there will be an additional layer of checking though. I have also reported it to Waves.
Thanks again for your time and nailing down this issue!

The direct answer was in the first paragraph. X3D implemented full support for VST3 factory preset management which is a new feature that didn't exist in X3C. When we did that it exposed problems with bi-directional support with some VST3 plugins.
I have already reported the issue to Waves with full details. Keep in mind that the workaround in SONAR will prevent the wrong settings being loaded but won't fix the problem with preset changes in the plugin not updating the host. So the preset picker will be out of sync until that is fixed from the plugin side.

 

Noel Borthwick [Cakewalk]

Guitarmech111
Thanks for the clarification Noel! I look forward to the next patch.
I did not see a direct answer that  addressed the X3C worked with all the tested versions I had and X3D didn't work. I am glad that there will be an additional layer of checking though. I have also reported it to Waves.
Thanks again for your time and nailing down this issue!

The direct answer was in the first paragraph. X3D implemented full support for VST3 factory preset management which is a new feature that didn't exist in X3C. When we did that it exposed problems with bi-directional support with some VST3 plugins.
I have already reported the issue to Waves with full details. Keep in mind that the workaround in SONAR will prevent the wrong settings being loaded but won't fix the problem with preset changes in the plugin not updating the host. So the preset picker will be out of sync until that is fixed from the plugin side.

I get it now. This response is much clearer. X3D had FULL VST3 presets support and X3C did not. That was not explicit in your first paragraph, but clear now.
THAT is the answer I was waiting for and happy to support. 
 
Thanks Noel!

So this is in fact the error you're seeing? If you're staying away from the Sonar presets menu it works fine?

It is the error I documented. ;)
 
Originally when opening a saved project, the settings were not showing up as saved with the project. I opened the project on my machine using X3C from my buddies X3D machine. I don't know for sure that he saved a preset, I seriously doubt it, but the settings opened as expected on mine and not his (without saving presets on his machine we could not get his desired results in a quick fashion). I only created the presets after we ran into this issue and that is what I could readily produce.

Since we know what the issue is, I am ok with where the issue is going. I am glad someone has a good handle on it at the bakers and the plugin manufacturers.

Dependencies...
 
> Since we know what the issue is, I am ok with where the issue is going. I am glad someone has a good handle on it at the bakers and the plugin manufacturers.
 
Excellent!