Choose Installation folder in installer

[rafaelferreiraql]

The request itself This should be a no brainer; let the user pick installation folder when installing Surge, instead of having it install in a generic, undisclosed folder. Surge already has a portable mode, so that should not be a challenge.

Now, here's my experience installing 1.7.0 (on Windows):

I opened the installer, hoping that at the very least, Surge would let me install it in the folder I keep the VST2 in (which is a custom folder where I keep all of my other VST in, 64-bit, 32-bit, VST2, VST3, what gives you). But instead, it prompted me nothing about destination folder and just installed itself where it wanted. After the initial confusion, I read on the manual that Surge has a "portable mode", and that the user had to manually do a bit of tweaking to get working. Thankfully, that is definitely not a lot of work (would be much better if it was no work at all, but i'll take it), but there remained the problem that the installer didn't actually inform me where the VST3 was installed in the first place. I had to guess it was installed on Program Files/Common Files/VST3 (and not, say, Program Files/VstPlugins, Program Files/VST or something similar), and that took me a little while.

All in all, happy ending, I got Surge to work, on the folder it was meant to be. But it shouldn't take me this much work, and I'm posting this in hopes that the next time I have to install it will be smoother. By the way, thank you Surge Synth Team for all the hard work, 1.7.0 is amazing.

[baconpaul]

Do you know innosetup well? None of us really do.

We all agree the current setup isn't that great, but since you said fixing it should not be a challenge, can you fix it? That would be super welcome!

[baconpaul]

And thanks for the kind words on the synth

[mkruselj]

VST2 is not distributed any longer in the binaries, so there is no need to choose a folder for it. For VST3, it goes to Steinberg decided default VST3 folder in Common Files\VST3, where it should be. It is generally not advised to move VST3s out of this folder, it's where all hosts that support VST3 are looking into.

[baconpaul]

yeah I agree we have the right defaults @mkruselj but if someone came along who knew inno and made it so at the start of the install chain you had a branch of "standard install" or "custom portable install" then in custom portable install prompted for a folder and set up portable with a full install rather than a junction, I think that would be cool.

That sounds like a challenge to me, but hey, I'm a mac user. Since it doesn't sound like a challenge to @rafaelferreiraql though perhaps they could help us get there?

[mkruselj]

Yeah that would be cool, no question about it. It goes well beyond my knowledge of Inno, though.

[baconpaul]

Yeah would totally welcome the help!!

[rafaelferreiraql]

Hey :[] I just assumed it would be easy, since picking installation folder is so standard for setup processes, including software of far inferior quality than this one.

[baconpaul]

I’m sure it is if you know how windows installers work! We are all a bit blind on that and you gave us hope that you knew .... if we can recruit a windows dev to help that would be super useful

[mkruselj]

Final decision has been to not allow to change the VST3 install folder, instead disclose it on the final page of the installer where it is to be found.

[lmnoop]

First I was confused about not being able to set the installation directory. Then I found the Nightly ZIP releases and happily skipped the installer altogether only to discover my host (Renoise) specifically doesn't allow you to define a location for VST3s. There's only a simple on/off toggle there. Surge being my first VST3 ever, I had to dig deeper and what I found in https://helpcenter.steinberg.de/hc/en-us/articles/115000177084-VST-plug-in-locations-on-Windows was:

VST3 Plug-in path

The VST3 format has a dedicated installation path all VST3 plug-ins must comply with. All your VST3 plug-ins should be installed here:

• C:\Program Files\Common Files\VST3
• 32-bit VST3 plug-ins on 64-bit Windows: C:\Program Files (x86)\Common Files\VST3

Wow. So, that's dumb and in no way the Surge team's fault. Is that supposed to be hardcoded to "C:" or does %CommonProgramFiles% work if your system drive letter is something else? As a user, what you might want to do instead of building a potentially sizeable VST3 library on the system drive (which is often hurting for free space to begin with), is relocating it via symlinking. To do that, run cmd.exe as an administrator and go:

cd %CommonProgramFiles%
mklink /d VST3 "E:\CoolStuff\VST3"

Where the latter path is of course where you actually want to store your VST3s.

To confirm it worked, simply go dir and you should see something like:

<DIR>          microsoft shared
<DIR>          Propellerhead Software
<DIR>          Services
<DIR>          System
<SYMLINKD>     VST3 [E:\CoolStuff\VST3]

Now your target directory looks like the expected VST3 path to hosts, plug-ins and installers which, as per the VST3 spec, have no incentive to make the path customizeable.

[mkruselj]

You can either change %CommonProgramFiles%, or (IMHO better) just symlink whatever folder on whatever drive to C:\Program Files\Common Files\VST3.

Also, VST2 was plagued with "I can't see my plugin that I've just installed" issues by many many users throughout the years, because different plugin vendors had different ideas about where the plugin should go. So this is now consolidated for VST3. It is far from dumb.

[lmnoop]

Well, dumbing it down for VST3 does solve the dumbnesses of the past as you describe. My frustration stemmed from the absense of the option and not knowing it was rooted in the spec. It looks like this could result in a more manageable and portable library after all.

[xparq]

VST2 was plagued with "I can't see my plugin that I've just installed" issues by many many users throughout the years, because different plugin vendors had different ideas about where the plugin should go. So this is now consolidated for VST3. It is far from dumb.

Of course it was plagued, but not because of the lack of a mandatory central location, but because of the lack of a standard default location! VST3 fell off the other side of the horse, and instead of fixing the situation by just mandating a standard default, it actually removed all the flexibility VST2 nicely allowed (albeit kinda accidentally...) for users who actually knew what they were doing.

That is the dumb part (as others have said). It's a really lazy "solution" in the VST specs. Adding a standard location (again: as a mandatory default, rather than an exclusive fixed one) in itself would have been a welcome improvement. They just overshot and now all the portable setups got out of the frying pan, into the fire...

Thankfully, most VST3 projects do understand this and still allow custom destinations, where they continue to work just fine. (For the record: basically none of my VST3s are kept in their super annoyingly hardwired default location at the system drive, but are on my portable SSD along with most of the prod. material, where they truly belong (in case of a robust portable setup), e.g. with all the VST2s. (Even some that don't offer a custom location still work fine after I just move them manually.) So, the nicer VST3 suppliers gently keep fixing the specs for us...

And so do the DAWs: the ones I use, from big to small (Ableton, FL, S1, Reaper, MuTools) have zero issues supporting arbitrary custom VST3 locations, they just work fine with whatever you configure, as expected (regardless of what the narrow-minded Steinberg specs have concocted).

(Mandating a single location in the VST3 specs. can make life easier, with all the factory data folders and user stuff etc. confined to one fixed path (which still isn't true, BTW: e.g. user-level state/data can still be problematic to manage, especially when shared across Windows users). But that's just too much simplification, costing valuable flexibility.)

---

As to Surge:

AFAIK, it has otherwise had basically everything to do the right thing (to support portable installs). So, removing freedom and explicitly preventing a flexible configuration does not seem to be the best choice. Please don't join those few rigid VSTs that need manual intervention to fix their installation layout for portable studio setups, forcing super fragile, tedious, and generally undocumented manual symlinking/junctioning to relocate, which may or may not work at best (as some VTS3s silently install parts all over the system drive, not just in the VST3 folder).

(The VST3 specs is not law that you must obey at all cost. You are free to be smarter, when it has no adverse effects. Even the HTML specs have similar pointless restrictions, which get properly ignored by every single existing browser (e.g. the placement of the STYLE element), because a) that's the right thing, b) provided that it doesn't conflict with the existing scenario anyway.)

[baconpaul]

Fl doesn’t support custom Vst3 locations only custom vst2 locations and comprises a big part of our user base, at least as of 6 weeks ago. How did you make it do otherwise?

[mkruselj]

I can only see that working through a symlinked folder to C:\Program Files\Common Files\VST3. FL plugin manager itself doesn't ever allow me to add a custom VST3 folder path (by that I mean even if I add one and scan it, it doesn't find any VST3s unless they're in C\pf\cf\vst3).

Also wait, MuLAB doesn't support VST3 yet?

[xparq]

Fl doesn’t support custom Vst3 locations only custom vst2 locations and comprises a big part of our user base, at least as of 6 weeks ago. How did you make it do otherwise?

Thanks for pointing it out, that one may be an oversight, and I may be wrong.

But if FL does miss the mark on that, Surge could still freely allow a custom path for everyone else, who may need that. All the FL users could happily keep using the usual default.

BTW, an installer option may not even be the best way, perhaps. For "power users" editing some config file could do fine, too. (That way preventing users cluelessly choosing some random custom folder on install.)

[xparq]

Also wait, MuLAB doesn't support VST3 yet?

Correct, thanks, I just hastily listed all the DAWs around. (See my reply to @baconpaul how it doesn't change the point, though.)

[mkruselj]

So far users who really needed a portable Surge have appreciated the current way we have it implemented. I guess this tells that it is very likely that people requiring portable software are 1. intermediate or power users and 2. by virtue of being intermediate or power users, have no problems with symlinks either...

We might go the Reaper/u-he portable install way for XT. We'll see. This does put the burden on the user to point the DAW to that folder, and FL and Renoise most definitely then won't work with this.

[baconpaul]

Right well we are installing in 3 days so nothing will change for 19 And yeah @lunakid these daw details with vst3 are ... well challenging perhaps? But maybe with xt we can present an option at the top like “i know what I’m doing and don’t use fruity loops and won’t ask for help let but please me set up my paths” or “i want surge to work please install it in a way that will” then see how many users in camp 1 show up in the discord help channel....

since we are volunteers I’ve always thought the installer doesn’t have a won’t work option was a good choice for our support burden but maybe I’m wrong and I don’t use windows anyway!

[xparq]

So far users who really needed a portable Surge have appreciated the current way we have it implemented. I guess this tells that it is very likely that people requiring portable software are 1. intermediate or power users and 2. by virtue of being intermediate or power users, have no problems with symlinks either...

The problem with symlinking is not with the users, but with the systems, of course. If you move stuff around and plug it in a USB slot at a host, and then you need to tamper its system drive to create junctions, is not quite what portable software really means. That's rather just a hack that can make (almost any) non-portable software work elsewere too, in case you may have permission to surgically attach it to a host system, case by case.

(I'm not yet familiar with Surge, I don't know what "the current way we have implemented" means for supporting portable installations, I just saw its portability mentioned in this thread by others.)

[baconpaul]

The non portable software here is the spec. Surge works perfectly portably without any symlinks in reaper which does t require the vst3 location to be the spec location.

[mkruselj]

So currently, Surge creates junctions in the folder where VST3 is that point to ProgramData\Surge (factory data) and Documents\Surge (user data). Users can manually remove those junctions and place the factory data folder inside the VST3 folder (name it SurgeData), and do the same for user folder (named SurgeUserData). Will work portably just fine like this.

[xparq]

@baconpaul, @mkruselj thanks guys, just tried that, and that's indeed enough for a proper portable setup, more than what many other VST3s offer (i.e. nothing :) ), indeed.

Cheers!

[baconpaul]

Great!

[SpeakingColors]

Final decision has been to not allow to change the VST3 install folder, instead disclose it on the final page of the installer where it is to be found.

I get y'all aren't experts in Inno and I am not either but... a simple Google search told me how... https://jrsoftware.org/ishelp/index.php?topic=setup_DisableDirPage

That parameter is set to Auto by Default. What you want, is to set it to No by adding AutoDisableDirPage to the config file. And now we can choose a custom path.

Now that you know how, can you please add that simple line to the file?

Thank you!

[baconpaul]

Please read this issue

https://github.com/surge-synthesizer/surge/issues/4818

If we did, the installer would allow a broken and non-spec install. That wouldn't bother us except it will break FL which is a large part of our user base.

[mkruselj]

@SpeakingColors It is absolutely not the case of not knowing InnoSetup enough. The implication that we don't know it was unnecessary and frankly rude. It was our decision not to allow it and we will stick by it.