Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LMMS redesign concept #1911

Open
budislav opened this issue Mar 31, 2015 · 236 comments
Open

LMMS redesign concept #1911

budislav opened this issue Mar 31, 2015 · 236 comments

Comments

@budislav
Copy link

budislav commented Mar 31, 2015

(Click to enlarge)
lmms_preview


Hi all,
My previous work for Zynaddsubfx has same purpose to dock all windows in one (link is dead)
http://budislavtvp.deviantart.com/art/ZynAddSubFX-UI-Concept-2014-455890191

It is in development phase > https://github.com/fundamental/zyn-ui-two

Link to full concept:
http://budislavtvp.deviantart.com/art/LMMS-UI-UX-Design-Concept-Single-Window-523696539
https://www.behance.net/gallery/38503021/LMMS-UIUX-Design-Concept-Single-Window-Interface
https://www.behance.net/gallery/194917259/LMMS-Redesign-Concept

Full version (mirror):
full version

@oeai
Copy link
Contributor

oeai commented Mar 31, 2015

Looks very good, you can add pics right here, maybe just not all for ui and zyn

@musikBear
Copy link

stunning!
..but i am feeling a chill, cause i have spent ...absurd time learning zyn's current UI sigh 🐹

@BaraMGB
Copy link
Contributor

BaraMGB commented Mar 31, 2015

For your (awesome!) LMMS-UI-Concept I fear this requires a complete rewrite of LMMS's GUI. How do you handle the windows? (switching in fullscreen per button? dragging the corners for sizing?)

Greetz Bara

@tresf
Copy link
Member

tresf commented Mar 31, 2015

For your (awesome!) LMMS-UI-Concept I fear this requires a complete rewrite of LMMS's GUI. How do you handle the windows? (switching in fullscreen per button? dragging the corners for sizing?)

I can't speak on behalf of the author, but most DAWs use a collapse/show method and the designated panes are just reused depending on which widget is shown.

you can add pics right here, maybe just not all for ui and zyn

Done. :)

@budislav,

Very interested to know the possibility of this. When you worked with the Zyn team, how involved with the code were you? Did you have to fork the repository? Did they merge the change into base? Last I checked, Zyn wasn't fully Qt compatible but your library seems to make heavy use of Qt and QML (right?)

Tagging @RebeccaDeField @pgiblock

Much overlap with:
#880 #1839

@tresf
Copy link
Member

tresf commented Mar 31, 2015

I am just UI/UX designer so I can't help with coding.

👍

everything you seen is work by Mark McCurry (fundamental)

Thanks for clarification. Yeah, Mark shows up here occasionally. I'm sure his efforts could probably be extended for LMMS as well.

As far as a singleton window, we likely have thousands of lines to clean-up to make this a possibility, but your mockup is delightful and we're likely to use it as a reference point when discussing major UI changes in the future, thank you! 👍

@tresf
Copy link
Member

tresf commented Mar 31, 2015

@fundamental what type of overhaul are we looking at here if we were to adopt this new UI? I assume we'd have to port over pretty much every single widget, but how extensible is this opengl/QML for other projects?

I'll quote the readme for others interested...

  • Custom nanovg (opengl 2.0) based rendering
  • Custom constraint based layout
  • QML based structure/event handling

Progress

As of so far a whole bunch of widget rendering code has been written.
A basic horizontal weighted/constrained pack layout has been created (in C)
and two simpler pack algorithms have been made in qml.
QML/nanovg integration has been establed and it appears to be relatively bug
free (though perhaps somewhat inefficient).
Some mouse handling has been done.
A variety of other widgets have received their design on paper.
To test some UI performance/integration a simple equalizer or envelop app might
be created.

@budislav
Copy link
Author

"your mockup is delightful and we're likely to use it as a reference point when discussing major UI changes in the future, thank you!"

I am glad to hear that, I hope this would be very helpful. I'm tired of floating windows :)

@tresf
Copy link
Member

tresf commented Mar 31, 2015

I'm tired of floating windows :)

Yes, many of us all are. Per #519, #765, #1406

And then there's #387, #1185, #1357, #520, #735, #1755, #1849, #1843

Just worked on a track last night and had to make use of the somewhat hidden Qt feature "Always on top" in the left corner of every sub-window. 👍

@budislav
Copy link
Author

"Just worked on a track last night and had to make use of the somewhat hidden Qt feature "Always on top" in the left corner of every sub-window."

