32 to 64bit

[sl23]

I know, I know, been discussed and I understand the idea that development time is scarce but may I just ask about one more variation that may, or may not be easy enough to implement. Please hear me out...

So, I use both the 32bit and 64bit versions of MuLab, I was first wondering if it were possible to somehow possible to run them side by side like with rewire or something? I've never tried and don't really know how that works, but is that possible? Basically it means some way of syncing the two versions of MuLab APP to run together.

Ok, I lied, there's a second option that may bring a few more customers!
Would it be easy enough to make MuLab 32bit into a 64bit plugin? So we could then load 32bit plugins into MuLab 32bit, but then if you made the PLUGIN version of MuLab 32bit available in 64bit,we could the have MuLab 32bit running as a 64bit plugin inside MuLab 64bit app.

This would mean 64bit app users would buy the app, but those same users wanting to use 32bit plugins would buy both the app and plugin.

I get jbridge is available, but it comes with compatibility issues and such. But running MuLab inside MuLab would be far more stable I reckon.

What do you think? Shit idea or jackpot?

[mutools]

I'm sorry but a 32 bit -> 64 bit bridge was and is not planned.

Please note that 32 bit plugins are abandoned out of date plugins, otherwise the dev would offer a 64 bit version.

Take into account that possibly one day also MuLab will cease 32 bit support. Maybe because one day Microsoft will also cease 32 bit app support, or maybe to cut the needless overhead, or to stop the 32 bit <> 64 bit confusion. Everything 64 bit is more simple and easy.

I recommend step by step replacing your 32 bit plugins by MUX presets, or by 64 bit plugins.

I'd rather invest dev time in extending MUX Modular so that you can use it to replace (some of) your 32 bit plugins.

[sl23]

I see your point, and I do get it, it's just that there are so many good 32bit plugins available with so much potential. Many of which have no replacement and probably never will.

But still, things always move onward. Ok well thanks for the reply, just wondered if there was a simpler solution than bridging. I know some plugins in other apps have been simple to implement 64bit versions, anyway, I'll leave it at that.

[nenneb]

There is one more:
I also switched from 32 to 64bit recently. But when I want to open a song created with 32bit, its a hassle, as I have to replace all non-MuLab-instruments and effects and then restore the parameter values manually.
Therefore I actually use both versions in parallel for that reason ...

[mutools]

I also switched from 32 to 64bit recently. But when I want to open a song created with 32bit, its a hassle, as I have to replace all non-MuLab-instruments and effects and then restore the parameter values manually.

I can imagine this is VST plugin specific. In fact it should not be like that, that a plugin's file data is dependent on the 32 bit or 64 bit version, sounds rather exceptional to me. MuLab project and preset files are independent from whether they're saved with MuLab 32 bit or 64 bit.

[nenneb]

As so often, you are right, Jo!
Of course I can save the 32bit preset to a file and reload it in the 64bit plugin.
Anyway it's not impossible, but a hassle: Store the preset, search the "new" synth in 64bit, reload the preset - and all that for every track.
On the other hand I assume: Loading 32bit into a 64bit register only results in leading zero's ...

[fde101]

Of course I can save the 32bit preset to a file and reload it in the 64bit plugin.

I would expect this to happen automatically without the need to save a preset, which leads me to think whatever plugin you are using is sub-optimally designed. In theory the 64-bit version should be loaded automatically in place of the 32-bit version of the same plugin when opened in the 64-bit version of the DAW and it should simply understand the data that was saved in the project by the 32-bit version.

Of course, being on the Mac, where 32-bit support was dropped completely several years ago now, it is largely academic from my perspective at this point, but out of curiosity, are all of your plugins failing to match up, or only specific ones (assuming you are using more than one)?

[nenneb]

Sorry for the late reply, fde01! I just checked again and you are partly right. I looks like this:
I load a new project in Mulab32, replace BasicSynth by a 32bit-Vst and save it.
Then open this project in MuLab64, which ask's me to locate this synth in file-manager (although the 64bit of this synth is listed in the plugin-manager).
After locating it again, the synth-settings are set correctly.
The weird thing is, in case I have more instances of the same synth in MuLab32, MuLab64 asks me for every single track to locate the 64-bit version .... plus for every effect or other VST ...

