Scaling issues on high DPI displays

[samkcarlile]

Edit: tresf, added checklist and workaround:

• [ ] Windows: - Partially working via d2e50df3ce2f8a56fd1750cc077eff3e76a6867d.
• [x] Linux: - Implemented via 8a39302571c96e130dd6db1f466011760fd7f1ec reverted. reimplemented bbedfa9. (Qt5.6+)
• [x] MacOS: - Implemented via 8a39302571c96e130dd6db1f466011760fd7f1ec

Unfortunately some HiDPI displays don't scale properly. There's more discussion around this here: https://github.com/LMMS/lmms/pull/4800#issuecomment-461681138

# HiDPI workaround for problematic screens
export QT_SCALE_FACTOR=1
export QT_AUTO_SCREEN_SCALE_FACTOR=0
export QT_SCREEN_SCALE_FACTORS=2

Or permanently (use with caution!)

# HiDPI workaround for problematic screens
echo -e "QT_SCALE_FACTOR=1\nQT_AUTO_SCREEN_SCALE_FACTOR=0\nQT_SCREEN_SCALE_FACTORS=2" | sudo tee -a /etc/environment

---

This is my first time submitting an issue here, so If I'm doing it incorrectly, please let me know.

I'm on Windows 10 and would like to use LMMS, however, being on a Surface Book with a high DPI display, I can't comfortably use this software without squinting to see the various menu items and text. This application doesn't seem to scale when I scale Windows up. Is this a known issue or is it just me?

[Markon101]

Is there any way to scale ZenAddFX? It is a VST that doesn't scale making it nearly unusable on my laptop.

[dwbullok]

LMMS is still unusable on Linux when using a 4k display. I can change the font sizes of some items with the various QT_* environment variables mentioned above, but many remain far too small to read. With some settings, The fonts are large enough, but they are cropped to an area that a smaller font would use (I only see the top half of the letters). Is this being actively worked on? I'd love to contribute to a fix, but since I can't see anything, I can't learn to use it, so I can't decide whether I'd be inclined to invest the time in working on it.

[tresf]

I'd love to contribute to a fix, but since I can't see anything, I can't learn to use it, so I can't decide whether I'd be inclined to invest the time in working on it.

It may be worth compiling with a more recent Qt version, but that's just a guess. I use LMMS on Mac and it scales just fine with the Retina display, and I'm the one that authored the registry hack for Windows to run full size (albeit blurred). I also helped test the environment variables. I agree, if it's not usable it's hard to know if it's worth working on, but I can promise you, you'll make a lot of people happy if you help improve this. 🍻

[dwbullok]

I don't mind putting in a bit of work to fix it, but I don't understand why this is such a long standing problem. A user can set font size preferences for all Qt apps. It's just a matter of those preferences being used by the application. As far as I understand, the Qt HiDPI features are only useful for apps that were written with fixed-pixel dimensions. Is that how LMMS is written? I'm not trying to throw shade on any devs here, btw. I'm Just trying to get a rough idea of the source of the problem before I start wading through code.

[allejok96]

Hard-coded pixel values and lot of tiny pixmaps.... yeah

[fabiensc0ville]

This thread implies the scaling issue has been solved on MacOS.

But how can I control it? The interface is too small on Retina and I'd like to give some scaling factor.

[tresf]

This thread implies the scaling issue has been solved on MacOS.

But how can I control it? The interface is too small on Retina and I'd like to give some scaling factor.

I've been using LMMS on Retina for years and it's sized fine.

In regards to scaling, that would be a separate issue, the software doesn't have a scaling feature yet.

[fabiensc0ville]

Thank you for your feedback @tresf !

Isn't there a hack I can use either, such as some command in the terminal to adjust the size?

[tresf]

@fabiensc0ville I don't know... I guess you could try to disable the high-resolution support:

  <key>NSHighResolutionCapable</key>
- <string>True</string>
+ <string>False</string>

This is located in /Applications/LMMS.app/Contents/Info.plist. However, in my experience, this just makes the UI the same size but very blurry.

Are you having this issue with the macbook screen or an external display? I use an M1 and the text and buttons are normal sized.

NSHighResolutionCapable: False

NSHighResolutionCapable: True

