MuLab 4.3 (incl Win 64 bit version)

[sl23]

AndreasD are you still doing requests for MuX FX?

[sl23]

See the other posts here.

I sort of meant other than that! These don't seem like major problems, except possibly the VST storing stuff in different folders might be?

Does it make it harder to code if you combine the 32/64bit exe's?

[MuTools]

No, not really harder to code. If most users would want a common package (which is not the case atm) then at least LibResample and the VstPlugins.xml should be splitted into a 32 and 64 version, but maybe also AudioSetup.txt (different drivers on different systems), MidiSetup.txt (same reason), PreferredFilesAndFolders.txt (maybe different folder locations) etc... So in fact there seems to be a natural need for a split. Which is logical in a way as you cannot have a 32 and 64 bit system at the same time, and so in fact you are wanting to merge different installations. So as i'm brainstorming here, i think the current way of having 2 different packages (which seems to be the most used way by other apps too) seems to be the right way. Right?

So i think we should turn around the question and ask ourselves which things we would like to share between different installations. Obviously that's at least the preset library. Well this can be done cfr http://www.mutools.com/mulab/docs/prese ... ement.html

[Crackbaby]

Is it possible to add shortcut for adjusting bpm? I might be blind but i couldn't find it in the lists.

[sl23]

Okay, I don't see the problem with combining really but I'll leave it at that, I don't want to stir things up, I was just curious really.

So if I 'install' both versions, can I just point the 64bit one to the User folder of the 32bit one and delete the 64bit User folder?

[fedexnman]

Although I use Windows7 64bit for music DAW stuff , I still would'nt mind seeing a Linux / with Jack port of Mulab , as I do dual-boot Ubuntu or whatever Linux distro be it Mint , AV linux , etc. etc . It'd be fun to try out. It'd be really cool to have because you could use musynth , musampla , mudrum and hook it up to Jack and record it with Ardour or whatever.
Congrads on getting it 64 bit and working on Mux still !!!!

[MuTools]

Okay, I don't see the problem with combining

And what about i wrote? Eg AudioSetup.txt etc...

So if I 'install' both versions, can I just point the 64bit one to the User folder of the 32bit one and delete the 64bit User folder?

No, currently only the factory and user libraries can be made common. How to = http://www.mutools.com/mulab/docs/prese ... ement.html

[sl23]

Okay, I don't see the problem with combining

And what about i wrote? Eg AudioSetup.txt etc...

So if I 'install' both versions, can I just point the 64bit one to the User folder of the 32bit one and delete the 64bit User folder?

No, currently only the factory and user libraries can be made common. How to = http://www.mutools.com/mulab/docs/prese ... ement.html

Yes, but I'm not a programmer, I don't understand these issues with the files, to me it's a simple matter of making MuLab see these 64bit versions, but I doubt it's a simple task for you.

Thanks for the link, I had just read it before you posted coincidentally, though not all, I didn't realise only certain sub-folders were common.

Sorry if I don't understand the why's, it's just that I know nothing about development issues and you saying about these files isn't really explaining the why. Which is my reason for asking again.

[MuTools]

It has nothing to do with programming.
Imagine you have a common installation folder with both the 32 and 64 bit MuLab.exe and all sub-folders, all installed on a USB stick. You put it in computer 1, MuLab loads AudioSetup.txt and starts playing. Now later you put it in computer 2, MuLab loads AudioSetup.txt but this will be set for computer 1, so it won't work on computer 2 because it has another sound device (most probably). So here starts the need to also split AudioSetup.txt. And the same reasoning may be true for more files, and so you *want* a common folder, but you'll end up making a lot of splits. And so that's why i say there seems to be a natural need to work with separate installations, and then, in specific user situations, the user can choose to make certain thigs common. Ok, up to now only the preset libraries can be made common, but maybe i'll also add options to common-ize other aspects. To be evaluated lateron, i don't think this is a top priority atm. (e.g. multi-core for MuLab has more priority, i think)

[sl23]

So it's not whether you can make AudioSetup64.txt just simply not wanted. Changing these files isn't really a problem then, just that users don't want it. Or you could use a single file but have it stated within that there's a 64bit section? Just an idea not asking as such. But yeah I see your point thanks for explaining further.

[zendorf]

I think that was a wise move to go 64bit before multicore Very keen to tryout the 64bit Mux plugin in Reaper64.

I just tried to download the 64bit version of Mulab at the proved link, but can only find a newer 32bit build(4.3.3). Has the 64bit version been taken down?

[pljones]

So it's not whether you can make AudioSetup64.txt just simply not wanted. Changing these files isn't really a problem then, just that users don't want it. Or you could use a single file but have it stated within that there's a 64bit section? Just an idea not asking as such. But yeah I see your point thanks for explaining further.

Every "if" is a failure point in a program. If you have to decide "do I want file-32 or file-64" for many files, or "do I want library-32.dll or library-64.dll" or likely even "do I call function-32() or function-64()" in many places in a program, you make it more likely to go wrong in the first place and harder to find the bugs. That means more developer time is spent doing non-useful work - i.e. not adding features, just fixing breakage.

I just makes sense to keep things that work differently separate. You might even then be able to move all those different "if" tests into one place: "if I'm building the 32bit version, do this; otherwise do that". Less to go wrong; less time spent fixing bugs; more time spent writing MuLab5 .

[MuTools]

I think that was a wise move to go 64bit before multicore Very keen to tryout the 64bit Mux plugin in Reaper64.

I just tried to download the 64bit version of Mulab at the proved link, but can only find a newer 32bit build(4.3.3). Has the 64bit version been taken down?

MuLab 4.3.3 32 bit is an intermediate version. I noticed a couple of issues and fixed+tuned them now. New versions of MuLab (OSX, Win32, Win64) and MUX Vst (Win32, Win64) are on the way...

[MuTools]

New MuLab 4.3.4 packages are available in http://www.mutools.com/mulab/cedar

For experienced users: If you already installed MuLab 4.3.1 you can just update the new application file.

What's changed since 4.3.1:

• Fixed a load bug for certain MUX preset files.
• Internal optimizations.

[sl23]

Every "if" is a failure point in a program. If you have to decide "do I want file-32 or file-64" for many files, or "do I want library-32.dll or library-64.dll" or likely even "do I call function-32() or function-64()" in many places in a program, you make it more likely to go wrong in the first place and harder to find the bugs. That means more developer time is spent doing non-useful work - i.e. not adding features, just fixing breakage.

I just makes sense to keep things that work differently separate. You might even then be able to move all those different "if" tests into one place: "if I'm building the 32bit version, do this; otherwise do that". Less to go wrong; less time spent fixing bugs; more time spent writing MuLab5 .

Thanks for the info. I think I'd rather time was better spent too Although it would be better for me personally if they were combined it's not essential as they're installed on the same device anyway.