MU.LAB is an alternative, state of the art software application for OSX and Windows, transforming your computer into a rich virtual music studio! It does not overwhelm you with a complex feature set, in which you can get lost.
![](/uploads/1/2/6/3/126336384/830007363.jpg)
Thanks PrapperI did have a chat about the integration of the 32/64bit versions for ease of use for the user. But Jo, the dev, pointed out that there's differences in the file system. I've tried locating the discussion but can't find it now. The end result was that the file system needed to be kept seperate. So it may not work as you expected?If not possible to do it this way then two seperate launchers is fine. Would it install updates on this link:When a new stable update is released this link is diverted to the MuTools site instead of the '/cedar' location. Sl23integration of the 32/64bit versionsI saw your discussions on KVR but I'm still unconvinced as the only difference between the contents of mulab-win.zip & mulab-win64.zip are two files: MuLab.exe & AppBinLibResample.Dll.
Nothing changes in the AppMuLab folder between runs so swapping those files according to OS version would seem to be the easiest way to do it. As we are in the Beta Testing forum, I suggest we just give it a try & test it. Are you up for that?A good point is also made re: Audio/MIDI setup which I don't think there's any way around in a portable situation but I can get it to remember the settings per computer once they're made, as long as each computer has a different name.sl23When a new stable update is released this link is divertedHow does that work? Or do you mean that's what you'd like to happen?I'm just going to do it as an 'x.x.x' version as the download filename stays the same with updates so it'll always pick up the latest one. If you want to stay at the cutting edge you'll have to upgrade manually I'm afraid. Ok, this is the beta link:This is the normal d/l link:I didn't expect it to be possible, it was just a suggestion that if it were possible could you do it. Trouble is as you said the version number for the beta changes, so it's useless.
But if I asked the dev to keep the d/l link/name static and he agrees, could you do it? It's a long shot but he might.When you d/l a beta it's from the first link above.
If the very next update, or if the latest beta goes official, this 'cedar' link is diverted to the main MuTools website. Only, I can't remember if it goes to the d/l page or the Homepage? I'll ask in the Forum with a link here to see what the Jo(the dev) thinks.Is that any help?Oh, one more thing, I'll have to find out first, but as I have purchased a 'UL' licence, can that be saved too so I don't need to keep installing on different computers? I know it only means 4 PC's for me personally, but if any of those need windows reinstalled or others have more, it could be useful.
![Download Download](/uploads/1/2/6/3/126336384/622828848.jpg)
Not sure about MuLab's Licensing though might not be allowed? I've transferred my settings and User folder to the PA version and this seems to work fine, couple questions though:1.
VST folder is currently in my original install folder of MuLab, is it safe to place it in MuLabPortable/Data/VSTPlugins?2. When updating the app will MuLab's User folder be affected? Normally when an update is performed manually I only update the.exe and the App folder. I'll mostly be doing manual updates to beta releases, but when an official version appears I'll re-use the installer so need to know about the User folder.Once I'm happy with it I'll install the 64bit version and see how it works.Thanks prapper this is great. Copied settings and User folder all ok. Still sorting all my VST's out as got so many. But they appear in Mulab ok.I had to reinstall key so can't be installed to registry.
Perhaps it is as you said installed to one of Mulab's folders. Will try this on another pc and let you know.I'm also using CubicExplorerPortable and whilst in the User folder adding a Mux preset into the folder I started MuLab and the entire User folder apart from the location I was in was lost! Is this a launcher issue or CE? Unfortunately I don't think it's either.
In any of the apps where a folder is moved, if a sub-folder is held open by any file manager or you have a file open in that folder when it's moved, there will be problems. It's unfortunate that the User folder has to move in this app. I know that in UserSettingsPreferredFilesAndFolders.Txt you can redirect UserLibrary but I found that to be a bit unreliable according to whether you used Save or Save As. & I always ended up with two versions, one in AppMuLab & one in Data, which also creates a problem.Is there a lot of manual work to be done in there?
Sl23I assume there's nothing can be done about this?I know 'don't do that' is rarely a good answer in this sort of situation but it's the only one I can think of at the moment. Sorry about that:-)sl23plan to store samples hereCan you put them somewhere outside the User folder? If they're referenced by your projects, as long as you store the project files in MuLab's default location, absolute paths in these files are updated (see the. Or perhaps they're for your synth designs? Are there other files (Mux presets) that should be updated?
I must admit, I didn't investigate the Mux stuff.Even if the redirection was 100% reliable, it only applies to the Library so it would still mean the Audio folder containing your recordings would have to be moved, so it's only half a solution anyway. It's a shame there's not a more robust way of redirecting the entire User folder but I suppose there's a reason.sl23I had the original folder stillGlad to hear it, always a sensible move. Dr, Dr, my arm hurts when I do this.Well, don't do that then!:lol::lol:I thought you'd say something like that, Ok, I'll try not to.
Like I said I'll keep a backup anyway. I'll also keep samples in the Data folder instead of User. That's where I'm going to keep VST's anyway so they can go together I suppose, not a problem. Saves them from being moved unnecessarily too.Mux presets could possibly get updated at a later date and then saved in the User/Library/Mux folder.
But any samples, VST's or waveforms used in the Mux can be located anywhere I believe. I'm not a seasoned user of MuLab it's still fairly new to me.I'm curious, why has the launcher been made to move the folders/settings in the first place? When the user is in the folder it's so easy to lose all these settings. The PAinstaller could be made to install to a temp directory and then move only the necessary files/folders to the final install location. That way nothing gets moved each start up of an app and nothing can get lost. Just sorta makes more sense than the way it's done now?But then what do I know?Thanks again for this prapper.btw, I'm testing the 32bit version on a win7HP 64bit laptop.
When I asked why the Launcher moves the files instead of installing around the existing install, I meant it as a possible suggestion as much as a question. Can it work that way? Is it better that way? It seems to me to be safer for your files/apps to perform as I suggest rather than moving folders that could potentially be lost in the process.
Obviously stuff like registry and AppData etc, will have to be moved, but moving settings and other stuff doesn't seem good practice to me! If I were to design PA's Launcher, not that I could mind you, I'd make it move the least amount of files necessary and have all the user stuff backed up in another folder. Sorry hope you don't mind the criticism, just my humble opinionOk, regarding the MuLabPortable setup. I'm confused what you're referring to. Are you asking or suggesting that only the Library folder be moved? Currently the whole User folder moves but you said you can't do that???
I've just double checked and that is exactly what's happening. Isn't that what you meant to happen? The last thing I want is for things to start getting messy.
It's a shame the whole User folder can't be given a specified location.I'm quite happy to leave it as is personally, but I can't see this becoming an official release in light of the potential hazard. I really don't know what the best way to proceed is to be honest.
Could you give a detailed description of how files will be managed if just Library is moved? How exactly it would work. What this would mean for MuLab as an app and the user. Just so I now what's going on beforehand. That would help.ThanksScott. File are only moved when the app itself, MuLab in this case, doesn't provide any way to redirect them. Lots of apps provide a way to point the app to its settings either via a command line switch (Mozilla apps) or environment variable (Inkscape, which we helped the developers setup).
Some apps we mod slightly to allow for one of these to work (gPodder). But with some apps, they only support having the settings in a specific location in relation to their EXE when in their built-in 'portable' mode, generally within their AppAppName directory. For these, we need to move the settings back and forth to the Data directory.The reasons for this are primarily two-fold. First, it's so that all an app's data is contained in the AppNamePortableData directory for organizational reasons. That way, the PortableApps.com Platform can easily backup your data from ALL your portable apps quickly and easily (since it's all in a consistent location) rather than needing to backup all the apps themselves as well.
This makes for quicker backups and (hopefully) makes it easier for users to backup their data more often. If their drive dies or gets corrupted, they have their data and can easily re-install the apps right from the app store and be right back up and running.Second, it's for safe and easy upgrades. Generally, on an upgrade, the AppNamePortableApp directory gets wiped out and replaced with the new version.
If you had user data within it, it would be lost. Now, we preserve specific paths in their on some upgrades for things like plugins for some apps, but those are specific cases. And those aren't backed up when you backup just your user settings.Finally, as a secondary reason and a bit of an add-on to the second reason, you can reset an app just by deleting its Data directory.
It's a handy convenience thing for advanced users without having to uninstall and reinstall an app and it'll be easier to do from the platform soon, too.One last note, the moving of files we mention, it's a simple 'rename' via the Windows API so it's about as safe as it gets. Either the directory gets renamed from AppAppNameSomething to DataSomethingElse and all the files exist there, or it doesn't and they remain at AppAppNameSomething. The files are moved individually so there's no danger of them getting lost. Sl23Are you asking or suggesting that only the Library folder be moved?No, exactly the opposite. What I mean by 'redirecting' is telling the app to look for the library in a different location to the default ie; in the DataUser folder. If a folder has been 'redirected' it's actually not moving.What will happen is, the Library will stay in DataUser while the app is running, except for the MuSession subdirectory which will have to be moved to the app directory, as will the UserAudio & UserSettings folders. I've also tweaked it so that folders that are going to be moved when the app starts begin with an underscore so it's easier to see what's going to happen & what to avoid.So, when the app is closed, the DataUser folder would look like this:UserAudioSettingsLibraryMuSessionMuSynthMuxWaveformsSo the Library can stay where it is.
It's probably easier to see it when it's working. It's a fully automatic upgrade & I'd say it was a better solution.How's the 64 bit testing going? Just d/l the Dev Test 2, I'll let you know Monday, possibly Tuesday, about how this is going and I'll also try it out on a second machine to let you know if it takes the License Key with it.And yes, I'm interested in using this still, I'd prefer it if this issue with the 'open file/folder causing a complete loss of that folder' could be sorted but I'd still use it. Is that problem inherent in all PA apps then?I've noticed that the 64bit version is still on Dev Test 1, is that right?Thanks againEDIT: quick test reveals this isn't the way to go! Trying to add some User Mux stuff but not appearing as Library is in wrong place I assume. Going back to Dev Test 1. The problem wasn't with me finding the Library folder but MuLab.
While editing a synth in the Mux I wanted to add a User Preset, but I couldn't find it. I then realised that the whole User section and the Factory parent directory wasn't listed. All the stuff included in the Factory folder was listed just not the actual 'Factory' parent folder if that makes sense.For example:+ Factory- + Effects- + InstrumentsThe Factory or User wasn't there just the Effects and Instruments subfolders of the Factory folder.Not happy! Lost load of stuff again managed to recover main Mux files so not too bad. I think this needs sorting before it can be used. It's part of using the app to need access to the apps folders and it's just too risky and easy to lose a whole load of work you spent hours on only to lose because you forget to back up straight away or forget to close the open file/folder. I'd like to use this though so let's hope kAlug finds a solution.
![Mutools mux ul 7.74 download free full Mutools mux ul 7.74 download free full](/uploads/1/2/6/3/126336384/615095109.png)
Regarding, I did send the files but haven't heard anything in reply.As the 'bug' still exists, anything I do won't get us any further forward unless it's a custom launcher (as the problem is PAL only) but if it's necessary to keep files open while the app is restarted, even that isn't much of an improvement.The app seems to function well in a portable situation by itself (relative paths etc.) so the only thing you're losing by not being in PA format is the data backup from the PA menu.But I haven't dropped it. In my attempts to lose data on purpose, I performed the following tests:1. Opened a Mux file in Notepad then started MuLab - Received error message.2. Opened User folder then started MuLab - Received error message.3. Started MuLab, opened User folder, closed MuLab - No error but closed fine and moved User folder back to Data. EDIT: second test recieved error message. First test only had User open, second had User/Library open.4.
Started MuLab, opened Mux file in Notepad, closed MuLab - MuLab closed ok but didn't move User folder until I clicked OK on the error message.All seems ok so far. Is there any other way I should test?Btw, I moved my VST's to PortableApps/CommonFiles/VST's/ this way I have a common place for apps to use them and less chance of them being lost. I did ask about keeping stuff here and someone replied saying it was ok, just to make sure, could you confirm this as a safe location?
I also moved several other common files like samples and roms here too.Thanks prapperEDIT:With the new v5 there's another file added to the MuLab folder. 'MuLab.ID File' shouldn't make any difference to the way it currently works but wasn't sure you were aware of it.EDIT:I've asked Jo, the dev, if he's ok with this and there's no problem as long as it doesn't go against the license terms. Also, I've asked if he would consider changing the link for the latest version so the PAL would be able to d/l the very latest updates. I'm not too sure how that works so might help to specify anything that he needs to do.He is VERY busy though, so it's not certain he'll put the time and effort in, which is understandable. Fingers crossed thoughAs this isn't OS or freeware does that mean there's no chance of it becoming official?EDIT:Jo has given a link for the if it's any help to you?
Probably not needed but thought I'd post it anyway. Sl23In my attempts to lose dataAll sounds good. I repeated all your tests & no data was lost although having folders open in Windows Explorer will lock them too.
Have you moved it to a different drive or folder yet? How about the 64 bit version?sl23I moved my VST'sA good idea, it shouldn't be a problem at all.sl23MuLab.IDI just checked v5. Is that the registration info? If so, I should do DT4 & move it back to Data.
Can you confirm?sl23link for the latest versionThe installer gets the latest version now, what needs changing? As to the wisdom of doing that with an 'official' release, I'm not so sure. Any questions like that are for John I think. I only use these apps on my internal drive. Occasionally use some on USB but rare.
So, no not tried that. 64bit version is also something I don't use as most of my VST's are 32bit. I have performed the same tests though and had no problems.MuLab.ID file is, I think, for registration. I realise now that it will indeed need moving also.Regarding updates, do you mean that this launcher will install and keep up to date with the very latest beta release? If so then you need to know that Jo, the dev, does not want this. He would like the latest official release only. Though there's rarely much of a reason to think the beta as unstable in any way from my experience.
There obviously are issues that appear but nothing major, at least, not yet!I suppose the reason is that if newcomers d/l the launcher which installs latest beta and it coincides with a 'dodgy' update, it could put off potential customers. Understandable.Personally I'd like it to update to latest beta, but expect you'll have to change that now? Up to you.One thing though, as I said, my VST's are 32bit but now I've installed the 64bit 'plugin' I can't start the 32bit version from the menu as the launcher doesn't give a choice.
In this instance I'd say that it'd be best to have both appear as seperate entries? Preferably in the same MuLabPortable folder something like LibreOffice perhaps? Sl23I only use these apps on my internal drive.I don't understand why you want the additional overhead of a launcher if that's the casesl23MuLab.ID file is, I think, for registration.OK, I'll make sure it gets moved.sl23this launcher will install and keep up to date with the very latest beta release?No, official releases only. I think it should stay that way too.sl23now I've installed the 64bit 'plugin' I can't start the 32bit version from the menuNot sure what you mean. If the 64 bit version is installed it shouldn't kick in until you run it on a 64 bit system.
Is that not the required behavior? Thanks againJust curious, you asked why I wanted the extra overhead, yet how many of these apps are already fully portable and still have a launcher? My primary app has to be CubicExplorerPortable yet it's a fully portable app so why did it get added? It's all about integration to the PAMenu isn't it? The Menu adds extra functions like auto updater, settings backup and the can't wait to be released file-associations.Though with CEP I use it's built in updater as it updates to betas which add and fix many things. If Mulab had this updater then I probably wouldn't ask for the launcherActually I would still use it as I do CE.
Ahem.Is there any chance of a 64bit version as a seperate launcher please?Also, I asked the dev of if it were possible to make the app portable. He says no, But I thought maybe you'd know more about it, possibly? I can't believe his app can't be made portable, it's not a system dependant app is it?
Even DeamonToolsLite has been made portable and that's got to be far more system dependant than something like jBridge.I was just wondering if you'd mind having a look to see if there's any possibility of it being made portable. I'd prefer to use the 64bit version of MuLab and the VST's I have are 99% 32bit so I'd need jBridge to use them. Thing is I really dislike installing anything if I can help it.As far as I know, once the app has made the bridging files it isn't needed unless you want to make more. I tried extracting the files with UniExtract which worked and even made the files but I can't remember what went wrong now. I'll try again see what happens.ThanksEDIT:Ok, I tried it again and the only problem so far is that for every VST jBridge scans, an error message appears saying it can't find the proxy.dll, which is in the jBridge folder. The full install appears to go to C:/ProgramFiles on a Win7 HP64 laptop. But the real problem is the Bridged VST's.
They will look for the original VST's in the location they were in at the time the Bridged files were created. Is there a way round that using the PALauncher? For most computing tasks, there's not really a ton of difference between the two. On Windows, the biggest benefits of 64-bit are at the OS level since you get access to more RAM (4GB for 32-bit vs 192GB for 64-bit on Windows Pro 7 or up), the virtualization extensions (better VM performance) in the newer CPUs, and (mark areas of RAM as not able to execute for better protection). None of these apply directly to apps, though.What they can get apps is access to more than 2GB of RAM and/or better performance. The thing is, most apps don't need 2GB of RAM or even close to it. The exceptions being video editing, editing very large image files, or working with large sets of data for processing and similar endeavors.On the performance side, the difference between 32-bit and 64-bit isn't much in most cases.
You'd think it would be. It's double the bits so it must be double the performance, right?
It does improve some CPU-limited operations of applications when working with the wider bit-path can help. But, even with an app that is totally CPU-limited, the performance gains are modest.7-Zip, for example, which is doing lots of intensive compression algorithms is CPU-limited.
But the 64-bit version only yields a performance gain of up to 7% in testing. And then even only on some files. But, since some people compress GBs of data with 7-Zip, we thought we'd dual mode the app (32-bit and 64-bit in one package). The fact that it's a small app also factored in.Realistically, you won't even notice the difference in normal operation of regular apps.
You're likely looking at no performance gain in most of them. Or, at least, no noticeable one. Even 7-Zip's 'large' difference between the two is only noticeable when working with very large compressed filed. As for 32-bit using no more than 3-3.5GB, they're talking about the operating system. 32-bit Windows maxes out at 4GB of RAM. 64-bit can make use of more.
Of course, 64-bit Windows and all 64-bit apps will use up more RAM when running. On your system, it's a wash.
Whatever version of Windows you have installed is fine, memory-wise.When in use, it doesn't matter if you use MP3s or WAVs as they have to be decoded to be used. That said, you're likely just fine.As has been said, unless you have specifically run into a problem that requires you to use 64-bit, you don't.need. to use 64-bit. Very, very few things need 64-bit.
Ok thanks for the advice, it's been hard finding someone that can help in this area.Most just say either 'get the best you can afford' or 'depends how you use it' rather unhelpful. Thing is my laptop is an Acer S3 and though it has 2 cores and HyperThreading, Jo, the dev of MuLab, recommended keeping one core seperate for the GUI for 'lightning fast response' I think he said. Because there were a couple issues with non-responsive R-clicks on occasion.Coupled with the fact HT isn't supported, I'm running ML on one core!!! When I started making a composition with only two tracks the CPU load was averaged at 45%!
That was a four bar loop, not much at all. Hence, I thought I'd need the 64bit version to eek out a bit more power? Honestly, I would install and try it to see how it works. All the theory in the world means almost nothing when it comes to a specific app.
A ton of 64-bit apps lag their 32-bit counterparts because they aren't taking advantage of what 64-bit offers. A ton of others offer a 32-bit and 64-bit version even though the 64-bit version offers nothing that users actually need.
And then others make proper use of 64-bit.So, install and try both. See if there is any difference when doing the exact same things. But when running an app like a DAW and loading VST's doesn't that mean that although each uses only a little CPU/RAM it adds up and therefore could well use more than remains on a 32bit system.So if 4GB RAM is installed then you are limited on how many VST's/Samples/Tracks can be used before you run out? Some VST's aren't fully optimised for CPU or RAM and this can be a potential problem for 32bit systems. Whereas 64bit doesn't have this limitation.I think the simplest solution is to use only 64bit VST's, so I'm going to sort out my collections and move over to that I think.Thanks for your help John. Are you saying that after the OS (Win7 HP64) uses it's share of RAM (around 1.5-2GB?) then the remaining 2-2.5GB is more than enough to make intensive compositions? I have little experience with making music on PC so this has puzzled me for ages.I always thought that with a DAW loaded with idk, say 15-20(?) VST's for the synths, samplers, FX, mastering, that 4GB would be rather skimpy?Most people on KVRAudio forum that mention their specs all have twice that or more???
Like you say though it's only when I need more should I worry about it!Keep in mind that when I load MuDrum in MuLab, the built in drum sample player, and then just click one pad RAM usage goes from 36% up to 40%!!!There is a bit of a discussion on the effect on system resources at KVR so I'll ask a bit more there about RAM and what others find necessary. Though it depends on how you make music I understand that.Thanks JohnEDIT:An example would be the which states a minimum requirement of 1GB. I'm not sure if you're still up for this prapper, but MuLab is now on v6 and there has been a change that could make it easier with regards to the User folder.
Basically, you can specify it's location in MuLab, would this help solve the issue about losing data if files/folders are open in other apps? Can the MuLabPortable Launcher use the User folder if it doesn't move it from MuLab/Data/ or doesn't the launcher work that way?It may be that due to the file LibResample.Dll that two user folders would be necessary, unless there's another way to do it, like swap this file around for 32 or 64 bit.One other thing, about the launcher, not MuLab, is there any way us users can change the link for updating a specific app? The purpose of this could be for auto updating apps that cannot be configured to update to beta's but the user would want that. For example, the link to update the stable version of Mulab is:Do PALaunchers ignore version numbering when looking for links?
Because this obviously changes. I suppose it must know this number is greater than a previous version so to some extent it doesn't, but the link to download changes depending on number.Anyway, what I'm asking is that to update to a new BETA version would be best so as to use the latest features, but the problem is that the beta page changes location.
MuLabv5 used a Cedar folder, MuLabv6 uses a different location called Forsythia. So to create a launcher that updates to beta isn't possible.
Unless there's a way to change the location manually.This would be helpful for easier updating if it can be done. Yes, I'm still up for itwould this help solve the issue about losing data if files/folders are open in other apps? Can the MuLabPortable Launcher use the User folder if it doesn't move itYes & yes.It may be that due to the file LibResample.Dll that two user folders would be necessaryI don't understand. As we're only dealing with the 32-bit version here, why would that be an issue?is there any way us users can change the link for updating a specific app?Only by editing installer.ini & recompiling the installer.Do PALaunchers ignore version numbering when looking for links?Not sure I understand. You mean PA installers? This installer downloads a generically named file that always contains the latest version which is entirely under the control of the MuLab server.
PA installers can't 'look' for links (see above re: installer.ini).update to a new BETA version would be best so as to use the latest features, but the problem is that the beta page changes location. Unless there's a way to change the location manuallyYes there is but see above re: installer.ini.Do you still want an update to test? Thanks for your interest prapper, I'm hoping to make the constant updates a bit easier, and perhaps others will find this useful as well.
I know this will never be official but to be able to use it and adapt it to update beta's would make life a little more tolerable, so yes, I am definitely interested in testing itRe: LibResample.dll - Sorry, I was assuming that the launcher would detect the OS (32/64) and run appropriate version, but I forgot about the VST issue so probably best to use two seperate versions? Or maybe do a 'dual' launcher setup within a single MuLabPortable folder, in a similar fashion as LibreOfficePortable has various launchers depending on which app to start.
Then just setup two User folders within MuLabPortable/Data by having User32 and User64 to cover the above.dll file. This would then suit anyone wanting either or both versions. I plan on eventually moving to the 64bit version anyway.Re: Version numbering in links - If you go to MuLab download page and hover the link, you'll see it as stated above, with a number. But when it's updated, that number will obviously change, does that cause issues with how the PAInstaller looks for updates?Re: BETA updates/changing links - This is the current beta location and the current version is mulab-6-4-14-win32-exe.zip. So when looking for updates, the file to download will change due to numbering, does the updater/installer only look for newer file at the Forsythia location? Is it difficult to change from forsythia to a future name?
Probably another tree name! Cedar was the name for M5 location, so it will probably change again for M7. Sorry for the noob question, but what does compiling actually consist of?
From what I can tell, the launcher packager does a lot for you so I imagine it's a matter of going through a process much like installation?EDIT: One thing I'm not sure of though is that although you can specify the User location it isn't relative, does the Launcher solve that problem? OK, I read the entire thread again to try & get back up to speed with what's going on here!The subject of 64-bits has already been discussed at length & it seems like sticking with 32-bit is still the way to go.I'm not keen on the idea of using betas, especially as this isn't even a version-specific package ie: who knows what the hell it's going to download! Theoretically of course but you get the point. In a previous post you said.Regarding updates, do you mean that this launcher will install and keep up to date with the very latest beta release? If so then you need to know that Jo, the dev, does not want this. He would like the latest official release only.It never used betas & I think the above is a good enough reason not to start.Anyway, I looked at the new version &, as the user folder doesn't have to move anymore, there shouldn't be any issue with data loss. I haven't tested restarting with files open but if it works in the installed version it should work here too.although you can specify the User location it isn't relative, does the Launcher solve that problem?Yes, it will update the full path.
I'm not keen on the idea of using betas, especially as this isn't even a version-specific packageI'm not sure what you mean about this.Thing is the betas are always very stable with odd things now and then that need sorting, Jo really keeps on top of it. Besides, when he said he didn't want updates to beta, that was for mainstream usage. Obviously, if you d/l a buggy beta before he got a chance to fix it, that may put off potential customers.What I am asking, is that this launcher be made for the main stable releases from his download page, but I'd like to adapt it for personal use to update the betas, is that possible? Thing is, the amount of changes and fixes made between stable releases is actually quite huge. First off, you can lose track if you don't keep up, and second, you miss out on some good stuff while waiting, sometimes two or three months for a stable build.I always wanted to learn how to use the PALauncher, but it seems you need some programming knowledge to use it as I couldn't find a guide. What process do you go through to test what apps leave and where, then how to fix that so it all stays within the AppPortable folder. How do you then test it to make sure you got it right?
Anyway that's another discussion.Thanks for your help prapper.
![](/uploads/1/2/6/3/126336384/830007363.jpg)