[fabiensc0ville]

Thank you @tresf, it looks blurry indeed but I'll try it!

The topic of displaying a "normal sized" content is a subjective one. Who defines what is normal? 🙂

Did we do some user testing to have quantitative data for defining the norm? Are we following a guideline backed-up by research to conclude on the norm? If yes, what was the user segment used for this research?

I am using the screen of my 16-inch MBP and some items are illegible to my 30yo eyesight.

In the screenshot you shared, you can see LMMS's font is smaller than the default MacOS font in the taskbar (which is a good base to define a normal font). We can make a case it is still ok for a label to be smaller.

The problem arises when you open a plug-in. In that case, the font becomes ridiculously small and is way under any typographic guideline defining the norm (Material design, Human design, etc.). Buttons are even harder to read, let alone clicking on them:

This is not a rant, just some knowledge sharing about UX, to improve an already great software 😎

[tresf]

Apple's human interface guidelines are a good starting point, but drastically off topic for this thread.

If this is something you're passionate about, get involved (please!). This is a volunteer lead project.

[fabiensc0ville]

I don't see how offering references to define how scalable the software could be is off-topic?

I would gladly be involved though. How could I contribute to defining a legible interface, other than commenting here?

[tresf]

I don't see how offering references to define how scalable the software could be is off-topic?

This thread is about issues specific to high-dpi displays.

I would gladly be involved though. How could I contribute to defining a legible interface, other than commenting here?

For starters, starting a new issue, but jumping on #devtalk on Discord to actually offer some code changes would be stellar.

[fabiensc0ville]

This thread is about issues specific to high-dpi displays.

I believe the tiny size of the elements is linked to the high-dpi display scaling. On my old computer, elements wouldn't appear so tiny.

I am not a developer, but I can have a look at Discord to see if I can help in some ways

[tresf]

I believe the tiny size of the elements is linked to the high-dpi display scaling. On my old computer, eleme

If the plugin font size is drastically smaller on Hi-DPI displays, it would be on-topic however the comparison to the default MacOS font would be a separate conversation. Furthermore, the team is mostly aware of the UI/UX issues. You may look up the "Single Window Interface" thread for some constructive feedback on this.

What the team needs is people willing to hack at the code a bit, developer or not. That's what makes volunteer lead projects succeed.

[fabiensc0ville]

Great! Thanks for sharing me this context @tresf

[michaelgregorius]

I have added pull request #6607 as a small step towards get rid of the minuscule texts in LMMS.

[michaelgregorius]

Pull request #6779 solves the scaling issues of the setup dialog that was mentioned in this comment.

How does it compare to the existing dialogs?

Here's a comparison between the new implementation and the old one.

The "Autosave" and "Buffer size" tabs have been slightly redesigned so that the revert/reset button is next to the slider. See the images above.

The audio driver settings dialogs and the MIDI settings dialog now use a QFormLayout to layout their labels and input widgets. Doing so gives a much tidier look than the current implementation with hard-coded sizes and positions.

Video

Here's a video that shows the dialog in action:

• The look of the new audio and MIDI settings dialogs
• The feel of the redesigned revert/reset button
• Resizing

https://github.com/LMMS/lmms/assets/9293269/a6da9cc0-30ad-4d11-a17e-670797eb97d4

[musikBear]

That looks better, and also more professional Its a good job done well. 👍

[michaelgregorius]

Thanks for the kind words @musikBear! The old dialog might have had a bit more "character", e.g. due to the LED check boxes, but I think the new version looks much tidier. And more importantly, it's much more user friendly because it also works on HiDPI displays.

The idea is to reintroduce the "character" later if wanted. However, it should be done with potentially new widgets that, unlike the old ones, know how to scale.

[michaelgregorius]

Pull request #6787 fixes the HiDPI issues for menus by using the general font size that users have set for their applications.

This adjusts the main menu, the track settings menu and the combo box menus.

Demo

https://github.com/LMMS/lmms/assets/9293269/c43debd4-09d2-420d-b9e9-37988898864b

[michaelgregorius]

Pull request #6788 fixes one of the HiDPI issues of the sample track window by removing the hard coded font size of the name line edit.

[michaelgregorius]

