I have a problem with a particular VST3 plugin

A small update to mention I can reproduce the scenario with the Monster Drums plugin from the same developer. This would have me think these plugins share some trait exposing them to this scenario.
OK, so can I reproduce it with Carla? In order to find out, I loaded the same 2 plugins into Carla 2.5.8. Carla sees each of these VST3s as "native" since yabridge is workingi its magic. Both plugins loaded fine, were usable, and I was able to save the Carla session to /tmp/carla-test.carxp and use that file to reload both plugins after restarting Carla.
I did see something of interest in Carla's log though....
======= Starting engine =======
======= Engine started ========
Carla engine started, details:
Driver name: JACK
Sample rate: 44100
Process mode: Multi client
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] Initializing yabridge version 5.1.0
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] library: '/home/windowsrefund/.local/share/yabridge/libyabridge-vst3.so'
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] host: '/home/windowsrefund/.local/share/yabridge/yabridge-host.exe'
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] plugin: '/home/windowsrefund/.vst3/win/MONSTER Drum v3-2022.07.vst3'
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] plugin type: 'VST3'
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] realtime: 'yes'
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] sockets: '/run/user/1000/yabridge-MONSTER Drum v3-2022.07-0LWhkmvw'
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] wine prefix: '<default>'
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] wine version: '9.13 (Staging)'
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw]
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] config from: '<defaults>'
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] hosting mode: 'individually, 64-bit'
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] other options: '<none>'
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw]
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] Enabled features:
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] - bitbridge support
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] - CLAP support
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] - VST3 support
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw]
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] [Wine STDERR] 002c:fixme:winediag:loader_init wine-staging 9.13 is a testing version containing experimental patches.
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] [Wine STDERR] 002c:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org.
23:08:18 [MONSTER Drum v3-2022.07-0LWhkmvw] [Wine STDERR] Initializing yabridge host version 5.1.0
23:08:18 [MONSTER Drum v3-2022.07-0LWhkmvw] [Wine STDERR] Preparing to load VST3 plugin at '/home/windowsrefund/.vst3/win/MONSTER Drum v3-2022.07.vst3'
23:08:18 [MONSTER Drum v3-2022.07-0LWhkmvw] [Wine STDERR] Finished initializing '/home/windowsrefund/.vst3/win/MONSTER Drum v3-2022.07.vst3'
JUCE Assertion failure in juce_VST3PluginFormat.cpp:3636

Honestly, I don't grok why Carla is reporting the file as being loaded from ~/.vst/win given the fact it is reported as "Native" so I'll chalk that down as some type of symlinkish thing I'm not going to worry about. So maybe Carla is handling JUCE raising some sort of exception where Qtractor isn't? I don't know.
Again, given what I think I know about these MONSTER plugins, I'd be willing to bet they're not entirely compliant with these vst standards? As such, I'm certainly not expecting much but I'm hoping to be pleasantly surprised if the underlying issue is something simple.
All the best

Going to recompile with this update and will report back.

No change.
That said, I've also noticed another odd behavior with these plugins where the correct patch isn't being loaded despite the appropriate config node existing in the .qtr fiile. Is anyone interested in trying to reproduce any of this on their end? If so, I'd be more than happy to share the exact steps taken to get yabridge working with Qtractor.

I am really happy to report I've discovered something in the sense of a root cause :)
On a hunch, I checked out and recompiled this commit. Now, this particular VST3 plugin's patch is persisted as I'd expect. Interestingly enough, some parameters do not persist (global volume) but others do. That curiosity aside, being able to persist patch selection is obviously fundamental so this is a win.
It does not solve the other IOT instruction crash I reported but I work around that by ensuring I disable the plugin before I save and exit Qtractor. I use automation to activate it before the part plays so this is fine.
So basically, 55c7d1335c34d10ebd76733c679d248af567e860 is the commit that introduced the inability to persist patches from this author. The odd thing is, other VST3 plugins I have do not appear to be impacted in this fashion which is why I mentioned what I knew about these MONSTER plugins and how the author seems to develop them in what I deems as "a very strange way". In other words, they are clearly not "standard" in as much as that word actually means anything. I also have a suspicion the "developer" would have no idea as he says there is no source code.............. uhm, yea.

Never mind. I thought I had made some progress but it does look like the previously mentioned commit is in play in terms of a root cause.

Rui,
Any chance 55c7d1335c34d10ebd76733c679d248af567e860 can be reverted?
All the best

Couldn't you cherry pick the newer commits into a new release? Unless I'm wrong, VST3s are unable to persist their state now? Actually, that's not a fair statement as I've only been talking about these particular MONSTER plugins. That said, the commit in question may be impacting other plugins that I wouldn't know about.

Let me try a different angle then. Would you mind seeing if you could reproduce what I've reported against this plugin? It's the smallest of all the plugins by that developer and I'd be able to share any information about how to setup yabridge and/or wine if needed. (though I suspect you already know).

OK, I'm going to make a few points here.

1. This has nothing to do with any interest in toy sounds. Out of all these MONSTER plugins, this is the smallest plugin in terms of size. I didn't even know about the particular plugin (because I actually have no need for it in my music) but for good reason, the main yabridge developer has been looking into a related issue here when I asked for help looking at this from the perspective of yabridge. In other words, it's the most practical of all the plugins to use for troubleshooting. IMHO, you, as a developer, shouldn't have needed me to explain all this and choosing to attack the "legitimacy" of the plugin's musical purpose, rather than focus on the real issue is childish and lazy. One could easily argue the 2 plugins you say your commit fixed are unpopular, dated, and equally not important. I would never make that argument because I know it's all subjective. The point is, you have NO IDEA what other VST/3 plugins are now broken as a result of that commit.
2. You pushed an "EXPERIMENTAL" commit (I'd actually go further and say you introduced a bug) to master. I reported an unintended consequence of that commit and have been troubleshooting, sharing my findings, and have been asking for help. The commit actually BROKE something and you're basically saying you don't give a shit. OK, do me a favor then, when you push to master, stop marking your commits as "EXPERIMENTAL", close the issues section, and let it be known your pushes to the master branch are "take it or leave it". In fact, just get rid of the develop branch all together? Now, I know what I just suggested is utter nonsense and in all my time watching you grow this project would never expect you to actually go through with any of that. I'm simply making a point that you know your commit broke something and this is not a decent way to move forward. You actually introduced a bug which a long-time supporter has provided valuable feedback on. I actually did all of the work related to identifying the root cause and make a logical request to revert that commit. Under normal development best practices that commit wouldn't even be in master as it would have been kept in the develop branch for some reasonable amount of time in order to sollcit feedback like what I've contributed here.

Just out of curiosity, I went ahead and installed both dexed and surge on my system. Here's what I noticed:

• Both of these plugins have lv2 variants. I suspect this is why the persistence bug as it relates to the vst3 variant existed for so long. In other words, I'd be willing to bet nobody is using the vst3 variant since they'd have a preference for the lv2.

• As the screenshot shows, I wasn't able to reproduce the original bug your commit allegedly fixed. We can see the non-default "Attacky" patch was loaded after I changed the default patch, saved my session, restarted qtractor, and loaded my .qtr. I'd do the same with Dexed but that's a VST2 plugin (see the dexed-vst debian package) so I don't know why that would even be in scope.

So from what I've seen, the commit I've asked to be reverted doesn't fix anything but DOES break something.
So please revert it?

What an absolutely childish attitude. That's fine Rui. I've already forked the project and fixed it by removing your broken commit.

You mean I won't be impacted by experimental changes being shoved in with no regard for user impact? Sold!
windowsrefund/qtractor-not-broken