search

LMMS / lmms

Cross-platform music production software
https://lmms.io
GNU General Public License v2.0
8.18k stars 1.01k forks source link

Better Interface: Infinite zoomable and panable Workspace #6266

Open BrahRah opened 2 years ago

BrahRah commented 2 years ago

I've made a better concept: https://github.com/LMMS/lmms/issues/6272

Enhancement Summary

I've posted this already in the discord lmms channel where it was so good the whole conversation got deleted : Make the workspace into an unlimited canvas like blenders node workspace. It resizes already so just make it bigger, add in panning and zooming. Then add screen regions where one can choose to add different components, either another canvas, tool or sidebar. Those regions would allow the use of multiple monitors! A small monitor could be for fixed elements and a big 4k monitor could be split up in multiple canvas workspaces. It would also allow moving the different workspace elements to other sides of the screen for a better individual workflow.

Justification

Lmms reminds me of blender 2.7 very powerful but hard to use. It is rigid, slow to work with and the workspace is messy. That simple change would declutter lmms and make faster and easier to use. It would also place lmms on the track to industry standard like blender.

Mockup

-Red lines are the regions. mockup

New concept after discussing it:

Monospace-V commented 2 years ago

Might I suggest changing the title to something more specific like "Infinite interface"? That being said, if this is implemented, we're going to definitely need a panel that shows the entire thing and the location of each window, possibly with the ability to move those windows around on that panel. Kinda like Carla's patchbay viewer panel. And defined size limits.

BrahRah commented 2 years ago

I don't know how Carla's patchbay viewer panel works but you can just zoom out to see everything. Here is how blenders node editor works: https://www.youtube.com/watch?v=5GjHpFYU-cU

Spekular commented 2 years ago

Most all of our editors would quickly become unusable when zoomed out, and unnecessarily large when zooming in. They have no inputs or outputs to connect either, so I really don't see any benefit to the infinite-canvas approach (which we in fact already have, just with no zoom).

Copping Blender's split/merge/resizeable UI concept is something I agree with, but there are several other issues thqt could be edited to include that (#1911, #3152, #5078)

BrahRah commented 2 years ago

"Most all of our editors would quickly become unusable when zoomed out, and unnecessarily large when zooming in." That makes no sense. You keep the zoom that you can work with, there is no zoomed out too much or zoomed in too much. Zoomed out too much would be the overview and zoomed in too much a maximized window. If a user wants to zoom in on one button why not it's their choice but most will keep the zoom to what they can work with. Contrary to that atm depending on the monitor the windows are either too large or too small in lmms. When too large they take up space unnecessarily and when too small the windows are hard to use. The zoom would allow users to adjust the size quickly to their monitor. The windows also stack and need to be moved around and opened and closed all the time which makes it messy and slow to use.

With that infinite space one could have all windows open have an overview when zoomed out, select a window and then press a focus or maximize button to work with that specific window. Or just pan around to get to the different windows, the panning is esp. good with large 4 or 8k monitors that have a lot of desktop space.

Alternatively a slim list of windows like the song editor could be used that is outside the workspace to focus on the different windows. If the windows then are placed adjacent instead of on top of each other. One could use the mouse wheel to scroll through the list (active list element would be focused on) or click on a name to focus or pan with middle mouse button. That would not fix the window size issue but would make the lmms workspace already much more usable.

Spekular commented 2 years ago

That makes no sense. You keep the zoom that you can work with, there is no zoomed out too much or zoomed in too much. Zoomed out too much would be the overview and zoomed in too much a maximized window.

Your mockup appears to show the entire editor being scaled. If you want to zoom the contents of the editor, this is already available everywhere where it makes sense (automation editor, song editor, piano roll). If your complaint is that fixed UI elements like toolbars are the wrong size then this should be solved by fixing our resolution scaling, not by making users zoom in and out.

The zoom would allow users to adjust the size quickly to their monitor.

