MuLab 10.1.25

[masterjoe]

BTW:

You should save a version info in the plugin database / config data folder so that when a user tries to overwrite this data with a seemingly incompatible version a warning can be display that the existing data is not compatible with the data that will be written to that location. This simple check prevents accidents and still gives a user the flexibility to update a database even when compatibility is broken.

[MuTools]

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?

Common settings folder or common setting files makes no difference wrt the possible issues i mentioned.

[MuTools]

BTW:

You should save a version info in the plugin database / config data folder so that when a user tries to overwrite this data with a seemingly incompatible version a warning can be display that the existing data is not compatible with the data that will be written to that location. This simple check prevents accidents and still gives a user the flexibility to update a database even when compatibility is broken.

That would mean that if a user, lets say a non-geek user, only has 1 single MuLab setup and the user updates MuLab which uses a newer format for some setting files then that user will get unexpected questions "Overwrite setting file X which has an older format?". That would not be ok.

[MuTools]

The option for a common plugin database is on the wishlist but i'm gonna give it some more time.
Not for M10.1.

[MuTools]

PS: I still wonder whether this is not solvable using a 3rd party tool, eg. a scripting tool, that can do all kinds of things including copying files. Then execute such script after having used one of your MuLab setups.

[masterjoe]

BTW:

You should save a version info in the plugin database / config data folder so that when a user tries to overwrite this data with a seemingly incompatible version a warning can be display that the existing data is not compatible with the data that will be written to that location. This simple check prevents accidents and still gives a user the flexibility to update a database even when compatibility is broken.

That would mean that if a user, lets say a non-geek user, only has 1 single MuLab setup and the user updates MuLab which uses a newer format for some setting files then that user will get unexpected questions "Overwrite setting file X which has an older format?". That would not be ok.

No. If you have everything saved correctly in the version info file (that MuLab puts there) then you can decide whether an update is ok or (potentially) not ok. You could also save an info there WHO is using that folder (which app or plugin plus version), whenever a shared use happens. This allows each using app to known how many other MuLab based stuff used that folder. This allows detecting problems.

So if a folder with this database / settings is NOT shared and the update is an upgrade then no message would be displayed of course.

[masterjoe]

PS: I still wonder whether this is not solvable using a 3rd party tool, eg. a scripting tool, that can do all kinds of things including copying files. Then execute such script after having used one of your MuLab setups.

I think this is not intuitive, you have to know how MuLab does this and where it stores things and it allows for all kind of issues (as already mentioned) that a clever mechanism included in MuLab could solve.

The suggestions so far are not that complicated and would help a lot without any "hacking".

- save a version info for the data / database to check compatibility
- save all app / plugin info (origin, version etc.) that share that data
- implement the setup for sharing (define a path)
- implement a check that looks for compatibility issues and warns the user before overwriting data - but just in problematic use cases

So it would be wonderful if you think about it and maybe - even if it's not 10.1 - such a feature gets its way into MuLab sometime soon

Thanks a lot for all your great work!

[MuTools]

No. If you have everything saved correctly in the version info file (that MuLab puts there) then you can decide whether an update is ok or (potentially) not ok. You could also save an info there WHO is using that folder (which app or plugin plus version), whenever a shared use happens.

- save a version info for the data / database to check compatibility
- save all app / plugin info (origin, version etc.) that share that data
- implement the setup for sharing (define a path)
- implement a check that looks for compatibility issues and warns the user before overwriting data - but just in problematic use cases

Thanks for thinking loud, but that's the overkill complexity i want to avoid, as i mentioned in my earlier post. It's easy to write this in a draft post, it's less easy to implement this, and we might not yet have thought of new issues in your idea. And even if it would be implemented, it also brings the responsibility when something doesn't work right. It's potentially a lot of extra work / can of worms while the use case is solvable with an external copy tool. I have to carefully balance where to invest r&d time in. Many other challenges and requests. I'll surely keep it on the wishlist but will give it more time.

[MuTools]

I think this is not intuitive, you have to know how MuLab does this

You only need to know the file path.
For the plugin database that is "{UserFolder}/Settings/PluginDatabase.xml"

So it would be wonderful if you think about it and maybe - even if it's not 10.1 - such a feature gets its way into MuLab sometime soon

I understand and agree it would be handy to share the plugin database between MuLab App and MuLab Plugin. It's on the wishlist but needs sufficient careful thought.

Thanks a lot for all your great work!

Thank you.
Please nominate + vote MuLab here:
https://www.kvraudio.com/readers-choice-awards/2025/

[MuTools]

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

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

What's changed:

• Initial dialogs like "Rescan Plugin Database" now appear upon the startup splash instead of appearing without any MuLab window.
• When there is a plug scan crash while doing the requested rescan on startup, on next startup the same scenario repeated itself. Fixed.
• When a long rescan crashes, MuLab now properly proposes to skip the crashed file, and also only does a partial rescan ie. not a complete rescan.
• "Rescan previously crashed file?" question now also has the options Yes To All and No To All.
• New "Plugin Developer Grouping" preference. Also editable via the Options button in the Plugin Manager + Project Browser.
• Project Browser -> Synth/Effect Plugins now include the option to toggle the Favorite tag and edit categories, thus avoiding the need to go via the Plugin Manager.
• Project Browser -> Plugins: Removed the redundant "Rename" option from the context menu.
• Project Browser -> Plugins: "Where" is used to choose a category. Now only relevant categories are listed.
• MUX Front Panels: Copy-paste group frame looks was working incomplete. Fixed.
• When a modular connection editor was shown, it was not closed upon doing New Project. Fixed.
• Other small improvements.

Note: For the sake of testing MuLab 10.1.2 will also propose a full rescan on startup.

[pekbro]

Hmm, this version won't scan Halogen_FM from GForce without crashing, had to remove it to get through the scan, though it's listed as being ok and already in the database, also working fine.

*Developer Grouping is great! Thanks for that

*Log excerpt from after replacing the plugin and manually initiating a scan of it.

Code: Select all

0x00004720 11:28:52:689 MessageAlert: Succesfully scanned 1 plugin file
0x00004720 11:28:52:689 BWndw[106] 000000001C202010
0x00004720 11:28:52:692 BWndW[781] 000000001931CF90
0x00004720 11:28:52:693 BWndW[786] 000000001C202010
0x00004720 11:28:52:694 BWndW[757]
0x00004720 11:28:52:695 BWndW[757]
0x00004720 11:28:52:696 Exception in user thread
0x00004720 11:28:52:696 Exception code=C0000005
0x00004720 11:28:52:696 Exception address=00007FFBD944A4B0
0x00004720 11:28:52:696 Exception in user thread
0x00004720 11:28:52:696 Exception code=C0000005
0x00004720 11:28:52:696 Exception address=000000014016B86A
0x00004720 11:28:52:696 Exception code bytes[-8]=49 8B 45 00 48 8B 70 10
0x00004720 11:28:52:696 Exception code bytes=0F B6 4E FE 0F B6 56 FD
0x00004720 11:28:52:696 Exception code bytes[+8]=0F B6 46 FF 44 0F B6 56
0x00004720 11:28:52:696 Rax BF31F0
0x00004720 11:28:52:696 Rcx 3A
0x00004720 11:28:52:696 Rdx 0
0x00004720 11:28:52:696 Rbx 22
0x00004720 11:28:52:696 Rsp BF1FC0
0x00004720 11:28:52:696 Rbp BF20C0
0x00004720 11:28:52:696 Rsi 7FFBD944A4B0
0x00004720 11:28:52:696 Rdi 22
0x00004720 11:28:52:696 App base address=0000000140000000
0x00004720 11:28:52:696 Exception map offset=000000000016A86A
--------------------
0x00004720 11:28:52:696 Caller EIP 0 @ 000000014016BF7B = @ map 000000000016AF7B
0x00004720 11:28:52:696 Caller EIP 1 @ 0000000140BE9A26 = @ map 0000000000BE8A26
0x00004720 11:28:52:696 Caller EIP 2 @ 00000001400CCF3F = @ map 00000000000CBF3F
0x00004720 11:28:52:696 Caller EIP 3 @ 00007FFC7F48796F = @ map 00007FFB3F48696F
0x00004720 11:28:52:696 Caller EIP 4 @ 00007FFC7F396397 = @ map 00007FFB3F395397
0x00004720 11:28:52:696 Caller EIP 5 @ 00007FFC7F4872AE = @ map 00007FFB3F4862AE
0x00004720 11:28:52:696 Caller EIP 6 @ 000000014016B86A = @ map 000000000016A86A
0x00004720 11:28:52:696 Caller EIP 7 @ 0000000140BE9A26 = @ map 0000000000BE8A26
0x00004720 11:28:52:696 Caller EIP 8 @ 00000001400CCF3F = @ map 00000000000CBF3F
0x00004720 11:28:52:696 Caller EIP 9 @ 00007FFC7F48796F = @ map 00007FFB3F48696F
0x00004720 11:28:52:696 Caller EIP 10 @ 00007FFC7F396397 = @ map 00007FFB3F395397
0x00004720 11:28:52:696 Caller EIP 11 @ 00007FFC7F4872AE = @ map 00007FFB3F4862AE
0x00004720 11:28:52:696 Caller EIP 12 @ 00007FFBD944A4B0 = @ map 00007FFA994494B0
--------------------
0x00004720 11:28:52:698 Caller EIP 1 = 0000000000BF20C0 = map @ FFFFFFFEC0BF10C0
--------------------
0x00004720 11:28:52:708 gonna shutdown MIDI engine
0x00004720 11:28:52:721 Gonna shutdown ASIO engine
0x00004720 11:28:52:753 AAE[229]
0x00004720 11:28:52:763 MessageAlert: 
0x00004720 11:28:52:763 A serious error has occured.
0x00004720 11:28:52:763 
0x00004720 11:28:52:763 This may be caused by MuLab App, or caused by a plugin.
0x00004720 11:28:52:763 
0x00004720 11:28:52:763 MuLab App will now try to save the current project as Crashed.MuProject,
0x00004720 11:28:52:763 in your MuLab App User/MuProject/AutoSaved sub-folder.
0x00004720 11:28:52:763 
0x00004720 11:28:52:763 Rename this file as soon as possible to another filename you choose,
0x00004720 11:28:52:763 and then try to re-open it again.
0x00004720 11:28:52:764 BWndw[106] 0000000006E020F0
0x00004720 11:28:52:767 BWndW[781] 000000001C202010
0x00004720 11:28:52:767 BWndW[786] 0000000006E020F0
0x00004720 11:28:52:770 BWndW[757]
0x00004720 11:28:52:771 Error BPS-Win[242]
0x00004720 11:28:52:771 Error BWndW[698] SUTC cbc<1
0x00004720 11:28:54:771 Error BWndW[698] SUTC time-out
0x00004720 11:28:56:771 Error BPS-Win[247] SUTC time-out
0x00004720 11:28:58:771 Error BPS-Win[247] SUTC time-out
0x00004720 11:29:00:770 Error BPS-Win[247] SUTC time-out
0x00004720 11:29:02:771 Error BWndW[698] SUTC time-out
0x00004720 11:29:04:770 Error BWndW[698] SUTC time-out
0x00004720 11:29:06:770 Error BWndW[698] SUTC time-out
0x00004720 11:29:08:771 Error BWndW[698] SUTC time-out
0x00004720 11:29:10:770 Error BWndW[698] SUTC time-out
0x00004720 11:29:12:771 Error BWndW[698] SUTC time-out
0x00004720 11:29:14:771 Error BWndW[698] SUTC time-out
0x00004720 11:29:16:770 Error BWndW[698] SUTC time-out
0x00004720 11:29:18:770 Error BWndW[698] SUTC time-out
0x00004720 11:29:18:770 BWndW[781] 0000000006E020F0
0x00004720 11:29:20:771 Error BWndW[698] SUTC time-out
0x00004720 11:29:22:770 Error BWndW[698] SUTC time-out

