Application: MuLab
Category: Music & Video
License: See notes below
Language: English
Description: MuLab is a top-quality sound & music production system, transforming your computer into an inspiring modular studio & is an easy, effective & rock-solid tool designed to create, record & finalize your music.
Online Installer: This is an online installer that will download additional files during setup.
Download MuLab Portable 6.4.18 Dev Test 1 [1+19MB download / 48MB installed]
(MD5: 29e156929add59b5cc8cfd70689f9aca)
Release Notes:
6.4.18 Dev Test 1 (2015-03-31):
- Well that's the end of that then...
-
-
MuProjects have replaced MuSessions so path replacement in Custom.nsh also targets
"User\Library\MuProject\*\*.MuProject".
x.x.x Dev Test 5 (2015-03-24):
- User folder stays in Data now.
- Upgrade should be automatic but backup your data anyway...
x.x.x Dev Test 4 (2013-02-14):
- MuLab.ID file is now backed up to Data.
- Removed 64-bit version.
x.x.x Dev Test 3 (2013-01-26):
- Added basic error checking for a locked user folder.
- If the installer or launcher find user data in the app folder, they will quit (rather than guess what you want to do with it).
- Clean install required. This is a test version, do *NOT* use any critical data!
- Updated path replacement & splash.
x.x.x Dev Test 2 (2012-08-17):
- Restructured Data\User. It's an automatic upgrade but make a backup anyway...
x.x.x Dev Test 1 (2012-08-11): Initial release
Notes:
MuLab Free is restricted but can be upgraded here.
Save all your projects into the default MuLabPortable\Data\User\Library\MuProject folder & all absolute paths will be updated.
If you have Wavosaur Portable in the same folder as MuLab Portable it will be set as MuLab's external audio editor on first start.
Tested with:
XP Home SP3 (Admin), 7 Professional SP1 64-bit (Admin)
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
Continued from here.
I did the 64 bit version as a plugin & added the code to switch. As there are only two files which are different in each package I'm presuming the User folder is compatible with both 32 & 64 bits although I'm also swapping the VstPlugins.Xml file as well (if this is a problem, let me know).
Not for an online installer.
Thanks Prapper
I 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:
http://www.mutools.com/mulab/cedar/
When a new stable update is released this link is diverted to the MuTools site instead of the '/cedar' location.
Live for an ideal and leave no place in the mind for anything else.
I 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 & App\Bin\LibResample.Dll. Nothing changes in the App\MuLab 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.
How 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 I'm willing to try it out
With regard to beta updates, there's always the same link for these. It.s the cedar location on mutools site which loses the cedar extension when the beta becomes official. It's not something I want to happen but what does happen. Hope that's clear enough.
Thanks
Scott
Live for an ideal and leave no place in the mind for anything else.
Sorry, I'm still none the wiser
:-)You'll have to spell it out for me, are you saying there's a link I could use that will download the beta version & then automatically change to download the stable when it's available? It would have to be one that I'm not going to have to update every version change & I'm still not convinced of the wisdom of an installer downloading beta versions anyway.Ok, this is the beta link:
http://www.mutools.com/mulab/cedar
This is the normal d/l link:
http://www.mutools.com/mulab-downloads.html
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. Not sure about MuLab's Licensing though might not be allowed?
Live for an ideal and leave no place in the mind for anything else.
OK, I'm with you. I don't think what you suggest is feasible really, neither of those links actually redirects to a specific file anyway, which is what the installer needs. Again, if you want to install betas it's easy enough to copy them in.
Regarding the license, I'd assume that it's stored in a file in the User folder, in which case there's no problem. I would be surprised if it ties the app to a particular machine. Could be wrong though...
I think I'll just upload this now & you can test it.
The links were just to the download pages for cedar/beta and MuTools/official but the links are there for whichever download you require. But Jo wants to keep cedar links as is so don't need to worry about that.
I've used my mulab on 5 machines so far and only once on each had to put code in on each. Should be ok as it is now so when you're ready I'll give it a try.
Thanks
edit- just noticed you already put links up. Will try it out when get home. Thanks for doing that prapper
Live for an ideal and leave no place in the mind for anything else.
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
Live for an ideal and leave no place in the mind for anything else.
Put your User folder in MuLabPortable\Data. When MuLab is running, it's renamed to MuLabPortable\App\MuLab\User. There should be no User folder in MuLabPortable\App\MuLab when MuLab is closed. Keep a backup
:-)VSTs can be anywhere on the drive but you'll have to rescan or manually change the paths in MuLabPortable\Data\User\Settings\VstPlugins.Xml. MuLabPortable\Data\VSTPlugins is fine.
I'm curious as to whether your authorization is successfully transferred between machines.
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?
Live for an ideal and leave no place in the mind for anything else.
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 User\Settings\PreferredFilesAndFolders.Txt you can redirect User\Library 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 App\MuLab & one in Data, which also creates a problem.
Is there a lot of manual work to be done in there?
I do tend to need access to it a lot as I'm working on some synth designs but also plan to store samples here though once placed shouldn't need access.
I had the original folder still so wasn't a problem.
I assume there's nothing can be done about this?
Thanks for the launcher though I'll just make sure I've got a back up of user folder
Live for an ideal and leave no place in the mind for anything else.
I hope this happens please, so I can take advantage of the PA.c updater.
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
:-)Can 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 notes. 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.
Glad 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.
Live for an ideal and leave no place in the mind for anything else.
Well, the User folder is data & according to the PA format, data goes in MuLabPortable\Data. I can't redirect the entire User folder, I can only redirect User\Library (using Settings\PreferredFilesAndFolders.Txt). MuSynth presets (which reference their samples using {UserLibrary}/MuSynth) loaded from this folder play correctly so I know this is working. So far, so good. Now, when you first save a project, the path comes up as 'Folder: Preferred User Sessions Folder' & you can then name the project & save it. As the default path is App\MuLab\User\Library\MuSession, I would expect that, having redirected the user Library, the redirected path would be Data\User\Library\MuSession but they're saved to App\MuLab\User\Library\MuSession, creating a second user Library in the app folder, which is a problem when it comes to moving it back to Data when the app closes. Does that all make sense?
At the risk of things starting to get messy, I can do another dev test which redirects the Library but moves the Library\MuSession folder which would, at least, minimise the problem. Do you want to give that a go?
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 opinion
Ok, 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.
Thanks
Scott
Live for an ideal and leave no place in the mind for anything else.
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 App\AppName 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 AppNamePortable\Data 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 AppNamePortable\App 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 App\AppName\Something to Data\SomethingElse and all the files exist there, or it doesn't and they remain at App\AppName\Something. The files are moved individually so there's no danger of them getting lost.
Sometimes, the impossible can become possible, if you're awesome!
Excellent thanks for the reply John. You pay files can't get lost but I did lord the User folder because I was using it in CE how did that happen? Just curious that's all.
Live for an ideal and leave no place in the mind for anything else.
Not sure what you mean by CE. It shouldn't be possible to lose them as it's similar to renaming a folder in Explorer.
Sometimes, the impossible can become possible, if you're awesome!
Sorry I thought you'd read this thread. CE is CubicExplorerPortable. What happened was that I was working on a synth preset in mulab and had the folder open in CE but needed to restart mulab for the preset to take effect. On doing that the entire User folder was lost apart from the one that was open in CE does that make sense?
Live for an ideal and leave no place in the mind for anything else.
I thought I'd checked this but, looking again, I can reproduce this data loss with PAL using [DirectoriesMove] but not with a stub program using the native NSIS Rename instruction. I don't really want to post the test files but maybe I could email them with a repro for a second opinion?
EDIT: Tested again & PAL can wipe the entire contents of a folder just by having one file open.
Scary! And all this time no-one's noticed this?
Live for an ideal and leave no place in the mind for anything else.
Send an email with the details to kalug [AT] users.sf.net.
Previously known as kAlug.
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 Data\User folder. If a folder has been 'redirected' it's actually not moving.
What will happen is, the Library will stay in Data\User while the app is running, except for the MuSession subdirectory which will have to be moved to the app directory, as will the User\Audio & User\Settings 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 Data\User folder would look like this:
User _Audio _Settings Library _MuSession MuSynth Mux WaveformsSo 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?
I'm not really sure but if you think its better that way I'll give that a go.
John.s explanation was good and gave a lot of insight on the reasons for the way this works which helps understand this better.
Sorry not had time to test 64bit yet. Replies have been made from my phone!
I'll try this new version before 64bit just to see how that works. When I get time that is.
Thanks
Live for an ideal and leave no place in the mind for anything else.
Hi, any news on this yet prapper? Are you updating to move just library or trying to figure out the cause of losing data?
Thanks
Live for an ideal and leave no place in the mind for anything else.
I wasn't sure you were still interested but I'll update it now. The data issue is a general PAL thing so I sent my test files to kAlug & I'm sure he will let us know.
See release notes for changes.
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 again
EDIT: 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.
Live for an ideal and leave no place in the mind for anything else.
Look in Settings\PreferredFilesAndFolders.Txt & check where the Library is supposed to be. It should be "UserLibraryFolderPath=/X:/PortableApps/MuLabPortable/Data/User/Library" if everything was upgraded properly.
My previous method of verifying the location:
This is the only way I can find of checking this. Is there another? Could you give me a more detailed explanation of what's going wrong?
64bit is a plugin & only adds a couple of files to the package so no need to change it yet. Still at DT1.
Re: the PAL thing. I don't know, wait & see what kAlug says.
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
- + Instruments
The 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
Live for an ideal and leave no place in the mind for anything else.
OK, consider this withdrawn until further notice.
EDIT: Trying to remove the links triggers the spam filter.
Don't suppose there's any news on this yet?
Live for an ideal and leave no place in the mind for anything else.
I haven't heard anything. Perhaps I should post a bug report.
Any chance of this getting fixed, or have you dropped it?
Live for an ideal and leave no place in the mind for anything else.
Regarding this post, 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.
Is this a dead duck now?
Live for an ideal and leave no place in the mind for anything else.
What exactly is the issue with moving files in this one, since it has a portable version that is being adapted? If it's a matter of a few lines of custom code, I'm sure I or Aluisio can assist.
Sometimes, the impossible can become possible, if you're awesome!
Data loss
I see walls of text. In a single line, when is data loss occurring? On a crash and then upgrade? If so, we can work around that by preserving the directories in the installer.ini.
Sometimes, the impossible can become possible, if you're awesome!
Not one line but here goes...
I followed those exact steps and it works as expected. How are things 'gone'?
Sometimes, the impossible can become possible, if you're awesome!
Well, I cannot explain that. They're 'gone' in that they don't exist either in %APPDATA%\A Note or %PAL:DataDir%\ANoteSettings.
Are you multi-launching (opening a new one before old closed)? Or locking the directory or file by keeping it open somehow? Please list your exact steps including what you are opening the file or directory in.
Sometimes, the impossible can become possible, if you're awesome!
No multi-launching. Yes, open Log.txt in Notepad & keep it open as you launch & exit the app again.
Ah, ok. That's a pretty unique scenario and, honestly, not one we need to worry about too much. I think you're fine releasing this.
I couldn't reproduce it as Notepad++ doesn't like TXT files it has open.
Sometimes, the impossible can become possible, if you're awesome!
That's fine for txt files but not for your multi gigabyte custom sample library which will also disappear in a flash.
I mean the possibility of that directory being locked is remote.
If you're concerned about it, handle the move and move back in PrePrimary and PostPrimary via custom code and ensure a Preserve is set on the directory within App in installer.ini (to catch a crash and then upgrade scenario).
Or, even better, try a quick rename on the directory back and forth as part of the Init segment. If it fails, you can abort right there and warn that the directory is locked.
Sometimes, the impossible can become possible, if you're awesome!
I thought it was remote too when it happened to me & then sl23 reported it so perhaps, due to the nature of the app, there's more chance of it happening.
The deletions don't occur with the native NSIS Rename (as in custom code), the problem is with PAL's [DirectoriesMove] so perhaps it's better handled as you suggest but it still makes me nervous considering the amount of damage that could be done.
I tested, and indeed the problem exists. Unfortunately I don't know how to fix it (perhaps trying to copy again if an error is reported?).
Previously known as kAlug.
Thanks for looking at that, pleased to hear I've not gone totally mad yet.
If a directory can't be moved, back out any other changes/moves that were made and then show an error that a directory can't be moved due to a file or directory locking it. Please close an open files within XDirectory and try again.
Sometimes, the impossible can become possible, if you're awesome!
See release notes for changes.
Wow! I missed all that going on :lol:
Thanks for trying with this one prapper, and of course John
I'll give it a go and post any problems.
Live for an ideal and leave no place in the mind for anything else.
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 prapper
EDIT:
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 though
As 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 PAD file if it's any help to you? Probably not needed but thought I'd post it anyway.
Live for an ideal and leave no place in the mind for anything else.
All 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?
A good idea, it shouldn't be a problem at all.
I just checked v5. Is that the registration info? If so, I should do DT4 & move it back to Data. Can you confirm?
The 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?
Live for an ideal and leave no place in the mind for anything else.
I don't understand why you want the additional overhead of a launcher if that's the case
OK, I'll make sure it gets moved.
No, official releases only. I think it should stay that way too.
Not 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?
Internal Drive: Easier to update
64bit: My OS is 64bit. If I run MuLab64 I can't use 32bit VST's they aren't compatible with 64bit, you need to install jbridge, or equivalent. So after installing MuLabPortable 32 + 64 I don't have access to the 32bit version and in turn the 32bit VST's.
Thanks prapper
Live for an ideal and leave no place in the mind for anything else.
You can uninstall the 64 bit version by deleting these two files:
App\MuLab\MuLab64.exe
App\MuLab\App\Bin\LibResample64.Dll
Or are you saying you want the choice of running either version on a 64 bit OS?
It may be the case that us only providing the 32-bit version would make more sense if the majority of VSTs are 32-bit versions. Like DLLs, the 32-bit ones only work with the 32-bit apps. And I know a ton of VSTs are 32-bit only.
Sometimes, the impossible can become possible, if you're awesome!
I suppose each user would have their own opinion, personally I'd like the choice. But it makes sense to make it 32bit as I d/l over 300 free VST's and only around 5-10% are 64bit.
Live for an ideal and leave no place in the mind for anything else.
I agree that 32 bit only is the better option. If there are no objections I'll remove the 64 bit code & get the ID file backed up.
Thanks again
Just 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 launcher
Actually I would still use it as I do CE.
Live for an ideal and leave no place in the mind for anything else.
See release notes for changes.
Thanks prapper
Live for an ideal and leave no place in the mind for anything else.
Ahem...
Is there any chance of a 64bit version as a seperate launcher please?
Also, I asked the dev of jBridge 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.
Thanks
EDIT:
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?
Live for an ideal and leave no place in the mind for anything else.
If all your VSTs are 32-bit, just use the 32-bit version of MuLab. Why do you need the 64-bit version?
Sometimes, the impossible can become possible, if you're awesome!
better performance. Though I can't say that from experience as I can't use them that way. But several people on the forum are saying that and as I have a 64bit laptop with a not very powerful CPU and 4GB RAM, isn't it better to use 64Bit?
Also, I'd like to gradually move over completely to 64bit as it seems that's the way it's going.
Live for an ideal and leave no place in the mind for anything else.
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 No eXecute bits (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? Well, no. 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.
Sometimes, the impossible can become possible, if you're awesome!
To get a launcher for MuLab 64-bit just install another copy of the existing one to a separate folder & replace these two files:
App\MuLab\MuLab.exe
App\MuLab\App\Bin\LibResample.Dll
with the ones from mulab-win64.zip. It should work but I haven't tested it.
Yeah I thought about that but wasn't sure. Thanks
Live for an ideal and leave no place in the mind for anything else.
Thanks for your answer John.
So the main reason for a DAW to be 64bit is RAM? Though minimal what about the fact I have 4GB and 32bit has been said by many to use no more than 3 - 3.5GB?
During normal use, web browsing, email, etc, memory consumption is at around 40-45%. So an extra 0.5-1GB would make a difference, wouldn't it?
Samples use a fair bit of RAM, though I'll try to use mp3's as it's good enough for me. Some VST's also use fair bit too.
Live for an ideal and leave no place in the mind for anything else.
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.
Sometimes, the impossible can become possible, if you're awesome!
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?
Live for an ideal and leave no place in the mind for anything else.
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.
Sometimes, the impossible can become possible, if you're awesome!
Sorry, I know you're a busy man, but could you just clarify one more thing please.
If you had 32bit OS with more than 4GB does that mean the extra RAM is unused or that the OS can't use it?
EG:
8GB installed
32bit OS uses up to 4GB
Would the extra be redundant or can apps still use it, though the OS can't?
I imagine the answer is no, because the OS is what 'controls' it, I think.
Thanks a lot for your help John.
Live for an ideal and leave no place in the mind for anything else.
Over 4GB can't be used by Windows which means the apps can't use it either.
Sometimes, the impossible can become possible, if you're awesome!
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
Live for an ideal and leave no place in the mind for anything else.
If you try it fully loaded, your memory use is going to be FAR less then you are expecting it to be.
Sometimes, the impossible can become possible, if you're awesome!
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 John
EDIT:
An example would be the Uhbik FX by U-he which states a minimum requirement of 1GB.
Live for an ideal and leave no place in the mind for anything else.
Right, he's saying 1GB or more for Uhbik FX plus the whole OS plus whatever software you use it with. That's a physical hardware recommendation. It doesn't mean the Uhbik uses anywhere near 1GB of RAM itself.
What's the MAX RAM you've ever seen your current setup using?
Sometimes, the impossible can become possible, if you're awesome!
Ah, I see...
My desktop uses around 1.5GB
Live for an ideal and leave no place in the mind for anything else.
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:
http://209.238.100.73/mulab/mulab-6-3-6-win32.zip
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.
Live for an ideal and leave no place in the mind for anything else.
Yes, I'm still up for it
Yes & yes.
I don't understand. As we're only dealing with the 32-bit version here, why would that be an issue?
Only by editing installer.ini & recompiling the installer.
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).
Yes 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 it
Re: 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 - http://www.mutools.com/forsythia/ 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?
Live for an ideal and leave no place in the mind for anything else.
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...
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.
Yes, it will update the full path.
I'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.
Live for an ideal and leave no place in the mind for anything else.
Pages