Native access?

VST, AU, AAX, CLAP, etc. Plugin Virtual Instruments Discussion
Post Reply New Topic
RELATED
PRODUCTS

Post

Deleted by Arcvidean
Last edited by Arcvidean on Mon Sep 25, 2017 6:29 pm, edited 1 time in total.

Post

Deleted by Arcvidean
Last edited by Arcvidean on Mon Sep 25, 2017 6:29 pm, edited 1 time in total.

Post

Arcvidean wrote:
fmr wrote:
Kr3eM wrote:
Arcvidean wrote:
HiEnergy wrote:For me Native Access is a big step backwards as I have no Internet connection on my studio computer and Native Access does not offer any offline options where Service Center did.
So for me NI is basically a dead end now. I'll use what I have (Komplete 9, Kontakt 5.6.6) and not update or buy anything new from them as long as possible.
Precisely the same here. Seems like they aren't concerned. :dog:

Arcvidean
+1
So, you don't update your OS either? NEVER? Unless you remain forever with that computer and that OS version, and don't update ANYTHING, I don't see a future for you.
There's nothing I can do about it as I live in a house in the mountains in Wales with several 2 foot thick stone internal walls between the internet hub and my computer, no wireless signal is going to get through.I would have to physically carry my computer downstairs and across the house. Still at least I won't be brain dead from constant microwave radiation. :tu:

Arcvidean.
You are aware of repeater devices, right?

There's also network using power sockets, but, i heard some not so good things about it.

Post

fmr wrote:Even if NI would do that as you say, I bet that some users would not choose anything, close the dialog box, and after installing would complain that the installers didn't work correctly :shrug:
Well, I didn't do that.

When I upgraded to Reaktor 6 earlier this year, with Native Access, I also experienced the VST going "missing"

But I can't remember I went on a forum to bitch about that, I went back into Native Access, saw the small menu/preference button, and understood that I should have set that before installing anything. So I uninstalled Reaktor, set my preference, and installed again, and then it worked.

But I would prefer that NI had a pop up window, underlining the importance of setting the desired vst path. Would have saved me an hour of trouble shooting.

I am used to dealing with installers, and those at some point will ask where the vst is to be installed.

Post

Mace404 wrote:
EvilDragon wrote:
Orbit-50 wrote:What makes everything worse, is that the Native Instruments installer pukes files in every corner of of the file system so manual uninstalls of broken paths are are even harder to do.
Paths where stuff is placed didn't change between SC and NA - in the background exactly the same installers are used. NI is just following MS guidelines on where what kind of data should go, so yes, you will get uninstallers in ProgramData because that's how InstallShield works, you will get factory data in Common Files\Native Instruments because that's where it's supposed to go, you will get all the database stuff in AppData\Local\Native Instruments because that's where it's supposed to go as well, and you will get the NKS stuff installed to Public folder because it's supposed to be installed for all users. It is NOT a good practice to put everything in Program Files (this is where just the standalone executables and documentation is supposed to go), so NI doesn't do it. As per MS guidelines.

None of this changed because of Native Access, it's all how it used to be years before, going back to Kore and even before it.
This. NI is actually one of the few developers doing it right/as per MS guidelines.
No, not really. Having it installed on two systems, I can attest to the fact that the Native system puts it in several places hoping one will work. And they don't even place like plugins consistently. So I find some under "ProgramData", others in "Program Files\Native Instruments" - "Program Files (x86)" and yet others in "Program Files\Common" and then also under "Users\Appdata\Roaming\Native Instruments", others in "Users\Appdata\Local" and still more under "Users\Documents" and "Users\Downloads". Of course, I have three separate folders set up for them on a secondary drive, which they also mostly apply them to also, but not always. Seems to me they really don't have a clear notion what "MS guidelines" are and just use a shotgun approach hoping they'll get something to work. Which of late, has been rather 'hit and miss'.

How does anyone miss with a shotgun and only manage to shoot their self in the foot? :shrug:

BTW, I was finally able to use the by-pass method of downloading by finding the link in their 'new idea' of a meta-link file replacing the old *.toc files. Something they appear to be trying to keep hidden to further force everyone to follow them blindly and erroneously. Updated without using Access and sheesh, there it is, but it refuses to see any of my third party libraries (which is all I ever use)... even after I add the path back to them and rescan. And they seem to have eliminated the "Add Library" function as well.

Really tired of this crap.

Post

BBFG# wrote:
Mace404 wrote:
EvilDragon wrote:
Orbit-50 wrote:What makes everything worse, is that the Native Instruments installer pukes files in every corner of of the file system so manual uninstalls of broken paths are are even harder to do.
Paths where stuff is placed didn't change between SC and NA - in the background exactly the same installers are used. NI is just following MS guidelines on where what kind of data should go, so yes, you will get uninstallers in ProgramData because that's how InstallShield works, you will get factory data in Common Files\Native Instruments because that's where it's supposed to go, you will get all the database stuff in AppData\Local\Native Instruments because that's where it's supposed to go as well, and you will get the NKS stuff installed to Public folder because it's supposed to be installed for all users. It is NOT a good practice to put everything in Program Files (this is where just the standalone executables and documentation is supposed to go), so NI doesn't do it. As per MS guidelines.

