The UI is missing the text label "Distortion Type" followed by its name for the 11th distortion type

[TheMicronauts]

This introduces a small cognitive inefficiency when forming a mental model of the device, documenting the session and communicating about it with colleagues.

Steps to Reproduce:
Cycle through the Distortion selector until the 11th position

Operating System:
macOS

Plugin Version:
1.0.1 & 1.2.1 (and likely all versions in between)

Suggested Fix:
Ensure the 11th distortion type triggers the display of both the "Distortion Type" label and its corresponding name in the UI, consistent with other types

[Lunix-420]

Thanks for reporting this! You're right, the 11th distortion type is definitely missing.

Should be a pretty minor fix, gonna make sure to get a patch out soon.

[Lunix-420]

Should be fixed with #31

I'm gonna build and release it tomorrow.

[Lunix-420]

I'm done building, signing, and notarizing the macOS version. This build also includes a few new features. I’ll post a release once we’ve tested all the builds, but you can try it early here:

plasma-v1.3.0-macos.pkg.zip

This build will most likely report that it’s outdated. The server still thinks 1.2.1 is the newest, so it’ll flag 1.3.0 as different from the latest until I push the official release, even though this is actually newer.

[TheMicronauts]

Thanks for the quick fix! It is working as expected in VST and AU v1.3.0. No 'outdated' warning for me. Looking forward to checking out the new features in the official release.

[TheMicronauts]

Update: Until now, I had only tested Plasma using Blue Cat's PatchWork on my laptop (the version of Cubase I own requires a physical dongle to launch, which, by definition, is never within arm's reach when needed).

Today I’m in the studio, so I had the opportunity to launch the Plasma VST3 v1.3.0 within Cubase 10.5, on macOS 10.13 High Sierra. Unfortunately, the graphics are off; please see the attachment.

It isn't a big deal for me, as I'll use it via PatchWork, which allows me to easily and reliably MIDIfy it. Additionally, I suspect my specific Cubase and macOS versions are full of graphical bugs, given that I encounter these problems on a regular basis. But I figured you’d want to know.

⁂

I’d also like to take this opportunity to recommend adding a 'Close' button to the Config Panel. It always takes me a moment to realise that the Config button itself is used to close it without Saving or Resetting, as it's located elsewhere and doesn't provide a clear visual clue.

[Lunix-420]

About the graphical issues in Cubase on macOS 10.13 you reported. I just want to clarify if I understood this correctly. From your description, it sounds like this is not specific to this plugin, but something you’ve run into with other plugins as well? I'm mostly asking because I read some stories about Cubase 10.5 having issues with plugins that use JUCE as the framework, which would mean I can't fix this and trying would pretty much be a waste of time.

Regarding the Config panel, I could probably make it change the buttons text when the user is in the config display.

Thanks again for your feedback.

[TheMicronauts]

Let's just say that I do encounter this issue from time to time. For instance, it happens with UVI Falcon, but simply resizing its window restores the UI to its normal appearance. Furthermore, unticking 'OpenGL renderer' in the Preferences completely eliminates the problem.

I’ve noticed that UVI isn't the only developer offering the option to disable the OpenGL renderer; FabFilter does the same, for example. Since their instructions cover Windows as well, I’m not entirely sure that this issue is strictly limited to my specific OS and host combination: https://www.fabfilter.com/support/faq#how-can-i-disable-graphics-acceleration-on-my-computer

If this is indeed related to JUCE, I wonder if it might be a version-specific issue? I have many other JUCE-based plugins that don't exhibit this behaviour, so perhaps a different framework version would behave differently.

[Lunix-420]

Let's just say that I do encounter this issue from time to time. For instance, it happens with UVI Falcon, but simply resizing its window restores the UI to its normal appearance. Furthermore, unticking 'OpenGL renderer' in the Preferences completely eliminates the problem.

Huge, thanks a lot for pointing that out! I think UVI is also using JUCE. At least, they are listed under Made with JUCE.

