MuLab & MUX Vst 5.5.2

[fluffy_little_something]

Just noticed a strange thing. I have two folders, Mulab 32 with sessions, and Mulab 64 with different sessions. After playing around with the 64-bit version, I can no longer call up 32-bit sessions from the sessions folder as for whatever reason it tries to open the 64-bit Mulab instead of the 32-bit version, thus it says all the plugins are missing, which is logical.
Now I can only open 32-bit sessions by opening 32-bit Mulab first and then from within that Open... Clicking on a 32-bit session in the Library folder opens the 64-bit version, though, which sucks.
There should not be anything connecting the whole Mulab 32 and the whole Mulab 64 folders in my view, there is no overlapping or shared files etc.

[fluffy_little_something]

Of course, you can always keep the old MuLab to open important old projects that should not change. After all, it's important that they do not change, you do not really need to open them (at all ) in the new version. There were some sound engine changes fairly recently (documented in the change history, as always).

I'd rather we keep getting a better MuLab than change be prevented by compatibility issues, particularly as there's the freedom to keep (and redownload) the old versions.

Since later versions also include bug fixes, I always want to use the latest version. My solution will be to simply use third-party plugins only.

[pljones]

Just noticed a strange thing. I have two folders, Mulab 32 with sessions, and Mulab 64 with different sessions. After playing around with the 64-bit version, I can no longer call up 32-bit sessions from the sessions folder as for whatever reason it tries to open the 64-bit Mulab instead of the 32-bit version, thus it says all the plugins are missing, which is logical.

What does "call up" mean? Did you do some kind of file association on a PC? I didn't think MuLab had that at all? I'd be interested to know how you did it.

Since later versions also include bug fixes, I always want to use the latest version. My solution will be to simply use third-party plugins only.

I guess if those bugs were in the audio engine and it meant changing it to fix the bugs, there's no solution if it was sounding wrong because of the bug -- fixing the bug would mean changing the sound. So you'd either be stuck with the bug or have different sound. Are you saying this only affected MUX rather than MuLab, though -- i.e. built-in instruments and effects? I don't remember enough about the change to know if that was what was done...

[MuTools]

Just noticed a strange thing. I have two folders, Mulab 32 with sessions, and Mulab 64 with different sessions. After playing around with the 64-bit version, I can no longer call up 32-bit sessions from the sessions folder as for whatever reason it tries to open the 64-bit Mulab instead of the 32-bit version, thus it says all the plugins are missing, which is logical.
Now I can only open 32-bit sessions by opening 32-bit Mulab first and then from within that Open... Clicking on a 32-bit session in the Library folder opens the 64-bit version, though, which sucks.
There should not be anything connecting the whole Mulab 32 and the whole Mulab 64 folders in my view, there is no overlapping or shared files etc.

I'm not sure if i understand you fuly but FYI: If you have a MuLab 32 bit installed and a MuLab 64 bit installed, these are 100% independent installs, no overlap. That's a good thing imho.

I assume you are talking about sessions that use VST plugins. Indeed there might be a practical issue on your side when you want to open sessions made with 32 bit VSTs into MuLab 64 bit as it's not possible to use 32 bit VSTs in a 64 bit app and vice versa, unless you're using some bridging mecanism.

That's one of the advantages of using the internal MU effects & synths as these don't suffer from that prob, they load fine on both 32 bit and 64 bit.

About "eternal" sound compatibility: That's practically impossible, it would mean a huge penalty for improving MuLab. Anyway, it's perfectly possible to manage that, it's all explained here:
http://www.mutools.com/info/docs/mulab/ ... sions.html

Now there was especially one version where the sound did change a bit and IIRC that was from MuLab 2 to MuLab 3. Lateron sound was stable IIRC. So i'm amazed to read that your session sounds totally different, never encountered such situation. Pls take the time to make a good comparison. If you need a legacy version of MuLab they're here: http://www.mutools.com/mulab/legacy-versions/

Hope this helps.

[MuTools]

PS FYI: The forthcoming MuLab & MUX 6 will also be 100% sound compatible with M5!

[fluffy_little_something]

Just noticed a strange thing. I have two folders, Mulab 32 with sessions, and Mulab 64 with different sessions. After playing around with the 64-bit version, I can no longer call up 32-bit sessions from the sessions folder as for whatever reason it tries to open the 64-bit Mulab instead of the 32-bit version, thus it says all the plugins are missing, which is logical.

What does "call up" mean? Did you do some kind of file association on a PC? I didn't think MuLab had that at all? I'd be interested to know how you did it.

That is what it looks like. Although, I did not create any association deliberately, it simply seems to be there now, since using the 64-bit version yesterday. I tried undoing it by right-clicking on a 32-bit session and using the Open With command, but it did not work. Whenever I click on a 32-bit project in the 32-bit folder, the 64-bit version of Mulab is opened, which of course leads to all the error messages regarding missing plugins.
No idea how to undo that association, where it is saved so to speak. Maybe it is a Windows issue, although I do not remember that problem from the past. I have had both versions on my computer for ages.

Since later versions also include bug fixes, I always want to use the latest version. My solution will be to simply use third-party plugins only.

