MeldaProduction

paterpeter · Post by **paterpeter** » Sat May 28, 2011 6:59 pm

Hi,

I just installed the creative bundle 5.01 on my new machine. I noticed that I can't use any of the plugins unless I'm running my host with admin rights (tested in Reaper 4 beta 7 and FL Studio 10). As a non-admin user, I don't see the user interface, and FL Studio even reports an access violation. As admin user, everything works fine.

What can I do? I suppose there's something going on with access rights somewhere, but where? I already gave the non-admin user write access to the VST dir and the MCreativeBundle dir and copied all Melda stuff from Admin/App Data/Roaming/ to the non-admin user, but still no luck.

Regards,
Andre

kx.001 · Post by **kx.001** » Sat May 28, 2011 7:11 pm

Do you have them installed in C:\Prgram files? Unless you run as admin all the time you need to run things as admin to access it I think (I'm sure I read that in u-hes forum..

paterpeter · Post by **paterpeter** » Sat May 28, 2011 7:15 pm

First I installed them into c:\Program Files\VstPlugins and tried giving the user full access (using the Security tab).

But I also tried installing them to another drive (and checked the access rights there, too) without luck.

On my old system I had the v4 plugins running without problems btw.

kx.001 · Post by **kx.001** » Sat May 28, 2011 7:17 pm

They run fine here in FL STudio and Reaper 3.76 (installed today) I havent' got the beta of reaper 4 though.

The 64 bit ones don't load in FL Studio, but I dont need them to, they open fine in Reaper though.

paterpeter · Post by **paterpeter** » Sat May 28, 2011 8:59 pm

Hm, I guess I'll have to give it another try

WOK · Post by **WOK** » Sat May 28, 2011 9:05 pm

Maybe they want to write something into the registry, and that key is not accessible without admin rights.
I think many progs will make problems using them as a "normal" user - why not give yourself admin rights in Windows? (it's not a great protection against virus' anyway)

paterpeter · Post by **paterpeter** » Sat May 28, 2011 9:32 pm

Thanks for your answer. Indeed, it could be the registry as well, maybe Vojtech can give me a hint.

Giving my every-day user admin rights is not an option, though. Actually, no other program that I use requires admin rights to run properly (accept administration applications, of course).

paterpeter · Post by **paterpeter** » Sat May 28, 2011 9:51 pm

A little bump, because I fixed the problem. Or better: I found a workaround.

I gave my non-admin user admin rights temporarily, then installed it as the now-admin user and finally revoked the admin rights again. Now it works.

So, to wrap it up: it seems that the plugins are only usable by the account that installed them.

I strongly think that it has to do with the stuff the installer puts in App Data of the installing account.

BTW: is it really necessary that the installer puts that many files directly into the App Data\Roaming directory? I installed the creative and the free bundle and I have 42 files in there. The MeldaProduction subfolder would be a much better place, right?

MeldaProduction · Post by **MeldaProduction** » Sun May 29, 2011 8:50 pm

Sorry for the delay. Anyway I think the only logical way is to install the plugins under you account. Why didn't you do that?

And why are you viewing the roaming folder? Do not do that. This directory is designed for data of the applications, not for the user. Trust me, the worst thing you can do is manipulate with them.
(btw. most files are now in MeldaProduction subfolder, but some are not - backwards compatibility issues)

paterpeter · Post by **paterpeter** » Mon May 30, 2011 7:06 am

MeldaProduction wrote:Sorry for the delay. Anyway I think the only logical way is to install the plugins under you account. Why didn't you do that?

Because my every-day user has no admin rights (i.e., it's a limited account), as it is supposed to be!

I have at least two accounts on my systems: one admin account and (for each user) a limited user account. If I want to install stuff I use "Run as administrator", select the admin account, enter the password and install the software. Seriously, that's how it's supposed to be! The application is installed as a different user (the admin), but that shouldn't matter - see below.

And why are you viewing the roaming folder? Do not do that. This directory is designed for data of the applications, not for the user.

First off, I'd consider myself rather experienced and competent when it comes to PCs (I studied CompSci, I'm a professional s/w developer and I administer the computer systems of several companies).

The %APPDATA% (normally AppData\Roaming) folder is used for per-user application data, like settings, bookmarks in a browsers, save games etc.*
[In contrast to %LOCALAPPDATA% (AppData\Local), the Roaming folders are part of the network/roaming profile of the user (which, of course, for local users, does not make much difference).]

But what's important: neither %APPDATA% nor %LOCALAPPDATA% are supposed to be used for data that is shared between users or which is essential for the proper execution of the application. Use %PROGRAMDATA% (e.g. c:\ProgramData) to store data that is used by all users. Cakewalk for example stores the presets of Rapture, z3ta+ and Dimension Pro in c:\ProgramData, i.e., all presets are accessible by all users.

A user should be allowed to simply delete any folder in AppData\Roaming or AppData\Local. The respective application should simply reinitialize those folder on the next startup, just as if a new user would start the application for the first time. If you use Firefox, delete AppData\Roaming\Mozilla (after making a backup of course) and restart Firefox: everything works, you only lost all settings, bookmarks etc.

If your application does not work like this, you have made false assumptions about the roles of certain folders in a Windows system.

Trust me, the worst thing you can do is manipulate with them.
(btw. most files are now in MeldaProduction subfolder, but some are not - backwards compatibility issues)

My suggestion for 5.02: make the installer put shared data into c:\ProgramData and only store per-user data into AppData - or - re-initialize the AppData folder of the user running the plugins as necessary. Don't make us fall into the old, bad habit of using privileged users for everyday work. It'd be a sad flaw on your otherwise awesome plugins!

Regards,
Andre

P.S.: please don't take this as an offence, I'm just trying to improve your great products

If I didn't care so much about them, I'd never written that much. Keep up your great work!

* Actually there isn't much difference between AppData\Roaming and folders like e.g. Documents. The latter is preferred for data that the user is supposed to see and use directly, whereas the former is used for data that is typically only accessed by the application. Some apps mix this difference up a bit. Nevertheless, users should know how to manage and backup(!) both AppData and Documents.

MeldaProduction · Post by **MeldaProduction** » Mon May 30, 2011 9:48 am

paterpeter wrote: My suggestion for 5.02: make the installer put shared data into c:\ProgramData and only store per-user data into AppData - or - re-initialize the AppData folder of the user running the plugins as necessary. Don't make us fall into the old, bad habit of using privileged users for everyday work. It'd be a sad flaw on your otherwise awesome plugins!

Regards,
Andre

P.S.: please don't take this as an offence, I'm just trying to improve your great products If I didn't care so much about them, I'd never written that much. Keep up your great work!

Thanks and don't worry, none taken

.

Anyway I'm afraid this won't happen, in fact it was originally like that. The "missing" thing that was in AppData were the styles, they were missing, which is the reason the plugins did crash. It is fine to have these shared, but the trouble was, that there were I think 2 cases, where the installer couldn't save them into the AppData pahts, because of some security settings or something. It has never been explained why, but it happened, so putting the styles into user-related program data solves the problem. Not exactly ideal, but since people usually don't use user accounts, it works.

And the rest of the files must stay there - you can freely delete them, but they contain presets and stuff, I definitely thing these things must stay user-related.

paterpeter · Post by **paterpeter** » Mon May 30, 2011 10:34 am

Thanks for your answer. Which files exactly contain the styles? Maybe I can find myself a better way to circumvent my issues the next time I need to install the bundles.

Regards,
Andre

MeldaProduction · Post by **MeldaProduction** » Mon May 30, 2011 10:45 am

paterpeter wrote:Thanks for your answer. Which files exactly contain the styles? Maybe I can find myself a better way to circumvent my issues the next time I need to install the bundles.

Regards,
Andre

They are all located in the MTexturedStyles directory. You can put it to global data if you want.

Cheers!

paterpeter · Post by **paterpeter** » Tue May 31, 2011 5:20 am

Ah, that was the one folder I've been overlooking all the time. Thanks, now I know what to do next time.

I'd still much appreciate if you figured out the problems and used the "proper" folders for shared data. If I can help you in any way with that, shoot me a message.

Q309isfun · Post by **Q309isfun** » Fri Feb 14, 2020 9:29 pm

Thanks, workaround also worked for me with a different plungin. In fact, I had this problem quite often - and I refuse to use an admin account for daily business.

MeldaProduction

KVR Audio

Plugins don't work when not running as admin