None of this changed because of Native Access, it's all how it used to be years before, going back to Kore and even before it.
This. NI is actually one of the few developers doing it right/as per MS guidelines.
No, not really. Having it installed on two systems, I can attest to the fact that the Native system puts it in several places hoping one will work.
What does that even mean?

I don't like files cluttered over dozens of folders too, but... the main application files are in ProgramFiles, installer logs are in ProgramData, unlike you claimed, there's nothing in ProgramFiles (x86) here, at all, and the rest of the locations hoards the usual suspect stuff, like configuration files, manuals and presets. They're not randomly put in folders, "hoping one will work". Even though i'm not even sure you meant that.

Post

fmr wrote: So, you don't update your OS either? NEVER? Unless you remain forever with that computer and that OS version, and don't update ANYTHING, I don't see a future for you.
I've been a customer of NI for almost 20 years, I would like to think I would be able to express my preferences for an offline option even if there are very few customers like me without getting all this attitude.

And regarding never updating OS...
I only need a way for an offline option, even if it's manual execution via DOS... which is by the way how I updated my root certificate for windows 7 to be able to update my UAD-2...(allthough UAD FAQ told me I needed to go online and run windows update to do, which is bollocks and a shitty support solution) and besides a small win platform update thats all the Windows updated I have actually needed to do from win7u sp1 x64... (but then I do not have anything from Waves or that uses iLok, Syncrosoft ect)
...so there you go, hope that answer your question.

I'm sorry for expressing my desire to have the option to have a offline system which I can control and maintain myself with the least possible dependencies.

I do realize it's somewhat off topic, but expressing personal likes and dislikes with fairly loose grounds is apparently what we do here... So I will leave you all to continue doing so...

All the best Regards

Post

Users/Documents - > user data, presets, crashlogs...
Program Files/Common -> factory data (i.e. IR samples for Kontakt, samples for Absynth 5 IIRC...)
Appdata\Roaming -> just some Native Access cache files
Appdata\Local -> databases mostly

Under no condition have I ever seen a plugin DLL in ANY of those folders (apart from Kore 2 "builtin engines" of course). And I've been using NI stuff for years.

Post

chk071 wrote:
BBFG# wrote:
Mace404 wrote:
EvilDragon wrote:
Orbit-50 wrote:What makes everything worse, is that the Native Instruments installer pukes files in every corner of of the file system so manual uninstalls of broken paths are are even harder to do.
Paths where stuff is placed didn't change between SC and NA - in the background exactly the same installers are used. NI is just following MS guidelines on where what kind of data should go, so yes, you will get uninstallers in ProgramData because that's how InstallShield works, you will get factory data in Common Files\Native Instruments because that's where it's supposed to go, you will get all the database stuff in AppData\Local\Native Instruments because that's where it's supposed to go as well, and you will get the NKS stuff installed to Public folder because it's supposed to be installed for all users. It is NOT a good practice to put everything in Program Files (this is where just the standalone executables and documentation is supposed to go), so NI doesn't do it. As per MS guidelines.

None of this changed because of Native Access, it's all how it used to be years before, going back to Kore and even before it.
This. NI is actually one of the few developers doing it right/as per MS guidelines.
No, not really. Having it installed on two systems, I can attest to the fact that the Native system puts it in several places hoping one will work.
What does that even mean?

I don't like files cluttered over dozens of folders too, but... the main application files are in ProgramFiles, installer logs are in ProgramData, unlike you claimed, there's nothing in ProgramFiles (x86) here, at all, and the rest of the locations hoards the usual suspect stuff, like configuration files, manuals and presets. They're not randomly put in folders, "hoping one will work". Even though i'm not even sure you meant that.
I have found "installer logs" in programdata, appdata - local & roaming. As long as I've had NI, it insists on having a separate folder for 32 bit *.dll which it has always pointed to both their idea of where it should belong and where they say they will put it according to my set preferences.
Oh! And sometimes it creates its own separate folder under "Program Files\VST Plugins" to put *.dll files in.
Personally would like them to give us an option of not installing what we don't use there. But no, even with a complete un-install, removing all registry keys, scattered folders, files and letting them install wherever they choose has continued to result in them splattered everywhere and more than a few things just not working. Obviously, it works for some and equally doesn't work for others. Which tells me the whole thing confuses them too and they work hard to make it the customer's fault and not theirs at all. Which seems even more obvious with their new philosophy of "just ignore the support requests until they go away".

So yeah, I'm planning my get away from them now.
And yes, I think it's gonna hurt.

Post

