v17

[GusGranite]

Just want to say thank you for the update. That’s all.

[jan-sandahl]

17.01 changes announced on the webpage, but the installer didn't get me that version.

- You?

[tonycore]

17.01 changes announced on the webpage, but the installer didn't get me that version.

- You?

The automatic update of the manager and the plugins to 17.01 went smoothly here. (MacOS 12.7.6 on a 2017 iMac, also same OS on 2021 MBP M1Pro)

[jan-sandahl]

Weird. Tried again. Nothing...

[jan-sandahl]

Today it worked, on the second try. It _seemed_ to be related to opting out of allowing beta versions. Oh well...

[dmcsweeney]

Re: MGuitarArchitect.
Are there any plans to add stereo+ support for Non-standard wavenet NAM models?
Currently, stereo only works for standard models, but it'd be fantastic to have stereo support working for the other model types.
(Nano, Feather, Lite, Standard).

[Rockis]

I have questions. Martin.
You said the melda company can know what DAW and OS we use by the mpluginmanager app. If that's possible, i guess it can detect other information as well.
I dont want Plugin companies collect our personal information even in this way seriously.

I tested new offline system you suggested today. But This offline system still use same mpluginmanager.
You know, Sometimes i just turn on and off my wifi and like to use my laptop as offline computer. (When i download an app or something, i turn on wifi. when i work, i turn it off usually.)
But, even if i installed plugins when the laptop was offline, the pluginmanager work as online app again when i turn my wifi on again.
i've seen you said 99.9percent users use internet. But it doesn't mean we want and need to use online automatic data collecting downloading manager app. And The app always shows me 'Do you want to allow this app to make changes to your device?' Pop up window.

We are going to release a new version of MPluginManager this week. There will be an option in the settings where you can enable or disable automatic package updates (for plugins and instruments). If disabled, you will have the choice to perform the update or not. This feature was available in the pre-release versions, making the update process less aggressive. For MPluginManager itself, this option will not be available, as we want to ensure you stay on the most recent version of the installer. In case of any issues in installer itself (which we do not expect), you can usually find the older version in your Downloads folder, or we can provide links to previous installers if needed.

So Why do you want to ensure that we stay on the most recent version of the installer?
The mplugin manager app itself is the most forceful concept here.
when i click the mplugin manager, why it should download the new version of mpluginmanager right away after the popup?

And, Even if i install older mpluginmanager again, it automatically downloads new version of mpluginmanager i deleted right away. So it makes downloading older mpluginmanager a pointless process here.

Many melda plugin-fans love OS like Linux and DAW like Reaper.
It means Linux, reaper and melda have something in common here: the users like their tweakablity, freedom and options we can choose. And It also means most users dont want any forceful things.

[audiojunkie]

I have questions. Martin.
You said the melda company can know what DAW and OS we use by the mpluginmanager app. If that's possible, i guess it can detect other information as well.
I dont want Plugin companies collect our personal information even in this way seriously.

I tested new offline system you suggested today. But This offline system still use same mpluginmanager.
You know, Sometimes i just turn on and off my wifi and like to use my laptop as offline computer. (When i download an app or something, i turn on wifi. when i work, i turn it off usually.)
But, even if i installed plugins when the laptop was offline, the pluginmanager work as online app again when i turn my wifi on again.
i've seen you said 99.9percent users use internet. But it doesn't mean we want and need to use online automatic data collecting downloading manager app. And The app always shows me 'Do you want to allow this app to make changes to your device?' Pop up window.

We are going to release a new version of MPluginManager this week. There will be an option in the settings where you can enable or disable automatic package updates (for plugins and instruments). If disabled, you will have the choice to perform the update or not. This feature was available in the pre-release versions, making the update process less aggressive. For MPluginManager itself, this option will not be available, as we want to ensure you stay on the most recent version of the installer. In case of any issues in installer itself (which we do not expect), you can usually find the older version in your Downloads folder, or we can provide links to previous installers if needed.

