User Library location
-
- KVRian
- 690 posts since 31 May, 2002 from chez moi
Hi
First of all, I should make sure I'm clear on the MuLab license. Can we install MuLab on two computers as long as we don't use them at the same time?
If so, I'm wondering if people have played around with putting their user library on a space like OneDrive so that you can access the same info/data seemlessly when moving between computers. How do you share your data between two computers?
thanks
First of all, I should make sure I'm clear on the MuLab license. Can we install MuLab on two computers as long as we don't use them at the same time?
If so, I'm wondering if people have played around with putting their user library on a space like OneDrive so that you can access the same info/data seemlessly when moving between computers. How do you share your data between two computers?
thanks
- KVRAF
- 13863 posts since 24 Jun, 2008 from Europe
Yes, you're allowed to use your Personal MuLab User Key on 3 computers, on condition you are the owner of these 3 computers.sluggo wrote: Sun Mar 08, 2020 3:12 pm Hi
First of all, I should make sure I'm clear on the MuLab license. Can we install MuLab on two computers ?
Some info:If so, I'm wondering if people have played around with putting their user library on a space like OneDrive so that you can access the same info/data seemlessly when moving between computers. How do you share your data between two computers?
Note that it's possible to indicate a specific user library folder.
See the User Library Folder preference.
Since M8.2 it's even possible to indicate a specific location for the entire User folder,
see http://www.mutools.com/info/M8/docs/com ... ences.html
Maybe these bits of info help to create a good organization so you can easily sync changes between your user folders.
- KVRAF
- 3157 posts since 28 Mar, 2008 from a Galaxy S7 far far away
Does this mean you can use the same user folder for both the M8 win32 and M8 win64 versions?
Projects using x32 VSt's wouldn't be compatible with M8 win64 and vice versa? How would you overcome this without jbridge?
If you marked each ProjectName with x32/x64 depending which version of MuLab was used to create it, would that be sufficient to avoid conflicts?
I'm not asking if you can use 32bit VSt's on 64bit M8, just whether the data in the user folder, apart from projects using the respective VST's, is compatible with both architectures.
So if you had three folders:
1. MuLab x32
2. MuLab x64
3. User
Could the two versions use the same User folder apart from the actual projects created on each that included incompatible VST's? How would this affect settings, such as the VST list you create in one version compared to the other?
Or is this setup best avoided?
I think to aid in using both versions it would be helpful to change the names of the x64 version to include (x64) after the EXE and MuLabID names. And also any other relevant files. Is this possible?
Why? Because it helps in keeping duplicates of files such as samples etc and avoids having to create several locations for these things. Keeps it tidy and less chance of breaking links to files should file paths be changed. I have updated my portable programs directory several times over the years to accommodate new Portable App Menu's and this can cause issues with these paths. I've had it happen before so this would help with that.
Projects using x32 VSt's wouldn't be compatible with M8 win64 and vice versa? How would you overcome this without jbridge?
If you marked each ProjectName with x32/x64 depending which version of MuLab was used to create it, would that be sufficient to avoid conflicts?
I'm not asking if you can use 32bit VSt's on 64bit M8, just whether the data in the user folder, apart from projects using the respective VST's, is compatible with both architectures.
So if you had three folders:
1. MuLab x32
2. MuLab x64
3. User
Could the two versions use the same User folder apart from the actual projects created on each that included incompatible VST's? How would this affect settings, such as the VST list you create in one version compared to the other?
Or is this setup best avoided?
I think to aid in using both versions it would be helpful to change the names of the x64 version to include (x64) after the EXE and MuLabID names. And also any other relevant files. Is this possible?
Why? Because it helps in keeping duplicates of files such as samples etc and avoids having to create several locations for these things. Keeps it tidy and less chance of breaking links to files should file paths be changed. I have updated my portable programs directory several times over the years to accommodate new Portable App Menu's and this can cause issues with these paths. I've had it happen before so this would help with that.
- KVRAF
- 13863 posts since 24 Jun, 2008 from Europe
Yes.sl23 wrote: Sun Mar 08, 2020 10:59 pm Does this mean you can use the same user folder for both the M8 win32 and M8 win64 versions?
Anyway, about 32 <> 64 bit: I can only recommended to use a stable setup. Constantly switching between 32 <> 64 is not really a supported case. It's recommended to go pure 64 bit. The 32 bit version may disappear one day. Best to upgrade your 32 bit VSTs to their 64 bit version. And if such version doesn't exist, which most probably means it's about an undeveloped VST, then think about replacing it by a MUX patch or by a 64 bit VST.
- KVRAF
- 3157 posts since 28 Mar, 2008 from a Galaxy S7 far far away
Ok thanks, good to know. It's just that I can't find any decent FX that had the sound and control of older VST's I've tried several distortions but to me CamelFuzz was my fave. Same for the Kjaerhaus Classic series, they were easy to use, effective and sounded good, to me at least. others I've found don't have the same character or control. Sad that progress often produces the opposite effect to that which is desired!!! Ambience was the best Reverb I've heard in software, I just don't like any of the others I've heard or tried. Even some expensive ones!
- KVRAF
- 13863 posts since 24 Jun, 2008 from Europe
That's a bit exagerated imho.sl23 wrote: Mon Mar 09, 2020 12:41 pm Sad that progress often produces the opposite effect to that which is desired!!!
On Windows you can use jBridge to use your fav 32 bit VSTs in MuLab 64 bit.
- KVRAF
- 13863 posts since 24 Jun, 2008 from Europe
All MuLab/MUX own data is 100% compatible between the 32 <> 64 bit versions and between the Windows and Mac versions.sl23 wrote: Sun Mar 08, 2020 10:59 pm I'm not asking if you can use 32bit VSt's on 64bit M8, just whether the data in the user folder, apart from projects using the respective VST's, is compatible with both architectures.
I cannot give that guarantee about VSTs though as it is the VST itself that decides on its data organization. That said, i'd expect a good VST to also have its data independent from the architecture.
- KVRAF
- 3157 posts since 28 Mar, 2008 from a Galaxy S7 far far away
A bit, but true.
Yes I've tried it. Not portable. Won't use it. Thanks for the tip tho.
- KVRAF
- 3157 posts since 28 Mar, 2008 from a Galaxy S7 far far away
Thanks for the advise. Greatly appreciated. I've transferred most of my work to 64bit, but the effects are the problem. Such a shame that, understandably, MuLab won't have a bridge.mutools wrote: Mon Mar 09, 2020 1:29 pmAll MuLab/MUX own data is 100% compatible between the 32 <> 64 bit versions and between the Windows and Mac versions.sl23 wrote: Sun Mar 08, 2020 10:59 pm I'm not asking if you can use 32bit VSt's on 64bit M8, just whether the data in the user folder, apart from projects using the respective VST's, is compatible with both architectures.
I cannot give that guarantee about VSTs though as it is the VST itself that decides on its data organization. That said, i'd expect a good VST to also have its data independent from the architecture.
- KVRAF
- 3157 posts since 28 Mar, 2008 from a Galaxy S7 far far away
Just tried jbridge out of curiosity and it's stopping the transport in M8 after a short while during playback.
EDIT: Only done it twice, doesn't seem to be causing issue at present. Will keep eye on it and report if further problems.
EDIT: Only done it twice, doesn't seem to be causing issue at present. Will keep eye on it and report if further problems.