Which should be done via LMMS properly handling the OS's scale factor, and if finer adjustments are necessary via settings. Scale factor should be set-and-forget, if someone needs change it often enough to justify a dedicated zoom control then something is terribly wrong and that should be fixed at the source.

The windows also stack and need to be moved around and opened and closed all the time which makes it messy and slow to use.

Your proposal doesn't seem to mitigate this, considering it features multiple movable windows. The single-window interface does and would work very well in tandem with blender-esque resizeable views.

With that infinite space one could have all windows open have an overview when zoomed out, select a window and then press a focus or maximize button to work with that specific window.

I'm not sure how this is more convenient than selecting windows from a dropdown or toolbar, and I've never seen it implemented in any software.

Or just pan around to get to the different windows, the panning is esp. good with large 4 or 8k monitors that have a lot of desktop space.

Again, not sure why navigating in space would be better than navigating via menus.

What problem does this interface design solve that wouldn't be solved by the single-window proposal with proper DPI scaling? If we're going to use a brand new design it needs a compelling benefit over existing tried-and-tested proposals.

BrahRah commented 2 years ago

  1. it does not work for vsts

  2. the time fixing that could be invested in a zoom that is much more versatile instead which would also fix the vst size differences 2b. a lot of vsts have differently sized knobs, buttons etc. which will not be fixed by lmms scale factor. A zoom on the other hand will.

  3. I'm not sure what you mean. What single-window interface? The views are pointless if there is no canvas attached.

  4. dropdown and toolbar? The workspace windows in lmms are not even in a dropdown or toolbar they only exist in the workspace uncollapsed and song editor collapsed.

  5. do you want to replace lmms song editor with a menu?

  6. See 1,2,2b

    • Also why remove the current workspace and make it a single window like every other daw? It's already there why not improve and extend it?
    • You won't have the zoomed out overview.
    • A menu/toolbar is only fast when there are very little elements in there once one has to scroll it becomes much slower then Zooming and Panning a canvas.
    • Menus and toolbars can also compliment the infinite workspace. If you maximize a workspace window and just switch out the track/plugin window via clicking inside a toolbar-list you would have that single window workflow and the workspace in the bg just like it is right now.
    • It would also add the groundwork of adding node based workflow if that is ever wanted in the future.
    • Why would you remove having multiple windows in the workspace just to have one window? That makes owning big monitors useless. Even if you add blender like regions/views those are not as flexible as a workspace.
    • If you arrange your windows on the workspace like it is rn you can fit in a lot more on the screen.
    • When you have midi controllers attached and everything important mapped it's better to have a canvas with some of what you need to use then having to move from one window to another just to change some things.

It's a flexible workflow vs a rigid one.

allejok96 commented 2 years ago

@BrahRah I don't think you realize the immense amount of work that this would require to implement. The dynamic zoom is not supported by our current UI framework, and we'd basically need to rewrite everything from scratch.

There are already many ideas of a total redesign of LMMS' inteface. One quite popular suggestion is single window mode. But it's still a long way to go. Your design reminds me of gnome shell. It's not a bad idea. Just a momentous task.

In the end of the day the issue here seems to be about high DPI scaling. Adding a setting for that should be fairly simple, and it wouldn't require a complete remake.

BrahRah commented 2 years ago

That is why I suggested to leave the zoom out first but add the panning. Together with the DPI scaling that should already improve lmms. Single window is just maximized workspace windows. For that a user just needs a list that is outside the workspace. That is quickly implemented and the current workspace doesn't even need to be removed to add that.

My suggestion would be to make the current ui more efficient to get more users to use lmms. That will also increase potential developers and funds.

Spekular commented 2 years ago
  1. it does not work for vsts
  2. the time fixing that could be invested in a zoom that is much more versatile instead which would also fix the vst size differences 2b. a lot of vsts have differently sized knobs, buttons etc. which will not be fixed by lmms scale factor. A zoom on the other hand will.