So Why do you want to ensure that we stay on the most recent version of the installer?
The mplugin manager app itself is the most forceful concept here.
when i click the mplugin manager, why it should download the new version of mpluginmanager right away after the popup?

And, Even if i install older mpluginmanager again, it automatically downloads new version of mpluginmanager i deleted right away. So it makes downloading older mpluginmanager a pointless process here.

Many melda plugin-fans love OS like Linux and DAW like Reaper.
It means Linux, reaper and melda have something in common here: the users like their tweakablity, freedom and options we can choose. And It also means most users dont want any forceful things.

I agree with this.

[FatGuy]

I'm also a Linux user with Reaper and Melda plugins because I like having full control over my setup. This new offline method is really disappointing

[martin-meldaproduction]

To audiojunkie, fatguy:

Nope, this was mentioned by my colleague that the plugins (not MPluginManager!) perform DAW/OS reporting from time to time. This feature has been in the plugins for ages, and it's explained in the help section. You are free to disable it if you wish (from the plugin settings menu). It's useful for us to know which DAW to prioritize for testing, as there are over 30+ DAWs at the time of writing...

I want to reassure you that MPluginManager does not collect or report any data from you, so you can safely use it without any concerns. Of course, we want to ensure you stay on the latest version of the installer, as newer versions contain important new features and bug fixes - see more on this topic bellow. It's the same as with older MeldaPlugins installers — we always provided the latest version of the installer with the plugins and never allowed the use of older versions. You could do it only by installing older version of plugins - plugins and installers were bundled together.

In the near future, we will introduce a "time machine" feature, allowing you to switch between different plugin/instruments versions, e.g., from v17.01 to v17.00 or from v17.00 to v17.05 (when available), between beta/stable versions. The same will be possible in offline mode. This way, if a new update "breaks" something you rely on, you'll have the option to revert to a previous version of the plugins and the corresponding install packages — but not the installer itself, as that wouldn’t make much sense.

By the way, there is a new offline installation possibility available - see this thread: viewtopic.php?t=613940

More to MPluginManager self updates:
Consistency & Reliability - Keeping the installer up to date ensures that it functions properly with the latest versions of the plugins it manages. Older installers may not support new features, dependencies, or bug fixes that newer plugins require, which can lead to compatibility issues.

Bug Fixes & Security - An up-to-date installer typically comes with essential bug fixes and security updates, which is especially critical in an installer that interacts with tons of software. Outdated installers can introduce vulnerabilities or functional problems that affect the user's overall experience.

User Experience- Allowing outdated versions of the installer could and will complicate support processes. For example, if users report issues but are using an older installer, troubleshooting becomes more difficult. By keeping the installer updated, you ensure a smoother support process.

Even on Linux, core components like installers and package managers typically update themselves to ensure they can handle new dependencies and software versions.

We could potentially add a switch to disable MPluginManager self-updates, but unless we see strong, logical reasons for it, this option is more risky than useful.

[audiojunkie]

Thank you Martin for taking the time to respond and acknowledge our concerns!

When using Linux, because there is not a linux native version of the software, we will have to use WINE and yabridge to get things to work. Because of the nature of the procedure of running non-native plugins, it is safer for us to not change things once we get them running. It would be greatly appreciated if you added a switch to allow users to choose to not receive automatic updates. You could even keep the default setting to be to receive automatic updates—there probably won’t be as many people concerned about updates breaking things. But for Linux users, it would be very helpful for prolonged stability. Likely, I would have automatic updates turned off, and once a few people have tried the new update and proven it won’t break things, I’d probably turn it on long enough to let the update take place, and turn it off again until the next update. This gives us a little more control as to “when” we choose to do the update—once we are sure everything will be ok.

