Add new comment

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?