Version issues

[jamcat]

Edit: Thanks for the UADx fixes, Ben.

On a (slightly) related note, can anyone explain what “My Actual Studio” in MyKVR is for?

[sin night]

If you decide against updating the version number in the database from data coming from the user reports, maybe you could provide a tool/dashboard to devs, listing all their products in a similar way to the current “my KVR” function, with the current version and the “suggested version” retrieved from the users and a button to update or discard the suggestion (the dev could override it, maybe the version format has changed, for example from 1.0.1 to 2024-03-07). Store a timestamp when the dev updates the version and the a timestamp for each new “reported version” (I mean: the timestamp when it reaches the amount of reports needed to consider a new version likely) and you should be able to build this feature.

This way the devs are still in control, but they are also reminded to update the KVR database entry. Maybe you could set up optional notification emails to the devs as well.


Also, I don’t know if you already provide something like this, but what about providing an api (for example a simple rest service?) to devs to automatically update their product entries? Then, if they have some kind of automated deploying system for their releases (I don’t know about very small devs, but I would guess it’s so whenever they provide a software manager for their products), they could integrate a step to automatically update their KVR entries. Of course it would need some kind of login/authorization, some options to makr the new version go live on the database only after a certain date (so they can put a new version online “silently” and make it public only after some days)…


Just some ideas, I suspect some have already been considered (and maybe they are already avaible even if I’m not aware).

[sin night]

Another consideration: it would be handy to exclude certain plugins from being reported, or to provide the devs a way to enter version patterns to ignore.
I’m thinking about the chance of some betatesting (especially if private, but also in case of a public beta): you may want to avoid that version to be displayed as the current version (or you may want an option to display both the stable and the beta, I don’t know).

To me, this seems a good reason to leave it to the plugin devs to control which version number is present on the KVR db (so I think the best solution is to provide them just the tools to make this task faster and easier).

[machinesworking]

One thing that would be useful is some way within the app to report when the plugin is up to date and the KVR database says it is not etc. Some way to report issues would make sense to me anyway.

Oh, and this thing rules already, I'm happy, just wish I didn't have over 100 plugins that need updating usually one by one..

[machinesworking]

A bug related to this, and tell me if this is the right place to report this...
It successfully for the most part found and named the AU and VST plugins that needed updating, but, after updating it is not updating it's database, I rescanned locally, restarted the computer etc. to try to get it to recogonize that I updated all 100+ plugins in three formats that needed it, but it's just reporting that I did nothing ...
For instance all the VSL plugins are updated and it's not responding to that update.

[machinesworking]

XILS -Lab Poly KB III VST3 was not updated number wise etc, but the AU was, so Studio Manager reports it as if there's a KVR newer. I would guess it's possible the developer forgot to update the VST3 Mac version?

[jamcat]

Polychrome DSP Cry Boy is not in the database

[machinesworking]

OK I know it's the weekend but I want to again get this out, I would love to bug report, help with this, it's a great idea, but, as it stands I have 1041 plugins, VST3 CLAP and AU, out of that 156 are reported as "KVR Newer'.

For various reasons:

-Moog seem to be using a decimal naming scheme for Mariana, so 2.2.4 is greater than 2.2.28 So KVR thinks it needs updating...

-Moog also do not seem to update their AU and VST3 wrappers, which means their Applications in Mac OS are named after the updated with the App Store number, so Model D is version 1.3.37 like in the KVR database, but the AU is 1.0.6, same with Model 15.

-GR-8 doesn't seem to publish it's version number?
-This also seems to be an issue with paid developers. New Sonic Arts Granite installer is called "GraniteSetup16921" but it states it's version 1.0 with a GetInfo. the KVR database thinks it should be 1.6919

There are ,multiple instances of one plugin reading with the updated version and one not, so the AU of PolyKBIII reads 3.6.4 but the VST3 is 3.6.2 and shows up as "KVR Newer" since KVR database sees 3.6.4. Surge is the opposite the AU version is not publishing it's version, and showing up as 'older"

Then there's just flat out read wrong. Strobe 2 as 2.0.0 when it states it's 2.6.1 like the KVR database.

