MuLab 10.1.25

[sl23]

Will MuLab app x32 be updated or is this the end of the road? I don't use Mx32 much, just now and then to play with some old plugins. Would be nice to be able to still do that with latest version. I get at some point it will likely be deprecated, but as long as it is compiled, I will be downloading. Would like to know if you have a plan as to when it will end support for the Mx32 version? Thanks.

[MuTools]

The Win32 versions are fading out, but M10.1 will also get its Win32 builds when M10.1 is almost ready to release. Generally i'm not building the Win32 versions during beta testing anymore.

[MuTools]

Why hide it? If its a database change only, which is what it has always been, or at least I thought it was

Yes it's purely an inside MuLab database rename, nothing changed on disk.

then it doesn't break anything. Also, changing the name doesn't work properly.
eg, I rename Filterstep_64 to Filter Step and nothing changes in the Plugin manager or the browser, So what is the purpose of renaming if that changes nothing?

In MuLab 10.1 there are plugin files and plugin items.
A single plugin file can contain many plugin items.
This is not MuLab's choice, it's how VST3 and CLAP are designed.

So at least there is a plugin file name and a plugin item name.
By default the plugin file name equals the real file name itself, without extension.
But it could be, for reasons, that you have multiple versions of the same plugin in different folders. These would end up with the same name in the database making it difficult to differentiate between them.
That's why MuLab 10.1 still allows renaming the plugin DLL file within the database, as before. A plugin item ( = a real plugin inside a plugin file) only has a single non-editable name and that's the name given by the plugin developer.
The project browser lists the usable plugin items, not the plugin files.

This somewhat complicated difference between plugin files and plugin items comes from the fact that VST3 and CLAP allow a plugin developer to store multiple plugins inside a single DLL file.
That's a reality i have to deal with as support for it has been requested by you and other users.

Renaming the DLL file name will only be visible in the Info frame of the Plugin Manager.
The DLL file name is important because this it's part of the data that is saved + reloaded so to retrieve the exact same plugin: MuLab saves the DLL file name + the plugin ID within that DLL file.

I understand the new system and how they use the internal name, bu the purpose of the Plugin Manager renaming was to display the custom name. I don't see how you can't still work the same way regardless of how plugin names are read from the shell vst or a standard vst. You get a name from the vst and if in the database as a renamed vst, use the custom name.

Why would you want to rename the real plugin item name given by the developer?
Sounds like overkill imho.

Note that you can rename each and every instance of a plugin!

[sl23]

I don't think I follow the implications of what you are saying. But then I kinda do. You are saying there are now two types of plugins shown in the database: Files and Items. I understand all that and I don't see how it has any bearing on renaming.

Let's take the uhbiks as an example for renaming. Each is shown in the list as an item, yes? That means MuLab is reading the File and getting the Item names for each, correct? So why can't you just allow the name to be changed within the browser/plugin manager?

The way I see renaming isn't about renaming the Files or Items at all. It is about replacing the real names shown in the browser with the custom names given by users. For example, Uhbik Ambience is shown literally as that. Let's say you wanted to rename it to just Ambience. Then MuLab sees the real item name, but swaps that name with the custom name within the browser/plugin manager. So as far as MuLab is concerned, the plugin is called Uhbik Ambience, but the user sees just Ambience. This has nothing to do with Files or Items or DLL's or anything else. There's no restriction on naming as it is not renaming anything, it is nothing more than a display name. Hope that makes sense. I'm not trying to be argumentative, but renaming is important for identifying plugins faster. Currently there is no way to do so for VST3 or CLAP unless I missed it? But I checked everywhere within the plugin manager and browser and can find no way to change names for VST3 plugins.

Why would I want to rename a plugin from it's given name? Easy, legibility! My eyes aren't perfect and having names in all lower case, all upper case, using symbols or lack of spaces between words is a hassle. If I rename them, I can then see them ok and don't waste my time trying to figure out what a specific name is. It's all too regular that developers have no clue how to name things for legibility, no offence meant, just an observation, plugins are some of the worst offenders in this area.

Btw, I never said anything about renaming the actual filename. This was something you have incorrectly misinterpreted. Easily done. So no, this isn't about that at all. Just simply using the PluginDatabase file to display a custom name for the specific entry wherever it may be used in MuLab. Something totally different from what your post was about.

[Michael L]

renaming is important for identifying plugins faster
developers have no clue how to name things

Examples abound

[MuTools]

I don't think I follow the implications of what you are saying. But then I kinda do. You are saying there are now two types of plugins shown in the database: Files and Items.

No, not really.
I can't explain it better than in my previous post though.
Maybe the confusion comes from this: A plugin DLL file is not a plugin, it contains plugins (aka plugin items)

Again, i did not choose for this complexity.
It's VST3 + CLAP that impose it.
I don't like it.
And it was expensive to add support for it.

Let's take the uhbiks as an example for renaming. Each is shown in the list as an item, yes? That means MuLab is reading the File and getting the Item names for each, correct? So why can't you just allow the name to be changed within the browser/plugin manager?
...