That's what I'm talking about 👍
I will upload one mockup that shows how it looks on full HD res.

@tresf
Copy link
Member

tresf commented Mar 31, 2015

That's what I'm talking about 👍

@budislav P.S., you can use the > to quote a messsage. :)

@softrabbit
Copy link
Member

Let's say I have a dual screen setup. Now I can stretch my LMMS window to cover both screens and place the subwindows where I like. In which way would the proposed concept be an improvement in that case?

@budislav
Copy link
Author

@tresf

P.S., you can use the > to quote a messsage. :)

Thanks, didn't know that :)

@tresf
Copy link
Member

tresf commented Mar 31, 2015

Thanks, didn't know that :)

Sorry, it has to be the first character in order to work properly. 👍

dual screen setup

Yeah, I was wondering this as well.... If the other usability improvements happen that is certainly an obstacle I'd like to have. My recommendation (even in our current design) would be to have unlimited container windows. This could get ugly for singleton objects though (which we have some other open items on already).

@tresf
Copy link
Member

tresf commented Mar 31, 2015

@softrabbit looks like we're not the only DAW with this dilemma... Ableton, FLStudio, etc.

@budislav
Copy link
Author

@softrabbit
I've been thinking about dual monitor but there probably should be some options in preferences just for LMMS to know if you want to use second monitor. I need to think about this more.

@budislav
Copy link
Author

One solution will be to undock desired section and to move it on second monitor which have container than dock it automatically. Now there should be some kind of pattern for each section. Browser should be docked only to left or right, and instrument and effect rack should be always on bottom, because it have fixed height.

@unfa
Copy link
Contributor

unfa commented Mar 31, 2015

image

Seriously, I'm gonna put out some cash for implementing this.

@fundamental
Copy link
Contributor

On 03-31, Tres Finocchiaro wrote:

what type of overhaul are we looking at here if we were to adopt this new UI?
I assume we'd have to port over pretty much every single widget, but how
extensible is this opengl/QML for other projects?

At the moment the goal is to just get this to work for zyn, but I'd
imagine other projects could adapt the code.
The layout routines seem like they should have no problem working in
other qml projects (and IMO QML really should have such algorithms
bundled by default).

The draw routines should be easily swapped out, as most of them are
contained within draw.{c,h} (it has really driven me nuts how many
toolkits make it so hard to restyle things by spreading out the draw
code over so much space).

The mouse interactions should be pretty much identical for many of the
widgets if they're reused.

The bindings of the widgets to the engine will need to change as once I
reach that stage they're going to be 99% OSC message driven with some
sort of caching backend.

So, there will be some mismatch, but nothing that would prevent another
project from reusing components.

Given the current rate of development, there's likely a year to go
before I get the current replacement UI completely
functional/somewhat-polished.

@unfa
Copy link
Contributor

unfa commented Mar 31, 2015

About multi-display operation:

pane detach 01

@fundamental you mean about a year to replace ZynAddSubFX UI? And then you could start working on LMMS?

@tresf
Copy link
Member

tresf commented Mar 31, 2015

@fundamental you mean about a year to replace ZynAddSubFX UI? And then you could start working on LMMS?

He was talking about the readiness of his GUI framework for Zyn which will make a good portion of the mockup possible. He never said he'd integrate it into LMMS, but rather was speaking broadly on behalf of its port-ability to non-Zyn uses (which I specifically asked about) :)

I'm curious how the messaging described as 99% OSC message driven with some sort of caching backend can or cannot be leveraged in LMMS. We use signals and slots for quite a bit of our stuff, but Vesa has expressed concern with it for real-time safety operations. Not sure if this message caching mechanism would help us in that regard or if it is more of a MIDI-type-channel that you are describing (or perhaps room for all the above).

-Tres

@rubiefawn
Copy link
Contributor

rubiefawn commented Mar 31, 2015

Very nice. A complete UI overhaul probably won't be any time soon, but I do prefer single-window functionality and would be very pleased if this was implemented. Good work.

@fundamental
Copy link
Contributor

On 03-31, Tres Finocchiaro wrote:

I'm curious how the messaging described as 99% OSC message driven with some sort of caching backend. can or cannot be leveraged.
We use signals and slots for quite a bit of our stuff, but Vesa has expressed
concern with it for real-time safety operations.
Not sure if this message caching mechanism would help us in that regard...