I guess if those bugs were in the audio engine and it meant changing it to fix the bugs, there's no solution if it was sounding wrong because of the bug -- fixing the bug would mean changing the sound. So you'd either be stuck with the bug or have different sound. Are you saying this only affected MUX rather than MuLab, though -- i.e. built-in instruments and effects? I don't remember enough about the change to know if that was what was done...

Exactly, it only affects the internal synth sounds. Although I do think Mulab as a whole (including external plugins) sounds slightly brighter now, but maybe I am wrong. The difference could also be due to my ears being better now than a year ago (Just checked, it was version 5.1.5 according to the deleted backup folder in the trashcan. Was that really that old already, over a year?! ) I noticed while upgrading that the old folder did not have the Rex Shared Library, yet. Maybe it has to do with that...

[fluffy_little_something]

Just noticed a strange thing. I have two folders, Mulab 32 with sessions, and Mulab 64 with different sessions. After playing around with the 64-bit version, I can no longer call up 32-bit sessions from the sessions folder as for whatever reason it tries to open the 64-bit Mulab instead of the 32-bit version, thus it says all the plugins are missing, which is logical.
Now I can only open 32-bit sessions by opening 32-bit Mulab first and then from within that Open... Clicking on a 32-bit session in the Library folder opens the 64-bit version, though, which sucks.
There should not be anything connecting the whole Mulab 32 and the whole Mulab 64 folders in my view, there is no overlapping or shared files etc.

I'm not sure if i understand you fuly but FYI: If you have a MuLab 32 bit installed and a MuLab 64 bit installed, these are 100% independent installs, no overlap. That's a good thing imho.

I assume you are talking about sessions that use VST plugins. Indeed there might be a practical issue on your side when you want to open sessions made with 32 bit VSTs into MuLab 64 bit as it's not possible to use 32 bit VSTs in a 64 bit app and vice versa, unless you're using some bridging mecanism.

That's one of the advantages of using the internal MU effects & synths as these don't suffer from that prob, they load fine on both 32 bit and 64 bit.

About "eternal" sound compatibility: That's practically impossible, it would mean a huge penalty for improving MuLab. Anyway, it's perfectly possible to manage that, it's all explained here:
http://www.mutools.com/info/docs/mulab/ ... sions.html

Now there was especially one version where the sound did change a bit and IIRC that was from MuLab 2 to MuLab 3. Lateron sound was stable IIRC. So i'm amazed to read that your session sounds totally different, never encountered such situation. Pls take the time to make a good comparison. If you need a legacy version of MuLab they're here: http://www.mutools.com/mulab/legacy-versions/

Hope this helps.

No, as I explicitly said, unlike described in your link the old projects COULD be opened, it is not that they could not be opened and I was asked to go through any of those upgrade procedures.

Yes, it was also my understanding that both versions and their respective folders live side by side, without affecting each other in any way. But maybe Windows creates some sort of link because of the name Mulab...

[BlackWinny]

The installation of an edition of Mulab being nothing else than a zip file to unzip everywhere you want, Fluffy, you may keep as many old editions as you want in parallel directories side-by-side, and in 64-bit as well as in 32-bit. So if they sound too much different (improvements in modules such as filter, modulators, etc. may indeed drive to new results and sometimes quite far from a previous version) you can consider them as different instruments, so you can keep them all without any problem.


It's a bit different with the VST edition of MUX of course. But not eliminatory... And it would be the same for all the other VST's. But yes, improvements in in new editions of modules of an instrument (whatever the type, hardware as software) imply modifications of the results and very often some corrections in the patches we make with them. It is the price to pay improvements in the products...


And it is also a reason why I militate for the system of tags and personal comments in all the sofware patches systems (it is very with the internal management of a dbf or vcf database), because it allows to use one of these comments to indicate for example the version number of the product which was used when we made that patch. And the tags can be used also for that and for many other personal informations per patch.

[fluffy_little_something]

PS: As I said before, I still can open 32-bit projects after starting 32-bit Mulab manually and then using the Open command from within. Just to clarify that...
But since I want to continue to use my countless user patches I made for SynthEdit plugins and Mulab does not have a built-in bridge, I will not use the 64-bit version of Mulab anyway for the time being. So I might as well delete it. Maybe the wrong file association goes away that way

[BlackWinny]

No idea how to undo that association, where it is saved so to speak.

What is your version of Windows? (XP, Vista, 7, 8... 9, 10...)

I'm gonna give you an answer regarding your version of Windows.

[fluffy_little_something]

W7 64-bit

[BlackWinny]

But maybe Windows creates some sort of link because of the name Mulab...

No, no.

The association has been made neither by Mulab nor by Windows. Sometimes we make things with the mind not very awaken and we discover what seems to be an anomaly later. It happens to me as to everybody.

[BlackWinny]

Ok, you can use this:
http://www.winhelponline.com/blog/unass ... s-7-vista/

It is totally safe, I use it myself.

[fluffy_little_something]

Something weird is happening. I deleted the entire 64-bit Mulab folder with all the projects etc. Then I clicked on a 32-bit session from the 32-bit Mulab folder and I was asked to choose a program with which to open that type of file. So I went to Mulab 32 and it did not accept it, opened it with Google Chrome instead Repeated it a couple of time, always the same thing...

[fluffy_little_something]

Ok, you can use this:
http://www.winhelponline.com/blog/unass ... s-7-vista/

It is totally safe, I use it myself.

Will try it, thanks.