Memorymoon ME80 going 64 bit

[EvilDragon]

Please don't make it like that, root of C: drive is not to be littered. Any files related to a plugin (a program) should go to Documents folder, both on Windows and on Mac. There should be an option to install for either current user (then it goes to the current user's Documents folder, example: C:\Users\<username>\Documents\Memorymoon\ME80\), or for all users (then it goes to public users folder, example: C:\Users\Public\Documents\Memorymoon\ME80).

This is the proper way to do stuff like this, there are programming guidelines that both Microsoft and Apple have for these situations, for a good reason.

[BBFG#]

Please don't make it like that, root of C: drive is not to be littered. Any files related to a plugin (a program) should go to Documents folder, both on Windows and on Mac. There should be an option to install for either current user (then it goes to the current user's Documents folder, example: C:\Users\<username>\Documents\Memorymoon\ME80\), or for all users (then it goes to public users folder, example: C:\Users\Public\Documents\Memorymoon\ME80).

This is the proper way to do stuff like this, there are programming guidelines that both Microsoft and Apple have for these situations, for a good reason.

I have to disagree here. First, depending on developer, I have seen these 'associated files' go where you point out or to it's own folder buried under the app folder under 'user' or even under it's own folder under 'c:\program data'.
The fact is, that there being no real standard as to where to put them seems to be more of the developer's mindset than a restriction of windows per se. And that is where most of us end up with a 'littered' C:Drive.
For those of us that do our best to 'un-litter' these installations and keep them all centralized, it's imperative that 1. We choose the path and folder it goes on (which can more often be a D: or E: Drive). and 2. That subsequent updates search the registry for that path and apply it there. (This is one of my most frequent complaints to Cakewalk and Steinberg, where sometimes it does do that, while others simply re-write a whole new directory to 'litter' everywhere.) BTW, NI has this problem of inconsistency too.

As my drives are set up, the path(s) would be chosen to read more like:
D:\x64\Memorymoon\ME80 with the dllx64 file placed under the Memorymoon folder.
D:\x86\Memorymoon\ME80 with the dllx32 file placed under the Memorymoon folder.
And depending on structure the 'associated files' are either placed under the (x64) ME80 folder or under D:\Program Data\Memorymoon\ME80. This allows me to keep everything in one place instead of treating my drives like a dumpster to be forced to rummage through for every individual plugin demanding it hide itself in locations where other plugins see it differently.

[Torchlight]

Please add preset handling within the plugin. If I use it in a DAW like Ableton, I can use the DAW to access the presets. But if I use it in Presonus Notion, this option is not available, so I'm stuck with the first preset, which admittedly sounds very good.

[D.J.]

Thank you Gunnare for the news and the detailed answers.
Where are usually located the presets in a Mac :
• Factory presets : Drive/Library/Audio/Presets/Memorymoon (Editor’s name)/ME80 (plug-in’s name)
• User presets : Drive/Users/Username/Library/Audio/Presets/ Memorymoon (Editor’s name)/ME80 (plug-in’s name)

And please, think of us, Mac users, Logic, Mainstage and Garageband users, we cannot use fxb. So yes, a preset manager (even a basic one) inside the ME80 would be a great improvement.

[EvilDragon]

The fact is, that there being no real standard as to where to put them seems to be more of the developer's mindset

There are developer guidelines that a lot of developers don't FOLLOW, that's the real problem. Microsoft explains very well where to put program data and user data and things like that. BTW if something ends up in ProgramData rather than Program Files, that is fine too - ProgramData is like Program Files, except shared between all users on the computer.

[gunnare]

The fact is, that there being no real standard as to where to put them seems to be more of the developer's mindset

There are developer guidelines that a lot of developers don't FOLLOW, that's the real problem. Microsoft explains very well where to put program data and user data and things like that. BTW if something ends up in ProgramData rather than Program Files, that is fine too - ProgramData is like Program Files, except shared between all users on the computer.

Thanks for the input. The only thing that has worked for me over the years, is that the dll. file has a folder with the same name as the dll. Both the folder and the dll in the same directory, and the dll will look for data in the folder. So it can have a relative path.

I found the preset location for the new Minitaur editor after a lot of detective work. It was in a Program data folder I have never seen before, hidden behind a lot of subfolders in My Documents. Some programs insist to be installed in the english "Program files". Some go to my Norway language "programfiler". Som programs store the data in "Shared program files". I forgot right now where it is. And lately I have seen program data stored in MyDocuments. I see no system in it. And why is MyDocuments in a different path on all my computers?

I hope Chris can put a ME80 folder with data next to the dll file. I think that would be the easiest way.

Was having fun yesterday with ME80 and accidentally discoverd that my Yamaha motif es7 actually does have aftertouch!!

Glad to hear that. There is no aftertouch in Roland FA6, Roland XA, Yamaha MX61 and Yamaha MOXF6. Lots of keyboards without aftertouch lately, so you are lucky.

All the best
gunnare

[gunnare]

Thank you Gunnare for the news and the detailed answers.
Where are usually located the presets in a Mac :
• Factory presets : Drive/Library/Audio/Presets/Memorymoon (Editor’s name)/ME80 (plug-in’s name)
• User presets : Drive/Users/Username/Library/Audio/Presets/ Memorymoon (Editor’s name)/ME80 (plug-in’s name)