Well, QT pretty much anything is very much unsafe to use anywhere near
the realtime side of things.
I've been procrastinating making a meta bug on the issue of realtime
safety and how to make it an achievable goal within lmms.
https://github.com/fundamental/stoat does a fine job at pointing out
errors as they occur, but it's virtually impossible to fix any of these
issues without some proper documentation detailing the overall
architecture and assumptions of the components of lmms.
Approximately what I think is essential to this is some sort of
architecture level documentation
(e.g. something akin to http://fundamental-code.com/tmp/architecture.html )

Some sort of message passing is the norm for effectively creating a
realtime safe UI, via LV2 atoms, OSC, parameter ID pairs, strings, etc.
Since the UI would still be qt based, using it for signals and slots
would be possible, but I don't think it's a good idea for the long term
plans of this project.

As per why I care about caching, it's mainly to avoid waiting for
parameters when changing views which can be noteworthy in some of the
cases with the current fltk UI.

--Mark

@Wallacoloo
Copy link
Member

Is it possible to easily undecorate QWindows (i.e. remove each window's menu bar) and then have some layout engine that positions them in code? This would allow for an easy way to toggle between a tiled interface and the current windowing interface for multi-screen users. Should also reduce the amount of code affected.

A quick search shows that Qt may support this pretty easily.

@lukas-w
Copy link
Member

lukas-w commented Apr 5, 2015

@unfa

Seriously, I'm gonna put out some cash for implementing this.

Ever heard of bountysource.com? It's made for exactly that purpose 👍
https://www.bountysource.com/issues/10253686-new-ui-concept-single-window

@Umcaruje
Copy link
Member

Umcaruje commented Apr 5, 2015

Ever heard of bountysource.com? It's made for exactly that purpose 👍
https://www.bountysource.com/issues/10253686-new-ui-concept-single-window

Oh yeah, bountysource is awesome!

Should we consider putting bounties on some issues with our donation money? That could lead to a faster development of some features.

@dednikko
Copy link

dednikko commented Apr 5, 2015

I'm supportive of that. It allows.non-devs like me to contribute more than
ideas.

On Sun, Apr 5, 2015, 1:45 PM Umcaruje [email protected] wrote:

Ever heard of bountysource.com? It's made for exactly that purpose [image:
👍]
https://www.bountysource.com/issues/10253686-new-ui-concept-single-window

Oh yeah, bountysource is awesome!

Should we consider putting bounties on some issues with our donation
money? That could lead to a faster development of some features.


Reply to this email directly or view it on GitHub
#1911 (comment).

@tresf
Copy link
Member

tresf commented Apr 5, 2015

Our donation money does well to break even with expenses. Please don't misdirect funds to our donation account, leave them for the bounties. Bounties are a much more sensible approach to these bugs (any developer can step in). We lack the organization to make promises with our own funds. We're not prepared to dispurse and organize a large amount of funds, nor are we prepared turn our volunteers into paid devs. Separate bounties can attract new help without putting unnecessary burden on a relatively inexpensive and simple to maintain team. :)

So please pledge against bounties you believe in supporting, but don't think the current team can necessarily allocate more time. These bounties would put a price on a feature that anyone can fulfill (like new help). That idea sounds promising. :)

@curlymorphic
Copy link
Contributor