-Newer Upgrade versions are reporting as needing updates, so MODO Bass 1.5.2 vs 2.0.2, Would be nice to have it not read as needing an upgrade especially considering old songs with for instance Kontakt 6 in them will need Kontakt 6. In general if there was a way of defining between update and upgrade that would save some hassle.

[Ben [KVR]]

Seeing a versioning issue on a number of plugins, e.g.
Pro-C2 2.19 vs 2.1.9
SuperVHS 1.3.0 vs 1.3
These are (afaict) the same version but they are reported as different.

Are they shown as "Up to Date" though? The PDB version and the version reported by the plugin may differ in notation but should, hopefully, report correctly as newer, up to date, etc.

It shows as Up To Date in the main plugin list, but if I open the MyKVR side panel as shows older.

I previously had 2 plugins showing in MyKVR as requiring an update, now I have about 37 Interestingly, some of them do need an update (a couple of Plugin Alliance things), and some, especially Fabfilter reappeared on MyKVR as being out of date but just had a differently formatted version number.

Another quick example.
Blue Cat Polyvibe - in the plugin list, both versions show up to date on 1.01, but on MyKVR it shows as out of date with 1.01 vs 1.0.1

The MyKVR website groups (i.e. not KSM groups) were using a more basic version compare function that couldn't cope with simple formatting differences. I've switched it to the same one that KSM uses (which is much better but still struggles with certain situations - there is no standard for versioning so every dev seems to do things slightly differently, some don't even bother putting accurate version info into their plugins!).

[Tj Shredder]

I think upgrade vs update is important. If I have Kontakt 6 and Kontakt 7 is a payed upgrade I want at least a different color to reflect it.
Any update that requires an OS upgrade should also not be listed as a needed update and could have another color.
Then I wonder what happens if I install a not yet released beta version.
Then I might be a beta tester with a NDA signed. Under no circumstances, this should be shared with KVR. I need a way to exclude plugins from sharing…

[MrJubbly]

-Newer Upgrade versions are reporting as needing updates, so MODO Bass 1.5.2 vs 2.0.2, Would be nice to have it not read as needing an upgrade especially considering old songs with for instance Kontakt 6 in them will need Kontakt 6. In general if there was a way of defining between update and upgrade that would save some hassle.

I think upgrade vs update is important. If I have Kontakt 6 and Kontakt 7 is a payed upgrade I want at least a different color to reflect it.
Any update that requires an OS upgrade should also not be listed as a needed update and could have another color.

Yeah, I'm 100% with you guys on that.

In some situations, it perhaps makes sense to automatically flag new 'major updates' to users. For example, plugins with free upgrades, like Pigments, which I bought at v1, but is now at (I don't even know, since I no longer use it), but at least those upgrades are free.

Or for already free plugins like Vital, Surge XT, etc.

However, perhaps the KVR plugin database shouldn't necessarily assume that all users automatically would want to upgrade to 'paid upgrades' (which usually occur with major versions revisions?)

But, some very good points, imho.

[yellowmix]

Not just paid upgrades, but not wanting to introduce unknown variables into an important project that depends on a specific version. It would be great to be able to "pin" a version where updates are ignored as long as it's pinned. It will still sync so locally you know there's a new version, but when you're ready for it.

[jamcat]

Lindell Audio 6X-500, 7X-500, and PEX-500 are all listed twice in the database under Lindell Plugins:

https://www.kvraudio.com/developer/lindell-plugins

I think they should only be under Plugin Alliance here:
https://www.kvraudio.com/developer/plugin-alliance

There may be others under Plugin Alliance that appear twice.

[wangeroge]

Just tried it, saw heaps of updates, but.....they are at last revision already, for instance U-He Ace. The app says 1.4.1 installed but Pluginfo and myself verified it is already 1.4.2 etc

Beta testers might have a higher version number than you.

[wangeroge]

Thanks, appreciate the feedback. Issues with plugins not being found and being out of date should slowly start to get sorted as more people are scanning. We try to match as much automatically on the back end, but some need to be manually linked to their respective products in the database. You'll most likely see that not found number drop in the next day or two even.

Have you noticed that beta testers pollute the data with higher version numbers? For example you can see that someone already uses Boz Das Boot 2 etc.