Pull request #6789 fixes the HiDPI problems for elements that are based on QTreeView by removing the fixed point based font size from the style sheet. This affects:

• The file browser
• The headings of the plugin browser
• The patch selection dialogs for GigPlayer and SoundFont player

It also makes the text size of the check boxes for user content and factory content based on a point size instead of a pixel size.

Preview

File browser:

Patch selections:

[fabiensc0ville]

Great to see the progress you guys have made on the topic!

Keep up the good updates 👏

[michaelgregorius]

Quick update: the fix for the problem with the font size of the menus (see here) has been merged via pull request #6787.

[michaelgregorius]

The fix for the HiDPI issue of the sample track window (see here) has also been merged (via #6788).

[michaelgregorius]

The fixes for the elements mentioned in this comment are now also merged via #6789.

So the setup dialog changes shown here are the last of the batch. But it looks like they need some more adjustments.

[he29-net]

Did something change in the way we build AppImage between versions 1.2.2 and the current nightly builds? I wanted to check out the latest fixes, since the fix in Sample Track seems to introduce two very different font sizes into the same window, which doesn't look that great. So I wanted to test it on my system, and I found that the nightly AppImage does not scale at all for me:

lmms-1.2.2-linux-x86_64.AppImage:

lmms-1.3.0-alpha.1.386+g910cdf22c-linux-x86_64.AppImage:

Using banana for scale, you can see that the 1.2.2 fonts are uniform in size and properly scaled for a 4K screen (maybe a bit larger than needed if anything). Not only that, but if I drag LMMS to a lower resolution laptop screen, it detects the difference in density and scales down. So 1.2.2 works perfectly (at least for a scaling method limited to integer multiples).

With the 1.3 nightly, no scaling is applied except for the OK / Cancel button labels and the main menu, and nothing changes when I drag the window to a different screen. The buttons in Song-Editor are aware that the devicePixelRatio() isn't one, because they adjust their size to accommodate the upscaled icons. So Qt clearly "knows" it is running on a high DPI screen. But the icons (and everything else for that matter) stay 1:1 anyway -- the "scale all non-natively-scalable elements by 2x" behavior found in 1.2.2 is not present. So it seems like a regression caused by a different Qt version (different default settings or method of detecting system configuration?), or some change in environment variables set up by us in the AppImage?

Playing around some more, I realized this probably matches the appearance common in screens from @michaelgregorius (most of GUI not scaled, and non-fixed-size fonts being notably larger than everything else) that I never managed to replicate on my system until now. I can finally experience the issue you have been dealing with the whole time. :)

When I build locally from the source, LMMS always behaves like the 1.2.2 version (apart from the automatic scaling when dragging to a low-res screen, that does not work). And I have no idea how to build or debug an AppImage, so I'm not sure where and how exactly should I look for the root cause of this difference. Environment variables exported before running the AppImage do seem to have some effect, but so far I had no luck replicating the 1.2.2 behavior (which seems much more "release-ready" compared to current nightlies).

[michaelgregorius]

Playing around some more, I realized this probably matches the appearance common in screens from @michaelgregorius (most of GUI not scaled, and non-fixed-size fonts being notably larger than everything else) that I never managed to replicate on my system until now. I can finally experience the issue you have been dealing with the whole time. :)

If anyone is interested why my desktop looked as described here's a coarse description of the setup at the time:

• I use SDDM as my login manager and it was configured to start the Plasma session with some extra argument that specified the DPI:

  ServerArguments=-nolisten tcp -dpi 120