And please, think of us, Mac users, Logic, Mainstage and Garageband users, we cannot use fxb. So yes, a preset manager (even a basic one) inside the ME80 would be a great improvement.

I think Chris has a surprise for Mac users. He started with a new native patch for all platforms, then he changed it into fxp and fxb for Mac. Not sure how he did it.

[EvilDragon]

Thanks for the input. The only thing that has worked for me over the years, is that the dll. file has a folder with the same name as the dll. Both the folder and the dll in the same directory, and the dll will look for data in the folder. So it can have a relative path.

This is good, but not on newer OS like Windows 10, which explicitly disallows WRITING to Program Files folder for regular users (gotta log in as admin to be able to do that, and even then it's not a walk in the part as you'd need to take folder ownership and change security settings and so on...), which might be important for users which (for whatever reasons) still use the default Steinberg VST folder path (C:\Program Files\Steinberg\VstPlugins)... Of course the solution would be to put the VST folder out of Program Files, but not everyone is doing that.

You gotta cover all your bases. Put them to Documents. The plugin should scan that if it cannot access files next to the DLL.

[EvilDragon]

Some programs insist to be installed in the english "Program files".

Ahh, it's amazing when some developers don't follow i18n guidelines and instead of just using the environment variable (%PROGRAMFILES%), they hardcode the path with their precious English?

I see no system in it. And why is MyDocuments in a different path on all my computers?

There is a system and I've explained it - there are developers who don't follow the system, that is all. If it's a single user path, it's always going to be different (depending on username). If it's a public folder (all users), it will ALWAYS BE THE SAME (UNLESS the user explicitly changes the location of it, which can be done). It has always been the same ever since Vista. Win XP had a different folder (Documents And Settings), this just got moved over to the Users folder with Vista onwards. Don't support XP - it's dead!

[gunnare]

Yes, I understand. But Documents is all over the place in Windows, they have a different path for every windows version. There is absolutely no system there. (Just read the latest reply, I understand the change was from winXP to Vista. A lot of users use winXP for music.)

The first thing I advice my students to do , is to never put anything in Documents, because the files will not be found it they change to another computer. So I force my students to use the folder I made the first time I started to use computers: C://soundfonts. They put all their files there. And it works. They can upgrade to a new computer , and all files will be found. No error messages. So C://ME80 might be illegal according to Windows, but it would work. Documents will not work. It is not a safe path.

All the best
gunnare

[EvilDragon]

Not true. Vista, W7, W8 and W10 all have EXACTLY THE SAME path to Documents. It's: C:\Users\<username>\Documents for current user, and C:\Users\Public\ for all users. This has not changed.

When moving stuff between computers a lot, this is EXACTLY why Roaming folder exists in AppData. https://askleo.com/whats-the-appdata-roaming-folder/ This is exactly made because of corporate environments.

You're wrong on this one. Documents WILL work, and Chris, being a great developer that he is, knows all this already, and can code to those guidelines. "Not a safe path" is not a good thing to say - it is EXACTLY the path to use for stuff like this, when coding your application properly to guidelines laid out by Microsoft.

A lot of users use winXP for music.

Not anymore, from what I can see. The number is really becoming very small now because W7 is much better at XP in just about EVERYTHING. XP is very much in minority these days. Not to mention driver and software support is dwindling. Plus, there's all this new hardware XP doesn't know how to utilize in best possible way because it's too damn old.

[gunnare]

Thanks!

I have got a lot of useful information. I know Chris will read it.

All the best
gunnare

[ethermusic1981]

Jeebus just let the man do his thing.

[BBFG#]

The fact is, that there being no real standard as to where to put them seems to be more of the developer's mindset

There are developer guidelines that a lot of developers don't FOLLOW, that's the real problem. Microsoft explains very well where to put program data and user data and things like that. BTW if something ends up in ProgramData rather than Program Files, that is fine too - ProgramData is like Program Files, except shared between all users on the computer.

Oddly enough, the others justify their procedure as the way to interpret MS guidelines.
And this is getting even worse with the new paths created in addition for VST3 support.

In any event, all of these are short-sighted in the idea of everyone having one massive hard drive that everyone demands to occupy. So regardless of pointed blame, everyone is missing the point that many of us want to decide the place they go (and I can't emphasize this enough, on a different drive) just so we have everything where we can find it.

[BBFG#]

This is good, but not on newer OS like Windows 10, which explicitly disallows WRITING to Program Files folder for regular users (gotta log in as admin to be able to do that, and even then it's not a walk in the part as you'd need to take folder ownership and change security settings and so on...), which might be important for users which (for whatever reasons) still use the default Steinberg VST folder path (C:\Program Files\Steinberg\VstPlugins)... Of course the solution would be to put the VST folder out of Program Files, but not everyone is doing that.

You gotta cover all your bases. Put them to Documents. The plugin should scan that if it cannot access files next to the DLL.

Win 10 has not been a problem at all for me in that regard. I have most everything loaded where I want, which is the D drive. The problem that can occur happens with updates, specifically those three companies I mentioned. Cakewalk/Sonar being the worse, since no matter where they are, it will load samples across the drive like the Easter bunny dancing through your yard, with a few in your chosen path. Sometimes it simply ignores all previous installations and simply creates it own wherever it wants.

Installers should always have the option to choose the path, updates need to always scan where those paths are.