MuLab 10.1.25

Official support for: mutools.com
Post Reply New Topic
RELATED
PRODUCTS

Post

sl23 wrote: Tue Sep 16, 2025 2:02 pm Uhbik, not showing all plugins, only one displayed.
Try rescanning Uhbik: Plug Manager -> Right-click Uhbik -> Rescan

Post

sl23 wrote: Tue Sep 16, 2025 2:02 pmBtw, no plurals for these:
Remove Unrecognizeds
Remove Unfounds
Nouning adjectives is acceptable ;)

("Nominalized Adjectives")

Post

Really? it's wierd! lol

Post

MuTools wrote: Tue Sep 16, 2025 5:09 pm
sl23 wrote: Tue Sep 16, 2025 2:02 pm Uhbik, not showing all plugins, only one displayed.
Try rescanning Uhbik: Plug Manager -> Right-click Uhbik -> Rescan
MuLab scanned on startup. But I did as you said, and now none of the shell vst's are in the plugin manager!
I have had to manually add them via Add Plugin.

Post

sl23 wrote: Tue Sep 16, 2025 8:55 pm
MuTools wrote: Tue Sep 16, 2025 5:09 pm Try rescanning Uhbik: Plug Manager -> Right-click Uhbik -> Rescan
MuLab scanned on startup. But I did as you said, and now none of the shell vst's are in the plugin manager! I have had to manually add them via Add Plugin.
So finally you now have all Uhbik plugins available, right?

Post

Sorry, yes, I do. I think everything is on order now. Thanks Jo.
It was just that uhbik was omitted from the initial scan at startup after updating. So I had to add it manually. But all ok now. :)

Post

sl23 wrote: Wed Sep 17, 2025 9:17 pm Sorry, yes, I do. I think everything is on order now. Thanks Jo.
It was just that uhbik was omitted from the initial scan at startup after updating. So I had to add it manually. But all ok now. :)
Maybe that initial rescan was aborted due to a crashing plugin before reaching Uhbik, could that have been the case?

In the next M10.1.2 update, a rescan will neatly continue even on a next run if a plug crashed a previous rescan.

Post

When you select a category in the browser, do the categories remain open (expanded) til closed or do they close automatically? They seem to close a lot and I don't know if I'm doing that heh, since sometimes they don't close.

thx

Post

They *should* keep their open/close state until you change that.
But there may be cases where it's reset.
If you find a case where it's not keeping its open/close state and which feels uncomfortable, let me know.

PS: Maybe best to wait until M10.1.2 to check it as quite some polishing has already been done.

Post

MuTools wrote: Wed Sep 17, 2025 9:44 pm They *should* keep their open/close state until you change that.
But there may be cases where it's reset.
If you find a case where it's not keeping its open/close state and which feels uncomfortable, let me know.

PS: Maybe best to wait until M10.1.2 to check it as quite some polishing has already been done.
Ok great, thanks :tu:

Post

MuTools wrote: Wed Sep 17, 2025 9:28 pm
sl23 wrote: Wed Sep 17, 2025 9:17 pm Sorry, yes, I do. I think everything is on order now. Thanks Jo.
It was just that uhbik was omitted from the initial scan at startup after updating. So I had to add it manually. But all ok now. :)
Maybe that initial rescan was aborted due to a crashing plugin before reaching Uhbik, could that have been the case?

In the next M10.1.2 update, a rescan will neatly continue even on a next run if a plug crashed a previous rescan.
No, there wasn't a crash. Just neatly scanned and started.

Post

sl23 wrote: Thu Sep 18, 2025 6:36 am No, there wasn't a crash. Just neatly scanned and started.
Do you happen to have a log file or saved scan log of that scan?

Post

masterjoe wrote: Tue Sep 16, 2025 9:29 am Only use ONE plugin database for both MuLab app and plugin, they shall share it.
sl23 wrote: Tue Sep 16, 2025 2:16 pm Wouldn't it be better if all the databases, colour settings, mux patches, etc, were central?
It's less simple as it may seem.

Imagine you would be able to indicate a custom plugin database file path, and use that for a common plugin database file.
Now you use MuLab setup A and change the plugin database and so the plugin database will be saved into that common file. Later you use MuLab setup B, but it's not the same version as MuLab A and it does not recognize the plugin database file and so it starts with an empty plugin database. You add some plugs and it's saved into that same plugin database file. Then you use MuLab setup A again and will only see that couple of plugs added in MuLab B. You won't like this situation.

I'm not saying the idea of a common plugin database file (+ some other setup file candidates) is a bad idea, no, i understand and agree it can be a great option which i would also use myself, but it can also cause problematic situations if the user is not aware of the dangers. Adding such option to use a common setup file is ok to me, but i do not want to add specific code to protect the user from problematic/conflict cases as that's too complex and overkill r&d. It should be an advanced user option with 100% user responsibility.

Just to brainstorm further on this:
What about the option to set a "plugin database copy file" and whenever the plugin database is saved it will also save it into that plugin database copy but with a "Overwrite?" question alert.
This may be less comfortable but more safe. This way each MuLab setup also keeps its own integral setup file, which is a good thing i think. In the example above MuLab A would point to MuLab B's plugin database and MuLab B would point to MuLab A's plugin database.
The "Overwrite?" question could be muted as an extra option, but raising user's responsibility.

I also assume there are 3rd party tools that can execute such copy.
Maybe that would be the best way.

What are your thoughts on this?

Post

Perhaps a common folder? If you want your plugin and MuLab app A and MuLab App B to use common settings/library/looks/etc, then allow users to set a custom location to look for these. Which iirc, there is such an option, so why isn't that feasible?
I imagine there are discrepancies in the logic of how files/settings are used between plugin and app, so if this was made more generic, then maybe that would help?
what do you think?

Post

sl23 wrote: Thu Sep 18, 2025 4:56 pm Perhaps a common folder? If you want your plugin and MuLab app A and MuLab App B to use common settings/library/looks/etc, then allow users to set a custom location to look for these. Which iirc, there is such an option, so why isn't that feasible?
I imagine there are discrepancies in the logic of how files/settings are used between plugin and app, so if this was made more generic, then maybe that would help?
what do you think?
I believe it would help to separately define the database location for each application / plugin setup so that the user can decide whether to share it or not.

During setup and later in MuLab itself you should be able to define the location (path) for the plugin database (or also other data). The default location can be different between app and plugin so that a novice user that takes the default values will not break things ever.
However more advanced users may choose to use the SAME location for plugin and app so that the database is shared. It would help to detect the already installed MuLab setups so that the used database paths for each of them could be displayed and used without searching.

The database (or other data) path should be changeable even after setup in the UI of MuLab itself so that you can change the location of the database at any time as desired.

I believe this should be doable. What do you think?

Post Reply

Return to “MuTools”