So to me, that really sounds like it might be an issue with JUCE's OpenGL backend. The problem is that there is not much I can do to fix it directly, but I could try adding a "disable hardware rendering" setting to turn off OpenGL.

If this is indeed related to JUCE, I wonder if it might be a version-specific issue?

Possible. All projects I made usually ship with more or less the latest JUCE version, since it provides the best performance and most up-to-date bug fixes across the widest range of systems. As far as I know, some developers prefer shipping with an older version, and considering macOS 10.13 has been officially dead for almost a decade, it makes sense that modern versions might start to misbehave more.

Also, I’m assuming not all JUCE plugins use the OpenGL backend, some probably use CPU-based rendering, and others might even have custom hardware rendering with Metal.

[TheMicronauts]

macOS 10.13 has been officially dead for almost a decade

I’ve got no time for technofascists 🤷‍♂️

[Lunix-420]

I made some changes based on your suggestions.

Changes

• Added option to disable the OpenGL hardware renderer on Mac and Linux to fall back to software rendering
• When inside the config menu, the config button now shows "return" instead of "config" to better communicate that clicking it again will close the configs

plasma-v1.3.0-macos.pkg.zip

[TheMicronauts]

After testing, I can confirm that disabling the OpenGL hardware renderer cured the UI distortion. However, the problem is I can't do that from Cubase, since initially, the UI is distorted and does not show the Config button or the following dialogue. I need another host that doesn't have the same problem (PatchWork in my case). I guess another approach should be chosen.

I can confirm also that the config button now shows "Return" instead of "Config". I would have expected it to show "Cancel" and act as a button for cancelling modifications and closing the dialogue. As it is now, it acts as a "save modifications and close dialogue" button, which is making the Save button a bit redundant.

[Lunix-420]

However, the problem is I can't do that from Cubase, since initially, the UI is distorted and does not show the Config button or the following dialogue. I need another host that doesn't have the same problem (PatchWork in my case). I guess another approach should be chosen.

I failed to mentioned this, but you don’t actually need to use the plugin UI to enable that setting. The configuration can also be edited manually via the config file. I’m planning to include a troubleshooting section in the README.md that explains how to do that, for when the feature is officially released.

As it is now, it acts as a "save modifications and close dialogue" button, which is making the Save button a bit redundant.

Exiting the config menu does not actually save any changes. This is so you can leave the config menu and preview how the plugin looks with the current settings before explicitly saving them.

I can confirm also that the config button now shows "Return" instead of "Config". I would have expected it to show "Cancel" and act as a button for cancelling modifications and closing the dialogue.

I feel like, from a UX perspective, a button that opens a menu switching to a “Cancel” action would be kinda inconsistent. Keeping it as a “Return” action that just throws you back to where you came from is a way more natural and consistent UX.

You definitely got a point though, adding a dedicated option to revert to the last saved state would be pretty useful. As of now, you basically need to close and reopen the plugin window for that, which isn’t exactly smooth UX. However, I feel like it should be grouped with "Save" and "Reset" so all state related actions are in one place. I'm probably gonna implement that.

[TheMicronauts]

I failed to mentioned this, but you don’t actually need to use the plugin UI to enable that setting. The configuration can also be edited manually via the config file. I’m planning to include a troubleshooting section in the README.md that explains how to do that, for when the feature is officially released.

Ah, I see. Yes, that approach will work.

I feel like, from a UX perspective, a button that opens a menu switching to a “Cancel” action would be kinda inconsistent. Keeping it as a “Return” action that just throws you back to where you came from is a way more natural and consistent UX.

You definitely got a point though, adding a dedicated option to revert to the last saved state would be pretty useful. As of now, you basically need to close and reopen the plugin window for that, which isn’t exactly smooth UX. However, I feel like it should be grouped with "Save" and "Reset" so all state related actions are in one place. I'm probably gonna implement that.

You're 100% right about the UX. At the moment, the ability to cancel modifications is impossible to guess; you’d only find it by chance. If you don't mind adding a third "Cancel" button, it makes that option explicit, and it's definitely logical to have it offered in the same place as "Save" and "Reset."