Is there any way to block v3 of Komplete Kontrol showing in Native Access? I have a Mk1 keyboard and have to judiciously avoid the "Update All" button every time I use NA.
@kerrysmith It is not possible to block this in Native Access. In case you accidentally update, you can always find the last compatible version with the MK1 keyboards here: https://support.native-instruments.com/hc/en-us/articles/13971860838173-Notes-on-Ending-Software-Support-for-Komplete-Kontrol-S-Series-MK1-Keyboards
Nope, as discussed already here:
Honestly it is rare you really need to update much in NA unless you have an issue. Plugins are seldom updated more than for compatibility issues these days, I haven't opened Native Access in probably 12 months
@Jeremy_NI
I upvoted your post because it's helpful to the end user.
However….!
I've got a bone to pick with Native Instruments about not allowing the Native Access user to block or hide updates that do not apply to the user's system or user profile within the NI ecosphere.
The current methodology only serves to give the user more hassle, increase the chance for mistakes, and just be plain annoying, with a side of "broken customer system" for some extra bitter flavor.
Yes, as you wrote, a mistakenly-applied update CAN be rectified. But the user shouldn't have to do that.
Sometimes, we outwit ourselves. I think NI has done just that in how NA has been designed.
People have been singing this tune tho for a decade now
We hear you, unfortunately this is not that simple to implement, given the number of products and dependencies. Not saying it will never happen. We're already improving the whole Kontakt dependency topic and this has been quite a challenge. We'll forward your comments to the responsible teams.
I have been thinking it over and my personal take on the problem is that the most simple solution would be that there should be some sort of filter settings in N.A. settings that would allow people to setup their N.A. to their own preference.
Like e.g. a "I am Kontakt 6 user and wants to stick with that" filter option which then should result in N.A. only updating Kontakt libraries to version X . Using filtering would mean that it's a simple question of making a version DB for every filter set and then let N.A. follow the set version info. And once N.A. has been made able to follow a version DB then it would be very extremely simple to add or change filters without any further change to the N.A. engine itself since the app should just follow the filter rules which again is simple version lists/databases. By using an external list/DB editor then there would not even have to be any bother for changes in N.A: itself when changing filters - which I guess could even be user-editable to some extent (?) (In no way suggesting that the individual user should/would have to edit such a list , only meaning that if people/'power users'' wanted to tweak then they could…) (of course there should be pre-made filters that people could choose as an option when setting up N.A. , NI do not want that job ? Fine then I am sure that the community could make version setting filter lists if all it takes is choosing a version of something to go with another version of something else.)
Trying to make N.A. intelligent by itself by analyzing people's setup would be , as you indirectly points out yourself, very hard to implement ! (and where NI would/could argue that they are not mind readers and being unable to cover all and any circumstances)
If N.A. followed/stuck to a simple version list of desired app versions set by a filter setting then people themselves could also be responsible of setting the right filter. (in particular if wanting to use what NI considers too old version of anything)
.