As for the new off line installer—Thank you so much! I really appreciate it! It means a lot to me that you are working with us to resolve our concerns! It really shows how much you care about your customers! I know that many think of us Linux users a a very particular or unusual group—while we aren’t opposed to developers using copy protection to prevent piracy, we do admit our desire to be able to reinstall our purchased software onto a new computer if needed, even in the absence of a company’s existence. You have made several accommodations for us in several regards, and your company doesn’t even officially support Linux. That says so much good about the kind of company you run. I really appreciate all you do!!

[FatGuy]

Thank you Martin, for your response!

The time machine feature sounds really interesting. I have a quick question about it if I create a project using version 18.1 and later decide to revert to version 17.5, will the project still load properly? In other words, does this mean newer versions are not only backward compatible but also provide the option to ensure a project can be opened in a previous version?

I’d also appreciate the option to disable automatic updates for both MPluginManager and the plugins. This would help avoid potential compatibility issues. I just need the plugins to work reliably, and while newer versions may come with improvements and bug fixes, I prefer to stick with what works and only update when necessary

[martin-meldaproduction]

I understand your requirements and the rationale behind them. The option to disable automatic plugin updates is already included in MPluginManager v01.10. Similarly, the ability to disable automatic updates for MPluginManager itself will be available in the upcoming v01.11. However, to fully observe this feature in action, you will be able to test it when v01.12 is released, assuming you choose to disable it in v01.11. That said, I hope you will continue using the latest version of the installer whenever possible:-)

Regarding the "time machine" function, its primary purpose is to provide the ability to revert to a previous version in case of unexpected issues. For example, if you upgrade from v17.10 to v17.15 and notice a drop in performance in your project, you might discover—after checking the forums—that a performance bug exists in v17.15 in one of the plugins. By reverting to v17.14, everything should work as expected. While no one intends to introduce bugs, we want to ensure you have the option to return to a stable version if necessary.

We maintain backward compatibility, meaning that projects using plugins, instruments, and their associated parameters and features will continue to function in future releases. This ensures that upgrading to the latest version is always safe - should be:-). What you referred to is forward compatibility, which, technically, is not possible unless we can foresee future changes. For instance, if new parameters are introduced in a plugin in v18.1 and you automate them, then downgrade to v17.5, those parameters won’t exist in the older version, leading to potential errors. In such cases, an intelligent DAW would detect the issue, and you would need to remove the unsupported part. But of course, if your project uses parameters and features that exist in both versions, the project will work without any issues. This is the nature of forward compatibility.

[FatGuy]

Thank you very much for your explanation!

[audiojunkie]

I understand your requirements and the rationale behind them. The option to disable automatic plugin updates is already included in MPluginManager v01.10. Similarly, the ability to disable automatic updates for MPluginManager itself will be available in the upcoming v01.11. However, to fully observe this feature in action, you will be able to test it when v01.12 is released, assuming you choose to disable it in v01.11. That said, I hope you will continue using the latest version of the installer whenever possible:-)

Regarding the "time machine" function, its primary purpose is to provide the ability to revert to a previous version in case of unexpected issues. For example, if you upgrade from v17.10 to v17.15 and notice a drop in performance in your project, you might discover—after checking the forums—that a performance bug exists in v17.15 in one of the plugins. By reverting to v17.14, everything should work as expected. While no one intends to introduce bugs, we want to ensure you have the option to return to a stable version if necessary.

We maintain backward compatibility, meaning that projects using plugins, instruments, and their associated parameters and features will continue to function in future releases. This ensures that upgrading to the latest version is always safe - should be:-). What you referred to is forward compatibility, which, technically, is not possible unless we can foresee future changes. For instance, if new parameters are introduced in a plugin in v18.1 and you automate them, then downgrade to v17.5, those parameters won’t exist in the older version, leading to potential errors. In such cases, an intelligent DAW would detect the issue, and you would need to remove the unsupported part. But of course, if your project uses parameters and features that exist in both versions, the project will work without any issues. This is the nature of forward compatibility.

You are awesome!! Thank you so much for keeping us Linux users in mind, even if there is no “official” support!