MuLab 10.1.25

[pekbro]

About GForce Halogen: Please try this:
Goto Plugin Manager, select GForce Halogen, and enable "Keep DLL Open Until End".
Then Rescan it.
Does that avoid the crash?

It did not crash.

ok, another thing is that it's not updating the browser list properly, though the plugins are listed
in the manager. E.g. they are not being reflected in the browser, even after multiple refreshes.

Note that the browser only lists plugins that are currently usable, ie. it won't list 32 bit plugins on a 64 bit platform. Does that clarify it?

I do see that the browser does not immediately show the very last plugin scanned, but it shows up after a browser refresh. This will be fixed in the next update.

Hmm, it might be the last plugin scanned, as you say, but the refresh and a couple restarts
have not fixed it for me, as yet...

[MuTools]

About GForce Halogen: Please try this:
Goto Plugin Manager, select GForce Halogen, and enable "Keep DLL Open Until End".
Then Rescan it.
Does that avoid the crash?

It did not crash.

Then this must be regarded as a GForce Haligon issue and must be reported to GForce.
I assume all of their plugins will suffer from the same: They seem to access their DLL even after exitDLL has been called.

[pekbro]

About GForce Halogen: Please try this:
Goto Plugin Manager, select GForce Halogen, and enable "Keep DLL Open Until End".
Then Rescan it.
Does that avoid the crash?

It did not crash.

Then this must be regarded as a GForce Haligon issue and must be reported to GForce.
I assume all of their plugins will suffer from the same: They seem to access their DLL even after exitDLL has been called.

I have a number of them, this is the only one that crashes mulab, it is their latest I believe.
Anyway, I shall report it, thanks

[MuTools]

Then this must be regarded as a GForce Haligon issue and must be reported to GForce.
I assume all of their plugins will suffer from the same: They seem to access their DLL even after exitDLL has been called.

I have a number of them, this is the only one that crashes mulab, it is their latest I believe.
Anyway, I shall report it, thanks

Thanks

They can contact me of course if they need specific info and/or a test user key.

[RichardSemper]

Great update
Full scan of all plugins ran smoothly. Removed all plugins and scanned again by folder, and some individually, no hitches.
It's great to have the right click options for favourites and categories without the need to open the plugin manager.

[RichardSemper]

I notice however, that the Rename option, Delete option and the Extra Options i.e. preferred num inputs/outputs have gone from the right click menu in the browser. Rename is still available in the Plugin Manager, but the plugin name changes are not reflected in the browser.
Also the plugin type suffix disappears from the name in the browser when the plugin has been added to a category.

Also, would be nice, if possible, to be able to select multiple plugins and add category to them all at once. At the moment it's at least 5 clicks for each plugin.

[MuTools]

I notice however, that the Rename option, Delete option and the Extra Options i.e. preferred num inputs/outputs have gone from the right click menu in the browser.
Rename is still available in the Plugin Manager, but the plugin name changes are not reflected in the browser.

First of all:
In MuLab 10.1 there are plugin files and plugin items.
A single plugin file can contain many plugin items.
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 allows renaming the plugin file within the database. The real file on disk keeps the same name (changing that could be problematic to some plugins) but you can give it a custom file name in MuLab's plugin database.
A plugin item ( = a real plugin inside a plugin file) only have a single non-editable name and that's the name given by the plugin developer.

So the Rename option in the browser has become obsolete as plugin items cannot be renamed, they're named by the developer. What you still can do though is change the database name of the plugin DLL.
That's what the right-click -> Rename in the Plug Manager does.
But as it's a bit confusing at that location in MuLab 10.1.3 it will be moved to the options menu of the info pane, deliberately a bit more hidden, only for exceptional / power user cases.

Also the plugin type suffix disappears from the name in the browser when the plugin has been added to a category.

Deliberately.
That suffix now is only added when there are 2 or more plugins in the same group with the same name but different plug types.

Also, would be nice, if possible, to be able to select multiple plugins and add category to them all at once. At the moment it's at least 5 clicks for each plugin.

Shift+click.
Even shift+lasso

[pljones]

The other additional feature I'd like is, where multiple APIs for the same plug-in exist with the same Product Name, they get the API as a qualifier. When I look under Developer, I'll see all installed copies of "Plugin X" (CLAP, VST2, VST3) - being able to tell at a glance (without using right-click Info) would speed things up.

[RichardSemper]

A plugin item ( = a real plugin inside a plugin file) only have a single non-editable name and that's the name given by the plugin developer.

Got it. So renaming in the browser is no longer an option.

Also the plugin type suffix disappears from the name in the browser when the plugin has been added to a category.

Deliberately.
That suffix now is only added when there are 2 or more plugins in the same group with the same name but different plug types.

see attached screenshot, showing multiple plugins with same name (but different types) all within the same group.

Also, would be nice, if possible, to be able to select multiple plugins and add category to them all at once. At the moment it's at least 5 clicks for each plugin.

Shift+click.
Even shift+lasso

I tried this - does not work in the browser. I had tried it in the plugin manager using a multiple selection as you suggest, but using the '+' in categories pane only changed the first selected item.
I see now that it does work on multiple selection if using the 'Options' button.

[MuTools]

A plugin item ( = a real plugin inside a plugin file) only have a single non-editable name and that's the name given by the plugin developer.

Got it. So renaming in the browser is no longer an option.

Indeed, because there you see the real plugins ("plugin items", not anymore "plugin files" as in pre M10.1) Note that you can still rename any plugin instance of course!

Will reply on the other points later.

[MuTools]

Also the plugin type suffix disappears from the name in the browser when the plugin has been added to a category.

Deliberately.
That suffix now is only added when there are 2 or more plugins in the same group with the same name but different plug types.

see attached screenshot, showing multiple plugins with same name (but different types) all within the same group.

A bug indeed, will be fixed in the next M10.1.3.

Shift+click.
Even shift+lasso

I tried this - does not work in the browser.

Indeed i meant in the Plugin Manager.

[MuTools]

The other additional feature I'd like is, where multiple APIs for the same plug-in exist with the same Product Name, they get the API as a qualifier. When I look under Developer, I'll see all installed copies of "Plugin X" (CLAP, VST2, VST3) - being able to tell at a glance (without using right-click Info) would speed things up.

In M10.1.3 there's a bug fix that will make that also inside developer groups the plug type is appended when there are multiple plugs with the same name but diff type.

[sl23]

What you still can do though is change the database name of the plugin DLL.
That's what the right-click -> Rename in the Plug Manager does.
But as it's a bit confusing at that location in MuLab 10.1.3 it will be moved to the options menu of the info pane, deliberately a bit more hidden, only for exceptional / power user cases.

Why hide it? If its a database change only, which is what it has always been, or at least I thought it was, 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? 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. If internal names are required, then don't go via the database name use the internal name.
Perhaps I am missing something?

[pekbro]

Jo, I hit your donation button as this is such a great quality of life update... seriously appreciate your efforts

[MuTools]

Jo, I hit your donation button as this is such a great quality of life update... seriously appreciate your efforts

Thanks pekbro