VSTs won't be affected regardless, they handle their own drawing and the most stable way to use them ("no embedding") makes a completely separate window. Besides, if a zoom feature can be made to affect VSTs then so can a scale factor.

  1. I'm not sure what you mean. What single-window interface? The views are pointless if there is no canvas attached.

See the issues I linked. I'm not sure what you mean with "no canvas attached", obviously the piano roll would still contain a note grid and so on even if we switched to a non-windowed solution.

  1. dropdown and toolbar? The workspace windows in lmms are not even in a dropdown or toolbar they only exist in the workspace uncollapsed and song editor collapsed.

Neither your proposed UI nor the one I'm arguing for are currently implemented. I'm not sure why you think editors couldn't be added to a dropdown, but they could be arbitrarily zoomed. Also, we do in fact already have a toolbar that opens and closes editors image

  1. do you want to replace lmms song editor with a menu?

No, and I've never said so.

  • You won't have the zoomed out overview.

You could easily create a layout that gives you an overview of all the editors if you want. Loadable layouts and or editor fullscreen would make switching a non-issue, and I see no reason that at least one of these wouldn't be available in a single-window UI.

  • It would also add the groundwork of adding node based workflow if that is ever wanted in the future.

An infinitely scrollable area is not the hard part of a node based workflow, and making the editors zoomable would not necessarily provide good groundwork for zoomable nodes.

Why would you remove having multiple windows in the workspace just to have one window? That makes owning big monitors useless. Even if you add blender like regions/views those are not as flexible as a workspace. if you arrange your windows on the workspace like it is rn you can fit in a lot more on the screen.

A blender-esque UI can be arranged exactly the same as a multi-window one if we make two assumptions

  1. No editors overlap
  2. There are no gaps between editors

These are perfectly reasonable conditions. You yourself mentioned the stacking (overlap) of windows as a downside, and you're arguing that fitting a lot on the screen is a bonus (hence no gaps are ideal).

BrahRah commented 2 years ago
  1. Ohh ok that sucks, I assumed they could be resized/zoomed in with an infinite canvas like workspace. Well yea that makes the zoomable workspace much less attractive. I'd still keep the current infinite workspace tho there are ways to make it more usable.
  2. Yea I was a bit confused there so basically the single window layout would be like ableton live not like blender.
  3. I was talking more about tracks and plugins
  4. That is a good point. I agree there.
  5. It would add some of the groundwork tho.
  6. Ahh ok I think I get you now you mean having different tabs where everything is arranged differently like blenders different workspaces. Yea having that is really good. So one would add regions/views and position everything however one wants, then have different workspaces with different elements to work on.

But that would also work with an infinite workspace and panning.

You are right lets just leave the zoom out then but keep the infinite workspace.

Let me summarize with the changes:

I'm gonna add this to the main post.

Did I miss anything or is there something to add?

RoxasKH commented 2 years ago

Definitely not a bad idea, but I don't if LMMS is still following that direction, but if so, it wouldn't fit well with the new single window UI that was planned as it's a completely different approach in making the UI better.

https://github.com/LMMS/lmms/issues/1911

To b e fair there's no daw that still deals with floating windows (ok, FL Studio does, but has magnetic windows, and also people don't drag windows like hell in it i think) so i still think we should move over that.

That said i know a lot of the fanbase still likes the floating windows UI, so i guess the choice is up to the devs or such.

BrahRah commented 2 years ago

I'm against removing the canvas workspace lmms already has. Improve it instead I've given many suggestions on how that can be done.

1911 would make lmms just a live clone.

allejok96 commented 2 years ago

3532 combined with linux gives you dual monitor and workspaces

BaraMGB commented 2 years ago

The singe window approach is discussed for 7 years now. Which steps are done forward to this?

qnebra commented 2 years ago

A lot of discussions with ideas and few PR's splitting Core and UI in some lmms editors and functions.