oh, the evils of money....... :( :(

@Iniquitatis
Copy link

Sorry for bumping this thread, but this UI looks really amazing! Absolutely can't wait for the release. :)

@RoxasKH
Copy link
Contributor

RoxasKH commented Oct 18, 2019

Maybe i'm the only one, but i think that the green line of the slider should be vertical, because the slider is horizontal, like this

sliderz

@winniehell
Copy link
Contributor

Please note that with #5118 there is already an open pull request to change/modernize the time display. However, that pull request seems to be stalled currently. @winniehell, do you have an update here?

@michaelgregorius @Lathigos The CPU meter got pushed to the right side and I wasn't sure why. So I started cleaning up the toolbar code (#5125, #5148). Unfortunately I didn't have time to continue that recently.

@Lathigos
Copy link

Lathigos commented Oct 18, 2019

@winniehell Ah, I see! Still, thanks for the refactoring, it'll probably speed things up tremendously! 😃

@RoxasKH I've implemented your slider handle design! I've also made the sliders a little smaller and changed some of the widget spacing. How does this look?
toolbar_implementation_rough_preview_002

Perhaps the shading gradient of the slider handle should point upwards (as if light is coming from above), but this looks pretty good as well (as if it's a wedge-shaped knob or something).

@RoxasKH
Copy link
Contributor

RoxasKH commented Oct 18, 2019

@Lathigos I think it looks dope, i could design the gradient from above, but i got no time atm

@RebeccaDeField
Copy link
Contributor

RebeccaDeField commented Oct 20, 2019

@Lathigos My only suggestion is to make sure that you're using shades of gray color picked with the same hue as what is elsewhere in the program so we don't end up with any clashing colors. This is looking great 💯 and I think any other fine details can be finalized with the PR

@mxmilkiib
Copy link

For Time Sig, might a formatting of "4/4" be a better fit than "04/04"?

@Lathigos
Copy link

@mxmilkb I think we should keep it as "04/04", since it is possible to have time signatures with numbers higher than 9. If we would remove (not just hide) the leading zero, then having a number higher than 9 would cause all widgets next to it to move.

@RebeccaDeField The gradient in the picture has roughly same hue as the area next to it according to a colour picker tool, but it has a lower value (brightness) to make it pop out a bit more. Unfortunately, the hue is actually not constant throughout LMMS (ranging from ~190 to ~210), so I am not sure which exact hue to pick. Once we get closer to @budislav's design, though, we'll be able to get properly matching colours everywhere.

@mxmilkiib
Copy link

My thought was that the spacing for one number would be the same as for two numbers so as to keep the other widgets in a fixed position. As in to "just hide" the leading zero.

@RebeccaDeField
Copy link
Contributor

@mxmilkb You will find that even the single UI theme has some hue variations as well as that does not necessarily = clashing. I recommend color picking the hues from a similar area as it is a good way to better foolproof designs where color theory is involved with other contributors. Budislav's design is also flat so the number of colors would be much more simplified than as it is now with more gradients. It is however the nature of an open-source project for more variations to come up than intended and a comb through in this regard wouldn't be a bad idea.

Last time I talked to budislav about colors, we were heading towards something like this while prepping for an instruments rehual so that his design would coordinate with our current branding. The plugins project would also be a great effort towards the single window design.

@zezic
Copy link

zezic commented Oct 20, 2019

Just a sight from aside: do not hardcode colors and use lightness/hue manipulation on very few colors from the base palette like it's done in Godot, Renoise and Ableton Live to allow different color schemes.

@Lathigos
Copy link

@mxmilkb Ah, I see! Yes, that could be possible - but I would rather work on key parts of the LMMS UI that need work the most before implementing that, because I think it looks alright as it is (unless everybody disagrees and demands this feature be implemented, of course 😄).

@RebeccaDeField Can you take a look at the pull request #5261? I've included a full-window screenshot there in which the color palette is more visible. Does it look alright?

@zezic Good point! Luckily everything from the background to the font color is customizable through a stylesheet 😃! In fact, that's also how I implemented the gradient, it's just an entry in the theme's .css file with a start and end color. The only thing not stylizable I think is the widget spacing, but perhaps I could add that in too sometime.

By the way, I've added a pull request (#5261), so let's continue the discussion regarding the toolbar over there!

@RoxasKH
Copy link
Contributor

RoxasKH commented Oct 21, 2019

I'm the only who'd like to see in the single-window lmms, both the color scheme of Budislav and Rebecca that were designed? So we could have a light and a dark theme, like atm there are the classic and the default theme.

@MetalMaxMX
Copy link

That looks like an interesting idea! I also like how the mockup was designed around the single window. I wonder how's progress on this?

@RebeccaDeField
Copy link
Contributor

@MetalMaxMX it's a great mockup that is referenced for many of the more recent design tweaks and continues to be incorporated into the UI as people have time or ability to within the current codebase. I'm currently converting icons to .svgs which is hopefully one step towards better scalability, something this mockup keeps in mind :)

@Lathigos
Copy link

Lathigos commented May 31, 2020

Since I am preparing another branch in which I will attempt to remove MDI from LMMS, I have a few questions regarding the intended design. I can resize all the widgets to fit into the new single-window design properly, except for the VSTs and other external plugins which come with a predefined fixed frame size.

I am unsure how to incorporate this unknown size constraint into the somewhat fixed layout proposed here. Any ideas?

For what I can see now, I see the following options:

  • Make each VST UI a separate window, not within MDI;
  • All UI elements are single window, but the VST UI can be overlaid on top using a single large MDI area spanning the full window. This means LMMS looks and feels single-window up until the moment a VST UI is opened;
  • Create one area within the single-window design in which the external plugin UIs can be rendered within an MDI window. This would still mean everything native to LMMS is single-window, except there's a single smaller MDI area that can be shown or hidden for the external plugins to live in;
  • Try to fit a multi-purpose and variable size area into the current design. If it works, it would be truly single-window design. However, this means that the VST area's fixed size dictates the rest of the layout on-the-fly. Since there is no fixed VST size to prepare for, this could mean the VST UI takes up too much space or takes up too little, this is hard to prepare for unless the surrounding areas are designed to handle this properly (and in an aesthetically pleasing way).

@qnebra
Copy link

qnebra commented May 31, 2020

In my opinion VST should have their separate container/window, as we see a lot of variety in their interface sizes. From tiny to really big. This mean all internal LMMS components can be part of single-window interface, but those external are in separate window.

@SecondFlight
Copy link
Member

SecondFlight commented May 31, 2020

Both Ableton Live and Bitwig open their VSTs as separate windows:
image
image

@RoxasKH
Copy link
Contributor

RoxasKH commented Jun 1, 2020

In my opinion VST should have their separate container/window, as we see a lot of variety in their interface sizes. From tiny to really big. This mean all internal LMMS components can be part of single-window interface, but those external are in separate window.

Both Ableton Live and Bitwig open their VSTs as separate windows:

Yeah, i was gonna say the same, also reaper and cakewalk have vsts in a separate window.
The exception could be FL, that anyway uses a separate window and it's a weird MDI, but still i agree vsts should have separate windows. Also if we use no embedding like Ableton, Reaper ecc this way we're gonna get rid of all the embedding problems, like the resizing ones and other little things like the menu ones.

@qnebra
Copy link

qnebra commented Jun 1, 2020

Also what if unify VST instruments and effects lmms workflow. Basically, from my perspective, those are completly the same except being more wonky in instruments, as they had two separate windows. And I know, there is more stuff going on like arpeggiator, effects and so on in "instruments" Vestige.

@michaelgregorius
Copy link
Contributor

Another argument for separate windows is that many modern VSTs are resizable.

@Krvstal
Copy link

Krvstal commented Jun 13, 2020

That's an amazing work man I wonder when are we going to be able to work with with this beautiful lmms.

@qnebra
Copy link

qnebra commented Jun 13, 2020

That's an amazing work man I wonder when are we going to be able to work with with this beautiful lmms.

Well, it is complicated. Because this is really nice looking UI, but more important in this kind of apps is UX, this mean "How user will interact and use lmms, and how hard it is to use", because nobody wants something pretty but harder than Dark Souls on nightmare-hard difficulty level to use.

@Krvstal
Copy link

Krvstal commented Jun 13, 2020

That's an amazing work man I wonder when are we going to be able to work with with this beautiful lmms.

Well, it is complicated. Because this is really nice looking UI, but more important in this kind of apps is UX, this mean "How user will interact and use lmms, and how hard it is to use", because nobody wants something pretty but harder than Dark Souls on nightmare-hard difficulty level to use.

Well I'm pretty sure it's easier than the actual interface where you end up opening windows instead of making music.

@RebeccaDeField
Copy link
Contributor

As stated above by devs in previous comments, we already agree that this mockup is the right direction to head in and already make efforts with the abilities, manpower, and steps possible with where LMMS is at now, as we can't work with a version of LMMS that doesn't exist yet.

All design-related pull requests end up referencing this mockup and there's no argument over whether or not we should, just a matter of time and number of devs, and the degree to which the program needs to fundamentally upgrade to reach this point.

No one is blocking any steps towards that, which seems to be a common misconception on the thread. I'm hugely in favor of this direction and hope that we find ourselves with a UI much like it at some point. There are a lot of steps to get there, one of which I am working on, despite it being one tiny step of so many needed. 👍

@LMMS LMMS locked and limited conversation to collaborators Jun 14, 2020
@Spekular
Copy link
Member

I'm locking this conversation, as it gets a lot of comments that are essentially just "+1", or debating issues that (1) have already been resolved or (2) aren't relevant or useful to discuss right now.

If you'd like to say something about this issue, feel free to do so in the LMMS Discord server. Perhaps those of us with access to comment on locked threads can copy over any useful comments.

@tresf tresf changed the title New UI Concept - Single Window LMMS redesign concept Mar 29, 2024
@tresf
Copy link
Member

tresf commented Mar 29, 2024

Behance link updated (see original post) and title updated per request of @budislav (via email). @budislav has also requested that we close:

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests