Duplicate bug

[yellowmix]

Version: 0.1.6.1

Problem: The app does not distinguish between folder name and file names. Some VST3 plugins are under a parent folder with the same name as the plugin file. For example, BBC Symphony Orchestra (64 Bit).vst3. The app detects the folder as a duplicate erroneously.

Solution: The app should test if something is a file or folder. If it's a folder, do not consider it a plugin.

[Ben [KVR]]

A folder shouldn't be detected as a duplicate!

When you right click on the duplicate error there should be two "Show PLUGIN NAME A.B.C in Explorer / Finder" options. Do they open to different plugin files?

Could you send me a screenshot of the scan report result screen that lists the error (to ksm@kvr{you-know-the-rest}.com)? Or write the text here if it's easier.

[MRT]

There is a recent pattern of developers installing their vst3 plugins nested in a folder structure that starts with a folder" VST name.vst3". I am curious as to the reason for this? I've had problems in the past from giving folders a file extension, and this is an example of that. I've been removing the .vst3 file and deleting the folders just to keep things neat, but this has its own issues?

[yellowmix]

A folder shouldn't be detected as a duplicate!

When you right click on the duplicate error there should be two "Show PLUGIN NAME A.B.C in Explorer / Finder" options. Do they open to different plugin files?

Could you send me a screenshot of the scan report result screen that lists the error (to ksm@kvr{you-know-the-rest}.com)? Or write the text here if it's easier.

I've recreated the situation (I had already updated the plugin so I reverted from a backup). It seems to be more of a rescan issue edge case. It's when the plugin is originally installed somewhere, then when updated, is replaced with a VST3 folder structure where the folder name is the same as the old plugin. "Show location" will go to the folder or updated VST3, respectively.

KVR Studio Manager - Version Conflict Scan.PNG

KVR Studio Manager - Version Conflict Scan - Popup.PNG

However, when closing the scan window, the database is correct. That is, it contains only one record, that of the updated plugin.

[yellowmix]

There is a recent pattern of developers installing their vst3 plugins nested in a folder structure that starts with a folder" VST name.vst3". I am curious as to the reason for this? I've had problems in the past from giving folders a file extension, and this is an example of that. I've been removing the .vst3 file and deleting the folders just to keep things neat, but this has its own issues?

That is a legitimate plug-in location structure per the VST3 spec. It is most often used when both 64-bit and 32-bit versions are installed on Windows. Since the 64-bit location is Program Files\Common Files\VST3 there is an implication that all binaries within are 64-bit. However, the folder structure can house 32-bit binaries so it gets its own folder noting that for clarity.

To simplify installation/support, some devs use this structure whether you choose to have 32-bit installed or not, and choose not to install 32-bit binaries to Program Files (x86). Call it laziness but I'd rather devs focus on developing the plugin and this systems stuff is more forgivable since it's behind-the-scenes except in this case, which is not their problem as it is per spec.

Bonus, in that case there is often a moduleinfo.json that contains some metadata including the version. But as users can modify it easily (and other things can go awry) still best to scan the plugin binary.

[MRT]

Thanks for the clarification on the use of this folder structure. But, shouldn't the 32bit vst3's be installed at Program Files(x86)\Common Files\ VST3. Or has this location been done away with? I'm on win 10.
Regardless, it seems odd at best to name a folder with a file extension.