How about a "Locate all" function in Native Access?

Options
13»

Answers

  • DunedinDragon
    DunedinDragon Member Posts: 468 Pro
    edited March 16
    Options

    Boy that would have saved me about three or four hours this last week with my library cleanup!!! Amazingly enough I survived and endured it all without one single moment of whining!!! Imagine that!!!

  • PoorFellow
    PoorFellow Moderator Posts: 2,822 mod
    Options

    Quote you : "While I do understand that integrating PA and Izotope into the NI "ecosystem" is a hard task, I don't understand how that is related in any way to a "locate all" function for Kontakt libraries or even expansions."

    Quote me : "Native Instruments are in the process of re-writing all the 'classical' N.I. library install software to be able to deliver 'Locate All' while at the same time, following the acquisition of iZotope and Plugin-alliance, also have to deal with having to completely rewriting the iZotope and Plugin-alliance installers for what they want to install via Native Access and on top of that deal with that some stuff are protected by iLok use."

    Most basically then problem is two fold , firstly then as I wrote then the rewriting the N.I. library installers are a project being done while at the same time also having have to deal with having to completely rewrite the iZotope and Plugin-alliance installers , and all of this I'm sure have to be a coordinated effort !. Also there have been other stuff that have had higher priority previously. And my response were related to your question of : "So if this was "in the backlog" in 2022, how is this still not implemented in 2024?"

    Secondly then most people in this forum fail to see the most basic thing. A very large section of the problems that we see that are not directly connected to OS makers changes of OS' (and then even some of that !) are connected to the fact that it all needs DRM protection since N.I. lives of selling stuff and can not allow that the downloads and installation is not DRM protected.

    So rather than it all is only about something as easy as just point to and add then all the stuff needs to be wrapped up in some sort of DRM protection else anyone could just get an unlimited amount of illegal copies of everything and then just add to collection and use as is !

    So this DRM protection will need to include when you are 'just adding' your existing stuff !

    Also then when adding existing libraries then Native Access would have to get programmed with/receive content info including version awareness and what not, that might previously not have been needed with all having been built into individual installers, and thus maybe not existing but might have had to be added. It is very easy asking for something but might not be so easy if you are the one that have to make it happen !

  • sickvisionz
    sickvisionz Member Posts: 3 Member
    Options

    The idea that it's like Mission Impossible to point something to a root folder and try to locate folders based on a system where products have default folder names and the software knows the default folder names doesn't make any sense.

    Just in the small amount of digging I've done for about an hour:

    C:\Program Files\Common Files\Native Instruments\Service Center\NativeAccess.XML

    Registry -> HKEY_LOCAL_MACHINE -> SOFTWARE -> Native Instruments

    The registry has keys for everything. The key name (and default folder name) is based off of every product's <Product><Name></Name> entry in the XML file. The rest of the data is in the XML file as well.

    • "ContentDir" (string) is your content directory. You set it to the folder with the file.
    • "ContentVersion" (string) is the version #. The XML file has all the software. You can get any program's version from its <Relevance minVersion="[VERSION #]"> tag
    • "HU" (string) I don't know what this means but the HU value can be obtained by the program's <ProductSpecific><HU></HU> tag
    • "JDX" (string) I don't know what this means but the JDX value can be obtained by the program's <ProductSpecific><JDX></JDX> tag
    • Visibility (DWORD) I don't know what this means but it's always set to 3

    I was able to add some programs and have them recognized as being installed successfully.

    Give me a few days. With ChatGPT's help I'll have a Python script on GitHub where you tell it where your XML file is and it'll run through it and add the keys to your registry for you. The only immediate thing is that the XML file looks like it has all products and I need a way of finding out which ones you already have. I'll probably just have you tell it your root folder, it'll scan that for subfolders and compile a list based on that. As long as you let the installer do their thing and didn't do something dumb like rename the "Analog Dreams" folder to like "Ooga Booga", it should work.

    It's shameful that NI sells packages with like 200+ bits of software in them and expects you to one by one locate every single one. It's also not some mammoth task, certainly not something that takes well over a year to implement.

  • Kubrak
    Kubrak Member Posts: 2,790 Expert
    Options

    But, this would probably work only, if you relocate already installed content, or installing again after OS reinstall on computer where it has been already installed in past....

    It would not work, I guess, on new computer, even if you have XML file from older computer....

    But maybe, if you run NA afterwards it might authorise content and things would work... Hard to say...

  • mykejb
    mykejb Moderator Posts: 1,209 mod
    Options

    It's interesting that you can't locate content for Maschine expansions, only for Kontakt libraries. I'm assuming that's because the Maschine expansions have Maschine packs, plus often things like Massive/Monark patches and sample libraries for Battery that have to be moved to the correct place. Certainly if you can locate one Kontakt library though it's possible to scan all the folders automatically and do the same operation on all the folders. Or it would be if it was coded into the app.

  • sickvisionz
    sickvisionz Member Posts: 3 Member
    edited April 8
    Options

    My OS was on drive 1 and my library content was installed on drive 2. Drive 1 crashed and when I replaced it, decided to buy another M.2 SSD to finally put all my drive 2 content on a faster drive. Installed my OS again on new drive 1 and moved all my drive 2 content to new drive 2. When I installed Native Access, that's when I came across the lack of a "Locate All" and that I'd have to go through like 200 folders one-by-one.

    Anyways, for people seeing this in the future: https://github.com/sickvisionz/Native-Instruments-Linker. You can be proud to have wasted 3 or 4 hours clicking like a robot in Native Access or you can spend those 3 or 4 hours making music. The choice is up to you.

    Hopefully NI can get on the ball and implement this. It really isn't difficult, especially if you have the source code like they do. There's really no reason that can't at least add a smarter auto-locate once you tell Native Access the root folder. It's literally just registry edits or implementing whatever function they do when users click the "Locate" button, but the software changes the folder path variable on it's own. None of this is rocket science. Or something that takes going on two years to implement.

  • Kubrak
    Kubrak Member Posts: 2,790 Expert
    Options

    But then you did not have C:\Program Files\Common Files\Native Instruments\Service Center\NativeAccess.XML file at hand.... Or the disk did not crash that much..... Or you had OS backup...

    Anyway, good work, just usable for certain, IMHO limited, usecase. Still beneficial.

Back To Top