Version issues
- KVRAF
- 5563 posts since 2 Sep, 2019
Edit: Thanks for the UADx fixes, Ben.
On a (slightly) related note, can anyone explain what “My Actual Studio” in MyKVR is for?
On a (slightly) related note, can anyone explain what “My Actual Studio” in MyKVR is for?
THIS MUSIC HAS BEEN MIXED TO BE PLAYED LOUD SO TURN IT UP
-
- KVRAF
- 1571 posts since 1 Aug, 2006 from Italy
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).
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).
-
- KVRAF
- 1571 posts since 1 Aug, 2006 from Italy
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).
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 machinesworking https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=8505
- KVRAF
- 6297 posts since 15 Aug, 2003 from seattle
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..![Clown :clown:](./images/smilies/icon_clown.gif)
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..
![Clown :clown:](./images/smilies/icon_clown.gif)
-
machinesworking machinesworking https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=8505
- KVRAF
- 6297 posts since 15 Aug, 2003 from seattle
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.
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 machinesworking https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=8505
- KVRAF
- 6297 posts since 15 Aug, 2003 from seattle
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?
- KVRAF
- 5563 posts since 2 Sep, 2019
Polychrome DSP Cry Boy is not in the database ![Crying or Very sad :cry:](./images/smilies/icon_cry.gif)
![Crying or Very sad :cry:](./images/smilies/icon_cry.gif)
Last edited by jamcat on Wed Mar 13, 2024 9:00 pm, edited 1 time in total.
THIS MUSIC HAS BEEN MIXED TO BE PLAYED LOUD SO TURN IT UP
-
machinesworking machinesworking https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=8505
- KVRAF
- 6297 posts since 15 Aug, 2003 from seattle
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.
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.
- Mr KVR
- 1431 posts since 23 Oct, 2000 from UK
- KVR Audio
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!).neverbeeninariot wrote: ↑Fri Mar 01, 2024 7:37 pmIt shows as Up To Date in the main plugin list, but if I open the MyKVR side panel as shows older.Ben [KVR] wrote: ↑Fri Mar 01, 2024 7:27 pmAre 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.neverbeeninariot wrote: ↑Fri Mar 01, 2024 6:43 pm 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.
I previously had 2 plugins showing in MyKVR as requiring an update, now I have about 37Interestingly, 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
- KVRAF
- 8845 posts since 6 Jan, 2017 from Outer Space
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…
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…
-
- KVRist
- 463 posts since 30 May, 2019
machinesworking wrote: ↑Sat Mar 09, 2024 6:32 am -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.
Tj Shredder wrote: ↑Sat Mar 09, 2024 2:58 pm 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.
-
- KVRAF
- 2011 posts since 11 Aug, 2012 from omfr morf form romf frmo
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.
- KVRAF
- 5563 posts since 2 Sep, 2019
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.
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.
THIS MUSIC HAS BEEN MIXED TO BE PLAYED LOUD SO TURN IT UP
- KVRian
- 570 posts since 19 Aug, 2020 from the top of the charts
Beta testers might have a higher version number than you.Septic Underground wrote: ↑Fri Mar 01, 2024 4:24 pm 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
If you plan on purchasing your first Universal Audio hardware, you can get a free additional plugin. Just send a PM.
- KVRian
- 570 posts since 19 Aug, 2020 from the top of the charts
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.NateKVR wrote: ↑Fri Mar 01, 2024 5:49 pm 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.
If you plan on purchasing your first Universal Audio hardware, you can get a free additional plugin. Just send a PM.