Hi all,

I am on Mac OS Sierra & I recently Moved my Kontakt Libraries to new External drive. I could easily locate libraries (left side) & replaced with the new path. But I got huge Quick-load instrument collection I assume 122 folders & subfolders divided. Quick-loads are saved as an Alias in my Kontakt folder & I need to change the path of those Aliases. I can change the of those Aliases one by one but Is there any way to change Path of multiple Files/Aliases at once ? I am sure there has to be something in Terminal that I can replace old path with new drive name in batch process.

Thanks in Advance

 

Delete old aliases and create new symbolic links from the new location to the old.Google Symlink creator and it's in the right click menu. Remember to remove the words symlink so that the description is identical to the new folders.

 

Thanks but if I delete the Alias then basically I am doing my quickloads from the scratch right? I got BIG collection of Quickload folders so I got huge collection of Aliases.

 

Update :


I renamed the disk as old one & created exact same path of Kontakt contents as previous External drive but no luck, but wait ! I restarted the computer & Bang ! Everything came on place all location same as before.


This is the easiest solution I found to shift to the new External hard drive.

 

Interesting comment on symbolic links here ! My testing has shown that symbolic links are not recognised by Kontakt - you MUST use aliases. This is a pity because the little utility I'm building for myself to automate the procedure of building Quick-load libraries runs much faster using the terminal to create symbolic links rather than the Finder to make aliases. On libraries with fewer instruments, this is not an issue, but with a library like Altered States which has thousands of instruments it's literally 4 times faster to build a Quick-load structure with symbolic links than with aliases !! The symbolic links also take much less space on disk 37k as opposed to 14.4 MO for the same Altered States library. My utility has to go the alias route therefore… a real shame !

 

I am finding that even Aliases are not recognized. I first tried to build a mixed library using symlinks to the different instrument folders - NG. Then I tried symlinks to the individual instrument files - still nothing. Then I replaced these with aliases, but still nothing shows up. Making an actual copy of the instruments works, but every one then has to have its links reset. There doesn't seem to be an easy way of combining libs without actually pooling their files together. (Kontakt 6.2.2 on MacOS Sierra 10.2.6)

 

I'm not sure what you're doing exactly for it not to work. Aliases definitely do work. If further proof were needed, it's exactly what Kontakt itself does when you add an instrument (or folder) to the QuickLoad menu. It creates an alias of your original in your user library/Application Support/Native Instruments/Kontakt/QuickLoad/. Check it out for yourself. On the other hand, as I said, symlinks don't work at all, which is a pity.

 

Have you tried making a symlink of the Quickload folder and replace it @ original place. Kontakt probably only understands alias of what you add as QL, but should not care about the QL folder, that just points to a place...?

K-))

 

@gorri
That works as expected but does not help my software in any way ! I wanted to use symlinks instead of aliases INSIDE the Quickload folder, whether the folder itself is an alias or a symlink, but it doesn't work. You can try this yourself, you'll see. Take an instrument for example Straylight.nki, make Both an alias and a symlink of it, e.g. Straylight alias.nki and Straylight symlink.nki and put them both in the Quickload folder. In Kontakt, you'll see "Straylight.nki". remove the symlink, no change - remove the alias, nothing ! So not only does Kontakt ignore symlinks, but it resolves the alias to its original name.

 

I probably should have been clearer - I'm not using Quicklink, I'm actually building combination libraries, attempting to avoid moving the samples from their original lib folders. When doing a batch resave, the software will not recognize aliases or symlinks the nki files. But what I do is actually copy all the nki and nkm files into the new lib folder and also add a symlink of the original lib folder where its samples are. When I batch resave and it asks where stuff is I select the symlink and it finds everything - much faster than navigating to the original. Afterwards I trash the symlink, since the links are to the original files. Not having to duplicate samples makes it more practical to, say, have certain instruments appear in more than one place.

 

I see. Well it looks as though we're fighting a different battle, but looking at what you're doing there, it seems way too tedious and space consuming to me ! Given that you can arrange the QuickLink folder as you please, and that you can place the folder where you like, as long as there's an alias or a symlink back to the Application support Kontakt folder. Having duplicates of all the nki files seems like using a sledgehammer to crack a nut to me, but then perhaps I'm missing something !

 

You may be right - copying the nki files is not a big deal, but batch resaving for every lib folder can be time-consuming, I like to see my collections in the libs tab, but it's a luxury I could easily dispense with.

 

The thing is, I reached a point where I had so many libraries, that to find something specific was becoming much too tedious. I'd waste more time searching than using ! It's all very pretty and visual having wallpapers displayed, but all told, neither practical for sorting nor finding, when you have many libraries. That's why I moved to QuickLoad, which has certain drawbacks too, but overall works better for me and of course you can keep a copy of it wherever you like, so you can drop a library into Kontakt straight from a folder on your desktop if that suits the way you work better…
The French have a saying "Don't discuss taste or colours !", a way of saying that these things are personal

 

That clutter is what I'm trying to deal with - for instance I had a number of solo string libs, each with its own strengths and uniqueness, just enough that I wasn't ready to toss any of them completely. So I stuck them all together under one lib banner and hid the originals libs. I build groups like that according to the shared material rather than the developer, but I file the actual library files by developer so updatng is easier.

 

Well I must be missing something still ! What you're describing is what QuickLoad does. What am I missing ?

 

Nothing - you're right, it does. But if you ever have to migrate to a different drive or CPU it's a pain in the ass. I have already migrated a number of libs I've built this way and it's pretty painless.

 

OK. I'm with you I just buy huge drivers ans then never move them ;)