• Plasma was configured to have a scaling of 100% (I don't even know if it supported fractional scaling at the time).

It seems that with this configuration images were not scaled at all (due to the 100% setting) but text was still scaled according to the DPI value. Therefore all images/pixmaps looked small compared to text.

Only recently I had to reinstall my system and now I am not using the DPI arguments anymore. Instead I use the fractional scaling that's provided by Plasma. It is set to 125% and now I can also enjoy images/pixmaps that are scaled in ugly ways as well as flickering sub window borders when they are being moved. See here for an example:

Note for example the missing light gray border on the left side of the window. It appears and vanishes when the window is being moved, hence the flickering. Almost all elements look ugly now: knobs, LED numbers, gear icons, button images. The button on the top right flickers when I move the right window border.

In general it seems that HiDPI is still a mess under Xorg/Wayland/Qt. I mean, why did I even have to specify the DPI explicitly in the first place? Shouldn't Xorg know best how to find out the DPI and provide that information to Qt?

When I build locally from the source, LMMS always behaves like the 1.2.2 version (apart from the automatic scaling when dragging to a low-res screen, that does not work). And I have no idea how to build or debug an AppImage, so I'm not sure where and how exactly should I look for the root cause of this difference. Environment variables exported before running the AppImage do seem to have some effect, but so far I had no luck replicating the 1.2.2 behavior (which seems much more "release-ready" compared to current nightlies).

I wonder if AppImage builds can include environment variables and if both build are configured with different ones which then steer Qt in different directions. Perhaps the new builds have been configured to work around fractional scaling due to the issues shown above.

However, I don't know much about AppImages and unfortunately I wasn't able to find out where their builds live.

[michaelgregorius]

@he29-net, can you please show how the elements that have been fixed so far look in the 1.3 AppImage on your 4K screen? This would for example be:

• The file browser, e.g. the "My presets" tab
• Menus of combo boxes, e.g. the combo box that shows "1 bar" in the Song Editor
• The track settings menu
• The sample track window

[he29-net]

@michaelgregorius Sure. I had to do the screenshots on the smaller screen (because imagemagick cannot grab the screen when a menu is open, and Kazam refuses to store anything on the main screen for some reason), but the proportions are the same (i.e. the big text is properly sized, everything else too small). System is Debian 12.1 + Xfce 4.18 with DPI set to 155.

The mixed scaling also happens in the Spectrum analyzer, as you reported in #5088, just with even larger difference in font sizes. The Add effect dialog is also a bit wonky: all the fonts are scaled up, but the window itself has a default size that does not scale with DPI, so it looks really tiny. I think that is a common problem with many similar windows as well (same goes for the side panel, which is too narrow by default and cuts off the check box labels).

As for the fractional scaling, yeah, that looks pretty terrible. Maybe if we only allowed 1x / 1.5x / 2x, it would be more acceptable, but the only good solution is probably to draw everything from vectors, and that's going to take quite a bit of effort. Meanwhile, there are other small bugs even with the "2x fallback scaling" done by the 1.2.2 version, like the borders of combo boxes (2x scale vs. 1x scale for comparison):

Taking care of all things like that seems like a major GUI rework, so I think for 1.3.0 it would be better to just focus on making the scaling at least "acceptable" and "consistent". And either aim the "proper scaling" for 1.4.x, or 2.0 (along with single-window mode, since that's also a complete GUI rework, so might as well do everything at once).

[michaelgregorius]

Thanks @he29-net!

This looks as expected then. All the remaining small elements are likely caused by:

• Code that sets the font size in pixels, e.g. via the pointSize template. Example:

  p.setFont( pointSize<8>( p.font() ) );

• Style sheet entries that use pixel sizes
• Code that hard codes widget sizes

The way forward

I think the way forward is:

• Remove all calls to the pointSize template.
• Switch all widgets that use fixed layouts, e.g. that move their children to fixed positions, and that assume fixed sizes. Make them use layouts so that they can flexibly adjust to different text sizes.
• If widgets do not want to use the default system font size they should define their size in points and ideally via a style sheet (I think this might also apply to the Spectrum Analyzer that was mentioned).

Places where pointSize is used

Currently the pointSize template can be found in the following files. I guess it is best to start with everything that's not under plugins:

• /plugins/AudioFileProcessor/AudioFileProcessor.cpp
• /plugins/CarlaBase/Carla.cpp
• /plugins/DualFilter/DualFilterControlDialog.cpp
• /plugins/LadspaBrowser/LadspaBrowser.cpp
• /plugins/Monstro/Monstro.cpp
• /plugins/Patman/Patman.cpp
• /plugins/Stk/Mallets/Mallets.cpp
• /plugins/Vestige/Vestige.cpp
• /plugins/VstEffect/VstEffectControlDialog.cpp
• /plugins/ZynAddSubFx/ZynAddSubFx.cpp
• /src/core/audio/AudioJack.cpp
• /src/core/audio/AudioOss.cpp
• /src/core/audio/AudioPortAudio.cpp
• /src/core/audio/AudioPulseAudio.cpp
• /src/core/audio/AudioSdl.cpp
• /src/core/audio/AudioSndio.cpp
• /src/core/audio/AudioSoundIo.cpp
• /src/gui/clips/SampleClipView.cpp
• /src/gui/editors/AutomationEditor.cpp
• /src/gui/editors/PianoRoll.cpp
• /src/gui/instrument/EnvelopeAndLfoView.cpp
• /src/gui/instrument/InstrumentFunctionViews.cpp
• /src/gui/instrument/InstrumentMidiIOView.cpp
• /src/gui/instrument/InstrumentMiscView.cpp
• /src/gui/instrument/InstrumentSoundShapingView.cpp
• /src/gui/instrument/InstrumentTrackWindow.cpp
• /src/gui/instrument/PianoView.cpp
• /src/gui/menus/MidiPortMenu.cpp
• /src/gui/modals/SetupDialog.cpp (#6779)
• /src/gui/tracks/TrackOperationsWidget.cpp
• /src/gui/widgets/ComboBox.cpp
• /src/gui/widgets/GroupBox.cpp
• /src/gui/widgets/LedCheckBox.cpp
• /src/gui/widgets/MeterDialog.cpp
• /src/gui/widgets/Oscilloscope.cpp
• /src/gui/widgets/TabBar.cpp
• /src/gui/widgets/TabWidget.cpp
• /src/gui/AudioAlsaSetupWidget.cpp
• /src/gui/Lv2ViewBase.cpp
• /src/gui/MidiSetupWidget.cpp
• /src/gui/SampleTrackWindow.cpp

Effort

As you have already noted this will be a ton of work. This first set of fixes were mostly low hanging fruits, except for the setup dialog. The goal was to make the application at least a bit more usable on HiDPI screens.

Example for the introduction of layouts

Some while ago I have started hacking on the effects boxes so that they also work with layouts. Their name labels use a larger font now and they elide the name if it is too long. Ideally they should be horizontally resizable. They currently look as follows in my branch:

"Add effect" dialog and side panel

One option might be to resize the "Add effect" dialog according to the screen size when it is opened. The dialog is resizable, so it might also be a good idea to store its last size when it's closed so that it later opens at that size again.

The same applies to the side panel. It it likely initialized with a pixel size instead of for example a percentage of the available width. On my screen I can fully read the check boxes but because you have a higher DPI screen (155 DPI vs. 117 DPI) the fonts are made bigger relative to the fixed pixel width and hence they are cut off on your screen.

[tresf]

Did something change in the way we build AppImage between versions 1.2.2 and the current nightly builds?

Not a whole lot, although in my experience, the Qt version we bundle can drastically influence the behavior, so it may be worthwhile to baseline compare the Qt versions.

And I have no idea how to build or debug an AppImage, so I'm not sure where and how exactly should I look for the root cause of this difference.

@PhysSong offered some debugging steps here: https://github.com/LMMS/lmms/issues/4286#issuecomment-379518594, the relevant parts are:

1. Go to the directory which contains the AppImage
2. Run ./lmms-1.2.0-rc5.43-linux-x86_64.AppImage --appimage-extract
3. Run squashfs-root/usr/bin/lmms

Since lmms is a wrapper to call lmms.real, there may be other environmental factors to consider and they should be present in the script. If you'd like to instead call lmms.real directly, PhysSong has the steps for providing this environment in his original steps although I'd recommend removing the calls to gdb unless that's desired.

There's also a small chance that the linuxdeployqt tool has changed the behavior since 1.2.2 release. That would be a deeper dive, since it's responsible for finding and bundling all of the dependant libraries.

[michaelgregorius]

The fix for the scaling issues of the setup dialog (see here) has been merged via pull request #6779.

This might be of interest for @Glitchy-Tozier who has mentioned the problem.

[Rossmaxx]

I have opened #7159 which might fix the text scaling issues but i don't really have time to confirm it. Would appreciate if someone gives a heads up.

[michaelgregorius]

Does anybody know if all of the targeted system (Linux, Windows and MacOS) have a notion of global (fractional) scaling? If they do, does the scaling apply to all of the following elements in a Qt application?

• Raster images
• Text that's defined in pixels
• Text that's defined in points

Windows has support for fractional scaling and Linux also seems to be gaining support for it, e.g. via Wayland. Does MacOS also support this?

If all system supported global fractional scaling (for all of the elements listed above) then the solution might be to follow these rules:

• Widgets that use font sizes in points must be able to accommodate for text with different pixel heights. They must not use hard coded widths, heights and widget placements. They should use layouts instead of hard coded placements.
• Widgets that set their font sizes in pixels can use hard coded widths, heights and widget placements because they will scale with global scaling and will be discernible.

With global scaling the way forward to fix the problems with HiDPI would be to either use flexible, scalable widgets that can take different font sizes as preferred by the user or use hard coded widgets with text sizes set in pixels.

More details can be found in #7178. There's also a screenshot which shows problematic elements in the GUI that need work. The quickest fix for some of these elements might be to use QFont::setPixelSize. But this would only be a solution if global scaling scales text in pixel sizes on all targeted systems.

[michaelgregorius]

Pull request #7185 should fix most scaling issues for users that use global fractional scaling. It for example fixes #7178 and does so in a consistent way.

There is still room for improvement though as it might still be desirable to have a flexible GUI that can scale, e.g. for users that cannot use global fractional scaling. If wanted the items that are described below can also be turned into potential tasks of a new project.

Areas for potential improvements

I have identified the following areas that could be worked on. The gist of it is that the individual plugin GUIs likely cannot be changed if they are not reimplemented completely. Several other areas outside of the plugins could be adjusted though.

Mixer channel view

The name of the mixer channels is still presented using a pixel sized font. It should be attempted to switch it to a fully dynamic layout, so that it can also be defined using a point sized font.

Automation editor

The automation editor uses a pixel sized font to display the min and max values on the left size of the editor. Might be switched to a point based size.

Piano roll

The piano roll uses a pixel sized font to display "Note Velocity" and "Note Panning" on the lower left side of the dialog. Might be switched to a point based size if everything around this area can scale accordingly.

Instrument dialog:

This is the dialog that displays the different instruments. It shows the following information:

• Characteristic GUI of the instrument
• Volume/cutoff/resonance envelopes
• LFOs
• Note stacking
• Arpeggios
• The effects chain of the instrument
• MIDI input/output
• Tuning options.

It should be attempted to reimplement the instrument dialog using layouts so that only the actual instrument GUI is displayed at it's fixed size. Everything else around it should be resizable and implemented using layouts. This is a rather big undertaking though but could also make the instrument window much more attractive as it could use more real estate to display the different aspects, e.g. envelopes and LFOs.

Effect view

It should be attempted to switch the effect view to a dynamically layouted implementation so that the view that shows the effects can be resized as well. Some time ago I have attempted to do so (see screenshots at the bottom here) but have not continued yet. This will also involve the effect chain list though. Therefore it has a dependency to the changes made to the instrument dialog because this dialog also shows an effect chain and ideally it should also be resizable.

Widgets

There are several custom widgets that use hard coded sizes and rendering. Due to this they cannot be used sensibly in layouts, i.e. they do not scale. For each of these widget there should be an alternative version that can use points size fonts and that can scale accordingly. In some cases it might be enough to inherit from an existing Qt widget, extend it with the additional functionality and to style it via a style sheet. The widgets are (each under src/gui/widgets/):

• ComboBox
• GroupBox
• Knob
• LcdFloatSpinBox
• LcdWidget
• LedCheckBox
• Oscilloscope
• TabBar
• TabWidget

If possible the old non-scalable widgets should be removed so that they do not get used in the future. Widgets that are used in the context of the plugins with fixed sizes cannot be removed though. It should be attempted to isolate the classes to only the plugins and make sure that they are not used outside of this context.

Plugins

The plugins can be found under plugins in the source tree. In this area nothing should be changed to use point sizes because the actual GUIs of most plugins use pixmap backgrounds and therefore assume absolute positioning, sizes, etc.

[tresf]

Does MacOS also support [fractional scaling]?

Not officially, no. AFAIK, all displays that they ship use integer scaling, so this would be more common with Hackintosh laptops or perhaps some oddball external displays.

[michaelgregorius]

Does MacOS also support [fractional scaling]?

Not officially, no. AFAIK, all displays that they ship use integer scaling, so this would be more common with Hackintosh laptops or perhaps some oddball external displays.

Thanks for the info @tresf!

So the idea is that Apple sells displays that are close to multiples of 96 DPI so that users can scale with an integer factor? And people who use other hardware must live with the consequence of everything being either a tad too small or too large?

[michaelgregorius]

I have a branch where the instrument window currently has the following layout:

The idea is that the individual instrument design is always visible and that the other options which shared by all instruments are shown right next to it. This design makes more use of screen real estate and less clicks are needed to sculpt a desired sound.

The next step would be to make the tabs appear less crammed by using layouts where they are not already used so that the dialog all in all becomes more scalable. The other layouts would likely be redesigned to give more breathing space.

Is it feasible to continue in this direction?

[tresf]

So the idea is that Apple sells displays that are close to multiples of 96 DPI so that users can scale with an integer factor? And people who use other hardware must live with the consequence of everything being either a tad too small or too large?

Correct. They do offer accessibility setting to increase font sizes, but as is the norm with Apple, anything outside of the hardware that they ship requires unofficial 3rd-party software.

Oddly, I've never had scaling issues with Qt apps on Mac (LMMS included), so this strategy has been effective in my opinion.

[Rossmaxx]

I remember @LostRobotMusic ranting about how every instrument has the same envelope setting. Michael's unification approach (two messages above this one) looks helpful. Perhaps it would even make sense to remove the seperate envelope tab and Integrate it per instrument but that's a rather huge change.

[musikBear]

seperate envelope tab

Envelopes should not be like this I made simpleton changes to the values so the envelopes was sc Negated, witch only means that the output is piano-like, and afair it was Oscar who added these changes to Master. He did it as a favour because i could not for the sake of sanity make commits from virtual-box. In Master, Its should be like this:

[LostRobotMusic]

I remember @LostRobotMusic ranting about how every instrument has the same envelope setting. Michael's unification approach (two messages above this one) looks helpful. Perhaps it would even make sense to remove the seperate envelope tab and Integrate it per instrument but that's a rather huge change.

No, I said absolutely nothing of the sort. What I have been ranting about is that LMMS's envelopes are strictly linear which sounds extremely awful, the time it takes to drop from 0 to -6 dBFS is the same amount of time as it takes to drop from -6 to -infinity dBFS. This is one of the main contributing factors behind people making the claim that LMMS simply "sounds worse" than other programs. I never once expressed any opinions against LMMS's instruments coming with an envelope supplied by the DAW itself.

[tresf]

Perhaps it would even make sense to remove the seperate envelope tab and Integrate it per instrument but that's a rather huge change.

Slightly off-topic.... I've mixed feelings about the overall layout, but "front-and-center envelope" I think is a win-win (both for newcomers and seasoned users).

[michaelgregorius]

Perhaps it would even make sense to remove the seperate envelope tab and Integrate it per instrument but that's a rather huge change.

Slightly off-topic.... I've mixed feelings about the overall layout, but "front-and-center envelope" I think is a win-win (both for newcomers and seasoned users).

@tresf, are you referring to the current "old" layout or the new one? If it's the latter what gives you the mixed feelings?

In my opinion the current instrument screen is much too small and hides too much information. Compared to some VSTs that strive to have everything quickly accessible on one screen it takes much more clicking to get the same things done in LMMS' instrument dialog.

The design above also isn't meant as the ultimate implementation anyway. The idea would rather be to start moving into a better direction and get a more and more improved solution via incremental steps. In the end this might even result in a complete redesign which shows all envelopes at once and that redistributes the other elements.

Technical motivations for a redesigned instrument dialog

There's also a technical motivation to change things. The current implementation of the instrument dialog uses LMMS' own TabWidget and that widget does not play nice with widgets that use layouts to organize their children. However, using layouts can help with getting a scalable GUI that works with different screen sizes and pixel densities. So the usage of that widget somewhat stands in the way of that.

IMO one goal should be to get rid of LMMS' own non-scalable widget implementations and to replace them with styled Qt widget wherever possible. This was for example done in the screenshot above with regards to the tabs. They are using a styled QTabWidget and as you can see with that tab widget the widgets are using the space they need which is not the case with TabWidget.

[tresf]

what gives you the mixed feelings [on the new layout]?

It's just aesthetically worse. Much more dead space in the interface, controls stretched to places they don't belong, LMMS-themed controls next to plugin-themed controls. I understand that it's no small task to rearrange the plugin controls for the future, but this side-by-side looks more like a deconstructed sandwich because it's obvious that it's an explosion of its parts.

A bit extreme (and in my opinion, over simplified) is @budislav's mockup. See "instruments and effects" section here: https://www.behance.net/gallery/194917259/LMMS-Redesign-Concept. (~~I don't believe he shows the envelope in any of his mockups~~ Edit: He does show it in the first mockup, but I believe it's missing from the mockups that follow -- which is why I believe "front-and-center envelope" would be a mutual improvement to both designs).

Many will argue that this will take the branding out of our plugins (this statement would be true). There may be a way to marry the ideas, but I find the existing "background plugin artwork" as a base for the panel-size to be a regression. I can't argue its utility, but I do not think the tradeoff is worthwhile. I hope that is clear and that this is not intended -- in any way -- as a way to minimize the effort involved. The community is always indebted to those that care enough to fix and improve things. ❤️

[tresf]

IMO one goal should be to get rid of LMMS' own non-scalable widget

Yes, I believe this summarizes it best on a technical level.

[michaelgregorius]

Thanks for you input, @tresf! I appreciate it!

Let me first emphasize that the design above is not meant to be final. It is meant as a proposal for a direction to solve the problems of the users (and also of some of the code). With that in mind I'd like to address some of your remarks:

Much more dead space in the interface, controls stretched to places they don't belong

At least technically the dead space could be removed by moving the controls at the top (Vol, Pan, ..., Save) to above the plugin window. Although that might not make sense logically.

LMMS-themed controls next to plugin-themed controls.

That's the current nature of the thing, also with regards to how it is implemented. The only thing the plugin provides with regards to the GUI is the individual plugin window. Everything on the right is implemented in the underlying instrument base classes and therefore it also looks the same for every plugin (but also different from most plugins).

I understand that it's no small task to rearrange the plugin controls for the future, but this side-by-side looks more like a deconstructed sandwich because it's obvious that it's an explosion of its parts.

No, it is definitively not a small task and that's the exact reason why I am advocating for small steps into the right direction even if none of the steps may be "perfect" and might have its "warts". The important thing would be that each of the step improves upon the previous steps.

A bit extreme (and in my opinion, over simplified) is @budislav's mockup. [...]

Many will argue that this will take the branding out of our plugins (this statement would be true). There may be a way to marry the ideas, but I find the existing "background plugin artwork" as a base for the panel-size to be a regression. I can't argue its utility, but I do not think the tradeoff is worthwhile.

I agree that the fixed plugin artwork/GUI size is a hindrance. It pains me to see that new plugins like SlicerT have to be crammed into that small space, limiting the functionality they can provide.

Some proposals to marry both ideas would be:

• enable the plugins to have arbitrary sizes, i.e. to redesign the instrument dialog in such a way that it can accommodate arbitrary sizes plugin windows
• allow plugins to have their own design elements so that they do not lose all individuality
• require plugins to be designed in such a way that they can potentially scale
• provide a consistent widget set of controls that are shared by the plugins

Finally, I think what's most important is that some sort of direction is given, e.g. in the form of a project that describes the goal, the strategy and its intended steps. Because no one wants to go through all these steps without being sure that all the work will not be done in vain.

I hope that is clear and that this is not intended -- in any way -- as a way to minimize the effort involved. The community is always indebted to those that care enough to fix and improve things. ❤️

Yes, it is. :slightly_smiling_face:

[michaelgregorius]

The envelope and LFO graph are now both scalable. So the design proposed here https://github.com/LMMS/lmms/issues/3067#issuecomment-252446911 would be possible now.