[mutools]

In theory the 64-bit version should be loaded automatically in place of the 32-bit version of the same plugin when opened in the 64-bit version of the DAW.

Is there a standard rule how MuLab can deduct the 64 bit plugin DLL file path from a 32 bit plugin DLL file path?

Alternatively: Maybe MuLab's Plugin Manager could be extended so that 32 bit plugins have the option to define their 64 bit version DLL file path. Then this could even be another 64 bit plugin.
About loading projects / presets: When MuLab loads the 64 bit plug version of a 32 bit plug and MuLab gives the stored plugin data to the 64 bit plugin, then if it's about the same plugin, the plugin should handle that well. (otherwise it's a bad plugin) If it's really another plugin then that plugin should simply ignore the original plugin data and so it will be in default state.

What do you think?

[sl23]

Wrt my topic on Replacing bridged x32 plugins with x64 and it's usefulness. If this is something you think is worthy of implementing, I would suggest adding it to the Plugin Manager window. So when you click on a Plugin in the left column, it would show which Projects it has been used in on the right somewhere.

I'm not sure if this is gonna be a headache to actually put into practice though as what if you open a Project and then delete the usage of a plugin in that project? Could potentially be a messy business.

The only thing I can suggest is to have a text file in each project folder that saves what third party plugins are used and update this if they are removed from that project. Then when you open the Plugin Manager, it scans these text files and then knows if that plugin is still in use? Anyway, just an idea, no rush.

I assume there's currently no way of knowing where plugins have been used? That's ok, I've already started going through the process, I've had worse things to organise! lol

[sl23]

Alternatively: Maybe MuLab's Plugin Manager could be extended so that 32 bit plugins have the option to define their 64 bit version DLL file path. Then this could even be another 64 bit plugin.
About loading projects / presets: When MuLab loads the 64 bit plug version of a 32 bit plug and MuLab gives the stored plugin data to the 64 bit plugin, then if it's about the same plugin, the plugin should handle that well. (otherwise it's a bad plugin) If it's really another plugin then that plugin should simply ignore the original plugin data and so it will be in default state.

What do you think?

Perhaps it's time to abandon MuLab32? I know several people, myself included, that want it to continue, but it's just not viable anymore it seems.

I have a few 32bit plugins that I cannot replace, 9 synths and 5 or 6 FX, which I'm gonna use jBridge for now. I may end up buying a Reaper licence, not sure yet. But either way MuLab64 will remain my main DAW, it's just too good and too easy to use.

[mutools]

It's certainly not planned to abandon MuLab 32 bit on short term. I only said, in a reply to a question, that i recommend replacing your 32 bit plugins by MUX presets / 64 bit plugins, step by step. There still is plenty of time to discuss this 32 bit -> 64 bit plugin transition aspect. And indeed jBridge is a handy tool to fill gaps for now. But then the practical question still remains: If a user wants to replace a 32 bit plugin by its 64 bit version, then how to do it in a comfortable way? That's why i posted some questions about that.

[sl23]

Maybe M9 will be the last version to support 32bit plugins ...
Yeah that's why I'm not getting too deep into using 32bit plugins now, and trying to switch everything I can before it becomes a problem.
Just trying to pre-empt it.

[nenneb]

Is there a standard rule how MuLab can deduct the 64 bit plugin DLL file path from a 32 bit plugin DLL file path?

I don't think so. Sometimes both versions are in the same folder, sometimes not.
I'd find it useful if the "Plugin not found"-prompt would offer the plugin-manager instead of the file-explorer. This way I could assign an already registered plugin easily. Plus the option "for one / for all", meaning, if I have more instances of the same plugin it could reload in 64bit at once.

... this could even be another 64 bit plugin.
About loading projects / presets: When MuLab loads the 64 bit plug version of a 32 bit plug and MuLab gives the stored plugin data to the 64 bit plugin, then if it's about the same plugin, the plugin should handle that well. (otherwise it's a bad plugin) If it's really another plugin then that plugin should simply ignore the original plugin data and so it will be in default state.

Agree!

[sl23]

It should offer the Plugin Manager with the option to use the file browser if the alternative isn't in the list.