I haven't experienced similar... the only thing that is a tad annoying is that you HAVE to install 32-bit (or 64-bit) versions too, so i always have two different folders for 64-bit and 32-bit plugins, because some other companies make you install both versions too (fxpansion comes to mind). They're all where they're supposed to be though (and where i directed Native Access to install them).

Post

BBFG# wrote: I have found "installer logs" in programdata, appdata - local & roaming. As long as I've had NI, it insists on having a separate folder for 32 bit *.dll which it has always pointed to both their idea of where it should belong and where they say they will put it according to my set preferences.
Oh! And sometimes it creates its own separate folder under "Program Files\VST Plugins" to put *.dll files in.
Personally would like them to give us an option of not installing what we don't use there. But no, even with a complete un-install, removing all registry keys, scattered folders, files and letting them install wherever they choose has continued to result in them splattered everywhere and more than a few things just not working. Obviously, it works for some and equally doesn't work for others. Which tells me the whole thing confuses them too and they work hard to make it the customer's fault and not theirs at all. Which seems even more obvious with their new philosophy of "just ignore the support requests until they go away".
I must have a really "clean" OS over here, because ALL my installer logs are located in a folder named "Installer Log" under Program Data/Native Instruments. The oldest log is from Service Center, dating back from July 2013. So, NI has been pretty consistent over here.

Regarding the DLL placement, by default (and I say by default because I didn't change that since I installed Native Access), they install the DLLs in Program Files\Native Instruments\VstPlugins 64 bits and Program Files\Native Instruments\VstPlugins 32 bits.

And yes, 32 and 64 bits are installed in different folders. I have them like that too, and I think it's the obvious choice. But you can copy them from the default folder and place them wherever you wish. It's just Copy and Paste. No big deal. You can create folders, not create folders, whatever pleases you.
Fernando (FMR)

Post

fmr wrote:I must have a really "clean" OS over here, because ALL my installer logs are located in a folder named "Installer Log" under Program Data/Native Instruments. The oldest log is from Service Center, dating back from July 2013. So, NI has been pretty consistent over here.
Same here, that folder takes up 56KB HDD space.

So why do they need to hide the folders in my Program Data folder that takes up 663MB HDD space?

Post

Numanoid wrote:
fmr wrote:I must have a really "clean" OS over here, because ALL my installer logs are located in a folder named "Installer Log" under Program Data/Native Instruments. The oldest log is from Service Center, dating back from July 2013. So, NI has been pretty consistent over here.
Same here, that folder takes up 56KB HDD space.

So why do they need to hide the folders in my Program Data folder that takes up 663MB HDD space?
My Program Data folder has just a little more than 2 MB, and besides the mentioned LOG folder has just another one, for the Controller Editor :shrug:

The App Data folder in my User has One Native Instruments in Local (where are all the Databases) and another one in Roaming, where there is just content related with Native Access.
Fernando (FMR)

Post

BBFG# wrote:No, not really. Having it installed on two systems, I can attest to the fact that the Native system puts it in several places hoping one will work. And they don't even place like plugins consistently. So I find some under "ProgramData", others in "Program Files\Native Instruments" - "Program Files (x86)" and yet others in "Program Files\Common" and then also under "Users\Appdata\Roaming\Native Instruments", others in "Users\Appdata\Local" and still more under "Users\Documents" and "Users\Downloads".
BINGO!!!!! That's what I was talking about! I have the same exact thing. Lest we forget the "million weird character folders" with names like {45B3F1D3-B6DA-4FAD-966B-4E0B29ACEFAE} that it splatters right on top of the program data folder for each product installed. This might have caused my problems when I deleted them a while ago thinking they were just garbage and should not be there. They really shouldn't be there to be honest. Nothing else that I have installed, has ever done that. Come to find out later when a few of them reappeared in the C\Program Data folder after trying to update with Native Access, which was a fail because of some unknown reason, that they were put there by Komplete. This is all water under the bridge to me at this point, but I just wish that they would freakin' take more care in making a neater install path considering the size of the product.
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Alienware i7 R3 loaded with billions of DAWS and plugins.

Post

You folks are still missing the real point.
Being that, while there were occasionally some discrepancies that happened using Service Center, and all of those I could easily by-pass by simply downloading from my account and doing my own installing/updating, and using Service Center only for authorizing are now gone. Many complained about it, but there was a viable work around. It appears that even more are complaining about Access since any work around is being written, rewritten and hidden to keep anyone from using it. Because the few things you could depend on SC are gone and for many of us have become non-existent in Access. As far as I'm concerned, all they need to do is give me back the ability to download from my account so I can do it once and install as I've always had. But what this last Kontakt update has shown me, even that is a thing of the past. But the whole idea of removing links from the accounts and hiding them in folders that we have to let Access try and fail before we can search wherever they're trying to hide it so that I can simply 'paste&go' in my browser all feels a bit too much like a 'shell game'.

I simply don't like having to deal with people that act like con-artists.
And that seems to be the foundation of their new philosophy here.

Post Reply

Return to “Instruments”