Technically no problem.
But my question simply was: Why would you want to do that?
You and Michael answered that question now from user pov, thank you.
I was wrong assuming that would be UX overkill.
You guys easily convinced me that it's a handy feature, even almost necessary sometimes, when devs have really badly named the plugin(s) inside a plugin DLL file.
So the next update will allow renaming the plugins itself too, aka the plugin items, ie. the names you see in the brower.

Btw, I never said anything about renaming the actual filename. This was something you have incorrectly misinterpreted.

I did not misinterprete anything.
I guess you must have misinterpreted something i wrote in my last post.
Anyway, we know we have a difficult communication, so lets leave it.

Renaming of plugin items will be added.

[sl23]

Ok, sorry for the confusion. Thank you, for adding it back in.

[MuTools]

The MuLab 10.1.5 versions for Mac have been removed because there is an issue with them.

[MuTools]

MuLab App M10.1.6 beta for Win64 is available on https://www.mutools.com/mulab/app/lates ... /beta.html

MuLab Plugin M10.1.6 beta for Win64 is available on https://www.mutools.com/mulab/plugin/la ... /beta.html

What's changed:

• Support for renaming the actual plugins in the database.
• When MuLab detects that the PluginDatabase.xml has a different version, it auto backs up that file before it's overwritten with the new plugin database. (also in the User/Settings folder)

[sl23]

[pljones]

Screenshot 2025-09-25 175751.png

Could there be a way to remove the Custom File Name? (As this was the default display name, rather than the Product Name, I wanted to know where a file came from at a glance. In my case, it's the same installer putting the same file in two places, so it's only the displayed name I want to change. I'm not sure what need the custom file name fulfils now -- it would prevent Plugin Name v9 and Plugin Name v10 clashing if they were otherwise un-identifiably different, just in different locations, I guess.)

[pljones]

OK, so when I rerun a full scan over Program Files, a ton of DLLs are found and MuLab happily doesn't crash (having been told to skip jsoundds.dll). When I go into Plugin Manager, VST2, Effects, I see a whole bunch of stuff...

Screenshot 2025-09-25 180758.png

Taking 7-zip as an example:

Screenshot 2025-09-25 180849.png

but it's not list as unrecognised:

Screenshot 2025-09-25 180945.png

Remove Unrecogniseds says, reasonably enough:

Screenshot 2025-09-25 181037.png

Saying "No" gets me

Screenshot 2025-09-25 181123.png

although there look to be rather a lot. (Remove Unfounds doesn't find any unfounds.)

[MuTools]

Screenshot 2025-09-25 175751.png
Could there be a way to remove the Custom File Name?

Select a relevant plugin in the list -> Info frame -> Options button -> Rename DLL File.
Note that this is not the display name, it's about the DLL name in the database.
The DLL name is only relevant for retrieving plugins upon loading projects/presets.
Generally: It's recommended to not use custom DLL names, unless you're an advanced user and know what this is about. There could also be legacy reason because custom DLL names were allowed in M8, M9, M10.0.

so it's only the displayed name I want to change.

If you want to change the display name, you have to change the plugin name itself. (ie. the plugin item name)
This can be done via right-click on the plugin list item, both in Plugin Manager and Browser.

I'm not sure what need the custom file name fulfils now

Example: When you have 2 installations of the very same plugin, maybe only a different version of that same plugin. By default they would both have the same DLL name in the database and that can be ambiguous upon loading projects/presets. A custom DLL name allows sorting out such issue. It's very exceptional that you would want to use a custom DLL name. But custom DLL names must still be supported for legacy reasons.

Does this clarify it?

[MuTools]

OK, so when I rerun a full scan over Program Files, a ton of DLLs are found and MuLab happily doesn't crash (having been told to skip jsoundds.dll). When I go into Plugin Manager, VST2, Effects, I see a whole bunch of stuff...
...
Taking 7-zip as an example:
...
but it's not list as unrecognised:
...

That's odd. And i can't repeat it using 7zip.
Please email me your PluginDatabase.xml file
It's in your MuLab/User/Settings folder.

Remove Unrecogniseds says, reasonably enough:
...
Saying "No" gets me
...
although there look to be rather a lot.

Little bug that will be fixed in the next update.

[MuTools]

OK, so when I rerun a full scan over Program Files, a ton of DLLs are found and MuLab happily doesn't crash (having been told to skip jsoundds.dll). When I go into Plugin Manager, VST2, Effects, I see a whole bunch of stuff...
...
Taking 7-zip as an example:
...
but it's not list as unrecognised:
...

That's odd. And i can't repeat it using 7zip.
Please email me your PluginDatabase.xml file
It's in your MuLab/User/Settings folder.

Ok, no need to send your PluginDatabase.xml
It's related to the fact that 7zip was already in your M10.0 database and it got imported as a VST2.
Rescanning should fix that, but there is an issue there.
Will research further.