[MuTools]

Please share the complete log file. You can also email it if you prefer more privacy.

[pekbro]

Please share the complete log file. You can also email it if you prefer more privacy.

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.

[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?

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.

[MuTools]

PS: I still wonder whether this is not solvable using a 3rd party tool, eg. a scripting tool, that can do all kinds of things including copying files. Then execute such script after having used one of your MuLab setups.

I think this is not intuitive, you have to know how MuLab does this and where it stores things and it allows for all kind of issues (as already mentioned) that a clever mechanism included in MuLab could solve.
...
So it would be wonderful if you think about it and maybe - even if it's not 10.1 - such a feature gets its way into MuLab sometime soon

Ok, i'll brainstorm some further on this topic.
What about this kind of in between solution:

MuLab could support executing a "OnQuitScript.xml" file in your MuLab user folder.
This XML file could be something alike this

Code: Select all

<?xml version=\"1.0\" encoding=\"UTF-8\"?>"
<Action>
  <Do>CopySetupFile</Do>
  <Which>PluginDatabase</Which>
  <ToDestination>C:\SomeFilePath</ToDestination>
  <Confirm>Never/Always/IfDifferentVersion</Confirm>
</Action>

<Action>
...
</Action>

So you could copy the plugin database to multiple locations.
Lateron this script can be extended for other relevant setup files too.

In a first step i would not add a GUI for this, but simply rely on the user making such XML using a text editor. This is about an advanced user option anyway so i expect such user is able to manage an XML file.

Advantages:

* Relatively quick to implement
* Copying files to a proper compatible location is the user's responsibility.

What do you think?
Feel free to make suggestions for the XML format.