Lmms: New UI Concept - Single Window

[budislav]

(Click to enlarge)

---

Hi all,
My previous work for Zynaddsubfx has same purpose to dock all windows in one.
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

[oeai]

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

[musikBear]

stunning!
..but i am feeling a chill, cause i have spent ..._absurd_ time learning zyn's current UI _sigh_ :hamster:

[BaraMGB]

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]

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]

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

:+1:

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! :+1:

[tresf]

@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]

"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]

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. :+1:

[budislav]

"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 :+1:
I will upload one mockup that shows how it looks on full HD res.

[tresf]

That's what I'm talking about :+1:

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

[softrabbit]

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]

@tresf

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

Thanks, didn't know that :)

[tresf]

Thanks, didn't know that :)

Sorry, it has to be the first character in order to work properly. :+1:

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]

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

[budislav]

@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]

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]

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

[fundamental]

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]

About multi-display operation:

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

[tresf]

@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

[iansannar]

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]

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]

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]

@unfa

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

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

[Umcaruje]

Ever heard of bountysource.com? It's made for exactly that purpose :+1:
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]

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:
:+1:]
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
https://github.com/LMMS/lmms/issues/1911#issuecomment-89831381.

[tresf]

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]

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

[Iniquitatis]

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

[budislav]

Thank you all :)

@Lukas-W Why not Kickstarter?

[tresf]

@budislav that bounty page seems to have some good integration with issue trackers, and the bounty is on the bug itself so it puts onus (and thus contract) on the bounty hunter.

Kickstarter campaigns often are promoted, led and organized by the project team. Kickstarters also tend to promise much more features and have the tendency to raise monetary amounts so large that the project may not be able to handle with its given resources.

We aren't opposed to a kickstarter, but I argue we should be very cautious what we promise if we do. We need to be conservative on the amount of money we accept and the amount of features we promise. :)

[budislav]

@tresf I believe that bounty is the best for software project, but Kickstarter is better for bringing more money. If we make a detailed project plan and with posting on social networks this can work, like Krita https://www.kickstarter.com/projects/krita/krita-open-source-digital-painting-accelerate-deve/description

[Wallacoloo]

Ok, so is this thread about taking the UI code fundamental added to Zynaddsubfx and integrating that into LMMS? Or is the goal to just achieve a look similar to the mockup using whatever tools fit best with the current LMMS codebase?

[tresf]

@budislav too much money is a pretty big problem right now (I'd rather not go into specifics in this thread).

@Wallacoloo from what I am reading, a bit of both, depending on approach

[tresf]

@Wallacoloo to clarify a bit...

Single window is a pretty big initiative on its own and many of the tasks are quite separate from the theming initiatives.

To do this proper, we probably would be best splitting this initiative into some higher level components and go from there.

What is tempting about the Zyn GUI framework is that it may solve some of our problems and reduce efforts in the long run, but they aren't necessarily mutually inclusive.

Also, as you well know, this is a tremendous amount of work and requires clear vision and coordinated agreed upon effort.

For starters, I think we can start prototyping some single-window code enhancements and proceed from there. Once we have a clear vision, someone would have to help manage this effort and also help decide the effectiveness of leveraging the Zyn GUI code over rolling our own.

Said person would need a pretty deep understanding of the codebase (both DSP as well as RT-safe GUI).

Of course... Some of this will creep into (or replace) the 2.0 future map, so we'll need to be mindful of that as well.

[budislav]

Are anyone works on this??

[Wallacoloo]

@budislav Not to my knowledge (but maybe someone will pipe in differently).

LMMS is in "feature freeze" as we prepare for the next release, meaning that most of the developers are focusing on fixing bugs over adding major new functionality.

After feature-freeze though, I think we'll see some gradual progression along this front. I certainly plan to do my part, though I will probably be doing more "behind-the-scenes" work (My current plans involve cleaning up the code around how the UI interacts with the core - decoupling the two & hopefully implementing some sort of message passing scheme as fundamental has discussed in this thread).

[budislav]

@Wallacoloo thanks for answer. That sounds nice.
Do you know approximately how long it will be "feature freeze"?

[tresf]

Do you know approximately how long it will be "feature freeze"?

Probably a month or so. The major holdup is one of our plugins "ZynAddSubFX" which went through a small code upgrade and getting it working without bugs has taken a considerable amount of time and attention.

[budislav]

@tresf thank you. I wish you success in that.

[Wallacoloo]

Btw, @tresf I think that after this release we should discuss the
possibility of entering feature freeze at the same time the first (alpha)
release candidate is released, and no earlier.

Spending 2-3 months in a feature freeze seems suboptimal, and it's a bit
misleading when we're actually still waiting for one more feature to be
completed (zyn upgrade).

[tresf]

possibility of entering feature freeze at the same time the first (alpha)
release candidate is released, and no earlier.

Yeah, IIRC, the title "feature freeze" was introduced by Vesa in one of the few posts he has made since April. This thread probably isn't the place to discuss this, but since we're on the topic I'll elaborate a bit...

At this point, we could easily freeze and release RC1 without Zyn and @curlymorphic and I are both OK with this.

@Umcaruje, yourself (@Wallacoloo), @curlymorphic have made some progress getting Zyn functional, but we're still stuck on a few hard-crash items. Overall, Zyn 2.5 has postponed the 1.2 release since at least April. That combined with some very busy schedules and we're here in July. :)

As far as the feature freeze, that's normally done on a dedicated branch to allow master to continue getting features, but we've held off on splitting to a stable-1.2 branch intentionally so that the rather complex Zyn 2.5 code can be merged before the branch occurs, but we can certainly hold off on that until 1.3 (or 2.0, depending on who you ask).

Again, this is probably the wrong area to discuss this, but if we can reach a mutual decision on Zyn 2.5, we'll know how to proceed. Thoughts welcome.

-Tres

copied this post to 1991 - ZynAddSufFx Upgrade -- Curlymorphic

[tresf]

To bring this back on topic regards to the feasibility of the single-window interface, was the plan to move to the future Zyn GUI framework?

[Wallacoloo]

@tresf I don't think there's a solid plan for it. There are many ways to approach it though, and each with various timeframes, etc.

Doing things properly, we need to work on decoupling the core from the gui. If we go with a message-passing system, in which the gui thread/code never directly modifies anything but just requests the core to do something, then we can move away from all the locking and real-time issues. If we make this message passing system externally interfaceable (e.g. sockets instead of just a thread-safe queue), then LMMS becomes easily scriptable/automatable, and we can also write testsuites a bit easier.

Choosing a message-passing system based on that, it seems that OSC will serve us. I haven't read up too much on the alternatives, but if using OSC will make it easier to use Zyn code, it seems a reasonable choice. At first glance it seems to be an all-or-nothing type of thing: ditch Qt altogether and use Zyn's UI framework, or stick with Qt and avoid Zyn's framework. However, using a message-passing system gives us the power to have multiple different GUI implementations, so we can adapt the current GUI to work with the message-passing system and then slowly build up this new GUI to the point where it's ready to replace the existing one (it's still an all-or-nothing thing, but it means the changes can happen gradually and sustainably without ever leaving LMMS unusable).

My recommendation for proceeding with this is as follows:
1. Implement the requirements for the core to listen for OSC messages and queue them to where they can be processed at a safe time.
2. Implement the requirements for the gui to send OSC messages.
3. Go through gui callbacks individually and move the top-level callback code into the core, replacing the gui side with an OSC message.
During this step, the core and gui are still in the same executable/process, and because this can be broken down into smaller tasks (i.e. commits that change just a single callback can be committed to a stable branch), it's much more manageable. We could potentially even do this directly in master to avoid merge conflicts, or we could maintain a separate branch & be prompt with pulling changes from master (I suggest the latter because it would be bad if we ever ended up with a permanent mix of slots and OSC code).
4. Once all OSC messages are implemented, work to move any mixed gui/core code into separate files and compile core and gui separately.
5. Add a new folder to master for the alternative UI and we can begin developing it, hopefully basing it off Zyn.

Open to discussion! Going the Zyn framework route, the GUI would have to be a ground-up rewrite. Having everything abstracted via OSC messages would make the rewrite much easier, though, as would being able to borrow routines from Zyn.

[tresf]

Having everything abstracted via OSC messages would make the rewrite much easier, though, as would being able to borrow routines from Zyn.

I find the OSC zyn-ui GUI rendering/framework portions to be particularly interesting because as Mark has stated, some of the C++ and/or QT code gets quite lengthy (or simply lacks functionality) for some fairly trivial UI concepts.

I feel like -- currently -- an overwhelming amount of our GUI code is statically managing layout because of the lack of a proper flow container for widget items and a decision to use statically sized windows and an MDI layout early-on in the project. Perhaps the initiative will vastly shrink the codebase as well as the learning curve to add plugin items. :+1:

[curlymorphic]

Most of my thoughts on this have been brought up in the last few posts, so I wont repeat them.

The use of a messaging system, and separating core form the ui would be a very good step in the right direction, and could be done as a separate project, With the size and complexity of this task I feel It may be a good idea to try and implement this, before any actual gui changes.

As for messaging systems and RT safety, I have no real experience in this, I have done reading on the subject, Seeing as we are already going to be including OSC libs , both lo and rtosc, with the ZASF 2.5 upgrade I feel we should consider utilizing them.

@fundamental linked me his tutorial on using rtosc, but as of yet I have not had time for that sub project. but is something I would like to spend the time on, before undertaking this task on a codebase as large as lmms.

https://github.com/fundamental/rtosc-tutorial

[musikBear]

a micro tiny comment on the freeze
lmms is -one- method away from having _the_ feature, that perhaps has been the most requested over time. Lmms 1.2 can have ghost-notes, if only 2155 was addressed..

[tresf]

@musikBear please don't lobby for other bug reports in this one. :+1: We all know the popularity of ghost notes. :+1: Popularity doesn't drive features (yet). Perhaps we'll be there some day, but for now, we do all what we can.

[fundamental]

@Wallacoloo yeah, that sort of multi-stage implementation/upgrade plan is basically what's required. Fixing up architectural problems is a messy affair, but doable when the rework is an organized effort.

[softrabbit]

I'm not out to pee on anyones parade, but after letting this proposition sink in for a while, I can't help but wonder. And I've seen enough designers being very firm about their Vision, so I just have to ask:

Looking at the blue drawing of the window subdivision, I read things like "MIXER or AUTOMATION EDITOR or MIDI EDITOR". Is the intention really to:

• Force users to have e.g. the mixer in the middle and the instruments at the bottom, or will the layout be configurable at least to the degree that I can move these top level blocks? I've always had the mixer at the bottom and I'd really like the freedom to put it there in the future.
• Make certain parts compete for space? What if I like to have both mixer and automation editor open and want to allocate a lot of space for them? And why have the BB-editor share a block with the song editor? I'd understand better if it was BB &/or MIDI editor, as those are kinda parallel concepts.

[J5lx]

IMHO realizing that drawing similar to the way Blender's UI works (see edit) would be a really nice solution to both problems you listed. However I _believe_ Blender uses some tightly coupled Python code for it's UI, so I don't now whether it could just be dropped into LMMS or had to be written from scratch.

EDIT: Just to be clear: I'm mainly referring to the way Blender allows for rearranging the window "areas" (editors), not necessarily to the other stuff.

[budislav]

Ok, I made solution for configurable layout and multiple monitors.

User can click on tab then drag and drop on some other section.
He can save layout from menu bar and he can switch between them from drop down select button from main toolbar.
LMMS should have some default layouts like mixing, arranging,..
User also can collapse tabs by double click on tab. Left and right sections will collapse in vertically line.
There is only one limitation. Instrument and effect rack have fixed height so this rack can't dock on left or right, just on top, middle or bottom sections. Controller rack have fixed width so it can dock only on left section.

I think this system would allow enough freedom to set a wanted layout. There is too many combination to show, so I would not draw every of them.

[TheColorRed]

If anyone has ever used Unity3d, the editor looks very much the same with tabs and stuff like that, and the core code is separated from the GUI code and connected with an API of sorts, where the GUI is mainly written in C# and the core is mainly written in C/C++. Users of the software can also modify GUI when creating plugins for the engine; they can add things such as custom windows, menu bar items, etc. all using C#. I started a mesh editor that would allow you to morph the mesh of 3d objects. All because of this C# API that they have. Also you can edit the C# code, save it and the editor will compile it and update the GUI all without restarting the software.

This could be helpful for those who don't want to edit core software code to be allowed to add some cool features to the software, such as a different way to edit beats or a different way to use the piano roll. The options would be endless. Using a higher level language such as C# will allow for more people to be able to add these features/plugins to the software, since the language is easier than C/C++ for most people.

BTW @budislav this looks awesome! I love using software that looks pretty :) For game development I use Unity3d because it is extendable and looks great! Software that has a UI that looks like it was made in the 90's is very unappealing.

[curlymorphic]

@TheColorRed

I have used Unity3D, and agree the ability of being able to code addins in c# is very nice, and in that scenario works well. I also currently use AutoDesk Revit that has the same feature, but from my searches is not used as much. I feel this works because the majority of users of unity are already coding in c#, most revit users are not coders.

This could be a massive effort, on the part of lmms, To include a scripting language, and write an api for this use.

This is a valid idea, but I am unsure if lmms has the resources to implement.

[J5lx]

This could be a massive effort, on the part of lmms, To include a scripting language, and write an api for this use.

Yep. I had to embed Mono specifically once and it was quite a challenge since there’s no documentation except for the most basic stuff and the API docs, and even those are not quite comprehensive. Many functions are not even documented at all IIRC. At the end I found an alternative, so I switched happily.

If a scripting language is desired, I believe Python could be a better choice - I didn’t try it myself yet, but when I was working with Mono I read many times that it would be rather easy to embed.

[budislav]

@TheColorRed Thanks! I always put UI on the first place :)

[budislav]

Can somebody add UX label on this topic?

[Umcaruje]

@budislav done.

[budislav]

@Umcaruje thanks :)

[M374LX]

Nice UI concept, but will the user be able to view multiple instruments at the same time?

[8tab]

Why do you want to view multiple instruments at the same time?

On Thu, Aug 6, 2015 at 3:17 PM, Alexandre Almeida [email protected]
wrote:

Nice UI concept, but will the user be able to view multiple instruments at
the same time?

—
Reply to this email directly or view it on GitHub
https://github.com/LMMS/lmms/issues/1911#issuecomment-128359351.

[budislav]

@M374LX no, because there is no need for that. User have all effects in one rack with instrument and he can quickly switch between all instruments and all type of effects in one project.

[mamarilmanson]

:+1:

[michaelgregorius]

@budislav Don't be too quick with saying that there is no need for being able to look at multiple instruments. I can imagine that LMMS has many different users with many different needs.

Also please keep in mind that LMMS supports VSTs which provide their own GUIs with different sizes anyway. So if you want to present internal plugin GUIs in a fixed place VST plugins will have to be presented in a different manner which I can imagine might be confusing for users.

I also think that the current fixed size of the existing internal LMMS plugins puts a constraint on the features that you can implement for them because there is not too much space to put the controls on to compared to some VSTs. I think that different sizes and layouts give quite a lot of character to VSTs and I think it would be great if LMMS would provide a similar flexibility.

[tresf]

To @budislav's point though, this isn't a deal breaker and his mockup is a concept.

I find the multiple-instrument interface to be hideous, counter intuitive and reminds me of a deck of cards. The only reason I use it is because of what I feel lack of functionality (not a complaint, an observation) as it allows me to do a side-by-side comparison of instrument knobs which should probably just be bulk "copy/pastable" from a UI perspective (not to mention that many of our plugins don't offer a visual spectrum feedback, so the knob positions can be arbitrary from a visual perspective)

But multiple instruments really comes down to "context" and in the context of a track, you generally are tweaking a single instrument. If there is enough demand by our users for multiple instruments interface, we find a way to make it possible.

But design is intended to be driven by usability, but in the end it is largely driven by opinion. Since opinions never align, we'll never agree. From what I'm reading above, the overwhelming feedback is to move to this design, so if we all work toward this single-window interface, we have to make some difficult compromises and the fastest way to that is to 1. Drop the multi-instument interface or 2. Brainstorm and provide the work-around which makes both wishes possible.

-Tres

[budislav]

"you generally are tweaking a single instrument" Thank you @tresf .
This problem can be solved very easy by adding option for splitting on two rack horizontally or vertically so if user have two screens, vertical split should be better choice.

[M374LX]

"you generally are tweaking a single instrument" Thank you @tresf .
This problem can be solved very easy by adding option for splitting on two rack horizontally or vertically so if user have two screens, vertical split should be better choice.

Great, @budislav!

[musikBear]

looks amazing! :+1: :100:

[eagles051387]

After reading through this thread, this is just a suggestion Why not give
users the ability to choose between multiple windows like we have no or
single window as per the mockup?

On Sat, Aug 8, 2015 at 2:29 PM, musikBear [email protected] wrote:

looks amazing! [image: :+1:] [image: :100:]

—
Reply to this email directly or view it on GitHub
https://github.com/LMMS/lmms/issues/1911#issuecomment-128973267.

Jonathan Aquilina

[musikBear]

@eagles051387 Has a point there. Also
How is this single window-concept looking on older screens?
Will the single-screen design _only_ work well on wide-screen?
There are still many users with older monitors, how will those see the design?

[eagles051387]

How are layouts handled right now? Can they be done through css?

On Sun, Aug 9, 2015 at 12:09 PM, musikBear [email protected] wrote:

@eagles051387 https://github.com/eagles051387 Has a point there. Also
How is this single window-concept looking on older screens?
Will the single-screen design _only_ work well on wide-screen?
There are still many users with older monitors, how will those see the
design?

—
Reply to this email directly or view it on GitHub
https://github.com/LMMS/lmms/issues/1911#issuecomment-129150602.

Jonathan Aquilina

[Umcaruje]

How are layouts handled right now? Can they be done through css?

Sure, you just need to add

* {
    single-window: true;
}

To your style.css.

If this doesn't work it probably can't be done through CSS.

[eagles051387]

If styling is done through CSS I am more then willing to work and implement
bootstrap based styling that way we can work on any screen.

On Sun, Aug 9, 2015 at 2:03 PM, Umcaruje [email protected] wrote:

How are layouts handled right now? Can they be done through css?

Sure, you just need to add

• {
  single-window: true;
  }

To your style.css.

If this doesn't work it probably can't be done through CSS.

—
Reply to this email directly or view it on GitHub
https://github.com/LMMS/lmms/issues/1911#issuecomment-129171176.

Jonathan Aquilina

[lukas-w]

Hehe

[tresf]

How are layouts handled right now? Can they be done through css?

You've asked this before. Find the last time you asked and the answer will be the same.

[budislav]

@musikBear
"How is this single window-concept looking on older screens?"
single window workflow is looking better on older screens.

"Will the single-screen design only work well on wide-screen?"
No.

"There are still many users with older monitors, how will those see the design?"
Perfectly. Are you one of them? Which resolution your monitor have?

This workflow will works better on smaller screens than present UI. I worked on this over 5 month and I brought it to perfection. Everyone who want to say what is wrong or what is not maybe he just need to study UX and UI before.

This can help
http://www.jiscdigitalmedia.ac.uk/guide/graphical-user-interface-design-developing-usable-and-accessible-collection,

http://www.usability.gov/what-and-why/visual-design.html

This are statistics about screens resolutions, the latest data from January 2015 are the most important
http://www.w3schools.com/browsers/browsers_display.asp

[musikBear]

This workflow will works better on smaller screens than present UI.

That is all i needed to hear
Very fine work indeed.

[mamarilmanson]

any updates about this UI? :D

[budislav]

I would like to know :)

[tresf]

any updates about this UI? :D

Minor, yes. @Wallacoloo has begun implementing the first stages of the OSC messaging system ("with the goal of reducing the coupling between the core & gui")

Choosing a message-passing system based on that, it seems that OSC will serve us. I haven't read up too much on the alternatives, but if using OSC will make it easier to use Zyn code, it seems a reasonable choice.

via https://github.com/LMMS/lmms/pull/2252.

But as he originally stated:

@tresf I don't think there's a solid plan for it. There are many ways to approach it though, and each with various timeframes, etc.

So, slow and steady. :+1:

[budislav]

Great news :+1:

[michaelgregorius]

I understand that the decoupling of the GUI and the core code is related to the current GUI. But I think the new GUI elements could be implemented independent of the work done on the decoupling anyway.

One way to do this might be to create a new separate folder for the new widgets and to start implementing them. These widgets should not be used in the "productive" code, i.e. they should not be connected to any existing core functionality yet. This would mean to only implement the rendering and perhaps some useful signals and slots which are not related to any core functionality. The intention is that due to the decoupling the core code will likely change too much anyway and that therefore we should only connect the new widgets once the core is stabilized.

We could also add a new project to the CMake file that's used to build a prototype of the new GUI or to test the new widgets.

Obviously this would still be a lot of work but it should be possible to start this in parallel (with the risk of the new widgets not being incorporated of course).

@budislav What font did you use in the concepts by the way? Is it a font for which it would be ok to put it into applications resources and to distribute it?

[budislav]

@michaelgregorius That font is Droid Sans.
Yes it would be ok to put it into applications resources and to distribute it.

[tresf]

@michaelgregorius I agree the tasks aren't mutually exclusive, but remember that this new UI (AFAIK) is hypothetically QML based and uses a completely separate work-in-progress framework... https://github.com/fundamental/zyn-ui-two

[fundamental]

Yeah, the zyn replacement UI framework (tentatively named 'zest') is quasi-qml based. Don't judge the current progress by the lack of progress in that particular repo though. Right now I have a bunch of stuff done locally while I'm working out how OSC interacts with the reactive dataflow of qml and the layout stuff is getting rewritten yet again to upgrade it to a fully global constraint optimization setup. Everything is still in pretty early stages, but it's going to eventually get there.

If there's someone really interested in digging into it I can try to make an effort to get the commits pushed off of just my machine, but at the moment there's more design notes than a working toolkit.

[mcanthony]

@fundimental I have been (rather silently) monitoring the progress of your Zyn related efforts as well as the integration of @budislav work into LMMS and I have been especially interested in the architecture you have been describing here and as it relates to your ZynAddSubFX overhaul in particular. I intend to port Zyn to NaCl for the WAM project: https://github.com/webaudiomodules - in which I think a lot of your work will be crucial in my task of retrofitting an HTML5 based UI.

I am a C/JS programmer and I pretend to write C++ - if I can be of any assistance to your efforts I will surely do my best.

[mcanthony]

It appears I misspelled @fundamental in my last post (which is really special of me since github has auto-complete) so here's a message just for the purposes of @mentioning @fundamental.

[fundamental]

@mcanthony I should be able to get the WIP code up this weekend, though until a particular mruby bug is fixed, it's not going to be able to do too much. For your goal of porting zyn, I don't really see how my effort really changes things all that much, though if you wanted a standalone zyn with a browser based UI I could see how the OSC layer would come in handy.

As this toolkit seems to be of general interest beyond just it's use in zyn I've setup a mailing list for it:
https://www.freelists.org/list/mruby-zest

[mcanthony]

The UI/OSC layer is most interesting to my project, as for porting it eases the pain of replacing the UI code with something that fits with the paradigm of CSS driven UI even if the code itself is not useful to me, the concepts behind the construction of the GUI framework for Zyn have gone a long way toward bettering my understanding of the issues involved, and seem to be far more fitting to be remapped to a browser context. Your ideas and statements about how The porting side of things, as far as signal processing shouldn't be very OS bound, so this should be fairly straight forward. Perhaps it was heavy handed to say it's crucial to my goal, it has been more crucial to me goal of understanding the process of making such modifications to the fabric of Zyn's UI arch such as you have been made to do.

Aside from that I am simply a fan of the UI and the synth in general, so I seek to support it's betterment. I may end up using the standalone Zyn library if the full version of the app itself becomes too problematic to port.

[fundamental]

@mcanthony well, that took longer than it should, but here's the current code:
http://fundamental-code.com:8080/index

It's not moving quickly, but I think it will eventually make it to the finish line.

[Reaper10]

I thought of a GUI compromise

[jackokring]

Zyn as I understand uses the FTLK toolkit, it is very memory efficient, an original xfce desktop toolkit for a small X desktop. It does not use Qt in the settings window. It is an embedded X11 component in Qt.

Lest not forget, it's sound output that matters. For those who note such things FTLK (faster than light tool kit) is statically linked, and design options are definitely not GTK or Qt level. But then again it won't flood the processor memory bandwidth with excessive pixmaps. I'm not sure if the project is 2D accelerated, but a replace grey square with scaled pixmap could add much. But that would be a upstream on the FTLK project perhaps.

EDIT: Try the xfce4 or (higher?) desktop to see what's possible.
EDIT: Using a Qt keyboard exported as an X11 control would maybe (although debatable due to Qt container code size) improve performance of multi-part polyphonic instruments using many tracks of such.

http://www.fltk.org/documentation.php/doc-1.1/toc.html and the T and L are backwards in my post.

EDIT: Possible fast to do optimizations:

1. Get rid of the keyboards in Zyn views, the one in the main instrument window is fine. (makes code smaller)
2. Change the FLTK default colours.
3. Change the default button style.

As an extra
is a synth design I'm working on. It could do with some tart. The limits are, the knobs must have the same centres and diameters, and be equally spaced. (the last 3 on each row maybe a pixel or so out. And an icon 48*48 too.

[tresf]

faster than light tool kit

Fast, Light Toolkit

Lest not forget, it's sound output that matters [...] that would be a upstream on the FTLK project perhaps.

I'm not sure what you've inferred from this thread, but Zyn's changes are happening upstream and this thread assumes whatever Zyn uses, we can also use, not the other way around.

Get rid of the keyboards in Zyn views, the one in the main instrument window is fine. (makes code smaller)

What are you referring to, our instrument plugin keyboard or one of the mockups? It's hard to know what context these comments are made for/in.

As an extra [Jacobi] artwork is a synth

I feel that is more appropriate in #2452.

EDIT: Try the xfce4 or (higher?) desktop to see what's possible.
EDIT: Using a Qt keyboard exported as an X11 control would maybe

Now I'm really confused.

I'd recommend you scan the fundamental posts from this thread, he's the one writing the GUI framework which may someday make the mockups in this thread possible. :+1:

[jackokring]

I'm not sure what you've inferred from this thread, but Zyn's changes are happening upstream and this thread assumes whatever Zyn uses, we can also use, not the other way around.

True but Zyd if it sticks with FLTK, would have it as a further upstream.

What are you referring to, our instrument plugin keyboard or one of the mockups? It's hard to know what context these comments are made for/in.

The keyboard in the basic which is not there in the advanced view.

I'd recommend you scan the fundamental posts from this thread, he's the one writing the GUI framework which may someday make the mockups in this thread possible.

Sounds good, but when shuffling pixmaps (intense GUI overlays and effects), the sound also travels along the memory bus in the system too. I like the mock ups, and think they are reasonably efficient on mathematical calculations needed, and pixmaps needing to be transferred to graphics memory for rendering. But me I'd recommend square pots to not need a sin/cos table occupying layer 1 cache in the processor. #2460

[tresf]

The keyboard in the basic which is not there in the advanced view.

Then please post on the Zyn project page, we aren't discussing that here.

I'd recommend square pots to not need a sin/cos table occupying layer 1 cache in the processor.

Recommend this in what exactly?

[fundamental]

@jackokring I have no idea where you're getting this concern about pixmaps from. There's no other mention about them in this thread and the toolkit which I'm writing (which is _NOT_ FLTK) doesn't even have a widget which supports pixmaps so far.

Profiling performance is a key part of what I'm doing with this toolkit as I'm trying to have very reliable 60+Hz full screen updates, 20+Hz resizes, and 10+Hz full UI reload (as code hotloading is supported). Once partial redraws are added back to mruby-zest (from the zyn-ui-two code) a very trivial amount of CPU, bus, and GPU time should be spent for each frame rendered.

[jackokring]

Recommend this in what exactly?

In a fastest possible toolkit. A bit of square humour. The fastest render would be a texture map on a surface rotation in openGL.

I suppose the initial confusions/confisions on my part were about the application of this UI scheme to the whole LMMS or just for plugins.

[budislav]

All right, so I got a mail from Alexandru Celea film producer from Mad Horse films about using my lmms ui designs for their new short movie about a group of high school kids who start a music label.

They would love for those kids to have this UI on their screens when they are working, also new zynaddsubfx gui. I am not kidding! Of course I gave them permission to use them. :)

That forced me to redesign LMMS one more time. Modern, flat and clean.

[iansannar]

Please make this gorgeous ui a reality

[IvanMaldonado]

Congratulations! I feel very excited for you, I have been inspired by this work of yours on my humble themes, I really would like to see your work in action some day.

Enjoy the success you just got, because you deserve it!

[budislav]

Thanks Ivan but this is more for community than for me and motivation for developers to start working on this.

[suhr]

@budislav Very nice, though a way too Bitwig-alike.

[budislav]

Thanks @suhr. Yes, present UI is a way too Fl Studio-alike.

[suhr]

Can we be different? Not yet another Fl Studio/Ableton/Bitwig/etc, but a cool open source DAW with its own spirit.

[tresf]

Can we be different? Not yet another Fl Studio/Ableton/Bitwig/etc, but a cool open source DAW with its own spirit.

We appreciate the enthusiasm, but we could do without the banter, please.

[suhr]

But seriously, a program is much nicer to use when it have it's own UI. Though this is not critical, this is an issue nevertheless.

I believe I'm not the only man that may be triggered by the fact that the new LMMS UI reminds Bitwig UI.

[Umcaruje]

We appreciate the enthusiasm, but we could do without the banter, please.

@suhr is right though, the mockups look a bit too much like Bitwig.

[tresf]

@suhr is right though, the mockups look a bit too much like Bitwig.

Which part? The rainbow track palette? I find that minor. There's only so many ways to preset an interface. Lotus 1,2,3 vs. Excel. KDE 3.5 vs. Windows 95. Android vs. IOS. @budislav's mock-ups are original and are based on our the original LMMS gui design.

[suhr]

Which part?

[budislav]

BitWig is the latest and most modern DAW. It have the smartest UI till this day you like that or not. If that isn't enough reason to look up on Bitwig when I tried to redesign LMMS then I don't know which DAW have the best UI? Keep in mind UI without floating windows.

@tresf thank you so much! I spent so much time into this and I know exactly what looks on bitwig and what not, so if someone have something against bitwig or with this designs I can't help him.

"Can we be different? Not yet another Fl Studio/Ableton/Bitwig/etc, but a cool open source DAW with its own spirit."
What kind of spirit? This is not human being. You can't invent hot water. If you want to put all instruments in one rack that will definitely looks like A.Live, Bitwig, Reason, Tracktion, Renoise..

This discussion have no sense. 99% of users would like to have this UI. I can't invent cold fusion here please.

@suhr do you have better mockup?

[budislav]

Yes and I can show you more things that looks like bitwig and you didn't notice. What do you want actually?

[Umcaruje]

if someone have something against bitwig or with this designs I can't help him.

I'm a bitwig user. I love bitwig. This design is infinitely better than the current one, but you don't need to bash someone for stating that your design looks a bit too much like Bitwig. Everyone is entitled to their opinion.

[suhr]

Oh, and Note – Automation – Devices/Plugins – Mixer have _the same_ order you can find in Bitwig.

@budislav

What kind of spirit? This is not human being. You can't invent hot water. If you want to put all instruments in one rack that will definitely looks like A.Live, Bitwig, Reason, Tracktion,..

Somehow commercial DAWs all look different. Somehow Radium looks different. Somehow Helm and Dexed look different. Somehow Blender 3D looks different. Somehow... well, the list can be long.

99% of users would like to have this UI.

That's why I said it's not critical. You mockup is still infinitely better than current LMMS UI, even though it looks like Bitwig. But again, this is still an issue.

What do you want actually?

Creativity.

[budislav]

@suhr
"But again, this is still an issue"
No this is only issue for you.

"Creativity."
So why don't you make something creatively and show all of us? If you want something so original spend some time on this problem.

I am not going to argue with you any more I see you don't know nothing about UI. You just come here in trying to stop some progress and that is not cool.

[suhr]

Well, I'm not going to continue this ad hominem discussion too.

[Spekular]

@budislav I like your mockup but I think @suhr has a point, and you're
being very defensive. Critique is a good thing.

[budislav]

@Spekular Suhr was very rude when said he expect more creativity like someone paid me to do something. I spent thousands of hours on trying to fix LMMS UI, and how I see this will never be new UI. Someone will always take care for that.

I don't need critique from non designers, especially not from someone who does not doing anything about this. Imagine I start to speak like that to developers what is good in their code and what is bad, like I know something about programming. Should I also say thanks for marked my design as plagiarism?

For the last time, some things from designs are similar or same because they are existing in both of programs. It would be normal if I borrow better things.

[michaelgregorius]

Critique is a good thing.

I would like to extend this to "Constructive critique is a good thing." To me the critique boiled down to "LMMS should be different for the sake of being different" which in my opinion is not a good thing.

If LMMS tried to be totally edgy and different from all other DAWs this would ruin the usability especially for experienced end users. There are certain expectations that users of DAWs have and if an application disregards too many of them users will not feel at home and rather ditch the whole thing to look for something that's more familiar. So there will (an IMHO should) always be elements that look familiar to other applications, e.g. each DAW has Mute/Solo, has a concept of tracks, a mixer, etc. How many ways are there to present these elements?

@budislav Don't let this discourage you. I (and I assume many others) really appreciate all the work that you have put into this. About this never becoming the new UI: never say never. However, it doesn't seem to suffice to post new images into this thread to kickstart the realization of your UI. There might be several reasons for this.

To me one of the current main problems of LMMS is the missing separation between the core code and the GUI code. If it were separated better I think it would be much simpler to switch the UI piece by piece to the new design because developers would only be concerned with GUI related code and there wouldn't be much other non GUI code that could get in the way. Unfortunately doing such a separation with hindsight at the current size of the code base is rather hard and "non-sexy" compared to other tasks so there might not be many people willing to work on such an undertaking.

The other problem seems to be of organizational nature. Even if we tried to implement the new GUI with the current code base this would definitively take an orchestrated effort which does not seem to be that simple to organize with the current tools at our disposal.

[budislav]

@michaelgregorius

If LMMS tried to be totally edgy and different from all other DAWs this would ruin the usability especially for experienced end users. There are certain expectations that users of DAWs have and if an application disregards too many of them users will not feel at home and rather ditch the whole thing to look for something that's more familiar. So there will (an IMHO should) always be elements that look familiar to other applications, e.g. each DAW has Mute/Solo, has a concept of tracks, a mixer, etc. How many ways are there to present these elements?

Exactly!

I understand the problem about separation between the core code and the GUI code, thank you for detail explanation. I think @Wallacoloo started working on this separation if I remember good? It would be very good if more developers are willing to help him with this.

This would probably increase performance of LMMS? I don't see more important thing if that is correct. Even this cool UI is not important like stability of software.

When I changing size of mixer or song editor a whole graphics just freeze. I have i5 3ghz, 8gb RAM and radeon r9 270. Don't understand why whole GUI reacting so slow.
Adding a new features, that can just make things more complicated for this separation right?

[musikBear]

"Constructive critique is a good thing."

Actually the only good form of critique

imo the only issue is:
Could the design be deemed a direct copy, and hence be ground for a law-suit for stealing _intellectual rights_ as plagiarism? If so, not good! If not, _forgedaboudid_, the design is stunning!

[budislav]

@musikBear Nobody goes to jail. This is an open source project and we don't sell anything. Otherwise BitWig is A. Live copy so if they are not subject of property debate nobody isn't. Design is borrowing ideas in many cases. Look at just on web world, show me one original design. If I start listing all softwares which one looks on other I would need a whole year. Look at new Da Vinci Resolve GUI
http://310.ch/_freespace/blackmagicdesign/RESOLVE_12_INTERFACE_ORIG.jpg

[Spekular]

@michaelgregorious that's why I said "critique" and not criticism.
Criticism doesn't necessarily have to be useful, hence "constructive
criticism". In my mind, however, "critique" is usually more analytical in
nature and somewhat above ordinary criticism.

Of course we don't have to be "edgy", but I don't think that stops us from
being unique. While usability is obviously the primary goal I think there's
a middle ground between "exactly like every other program" and "edgy
unuseable crap".

I'm not saying @budislavs work is bad, but I think both sides have valid
arguments and we could do with less aggression.

[budislav]

@Spekular aggression from me comes because of non respecting and "I am so smart to say this is not good without giving better solution". If you really want to help then instead of saying just this is not good than show me what is good.

Make that good thing and show me so we can make better solution together. The best option for peoples who does not like something is to to show their better solution. Maybe there is a thousands of reasons why I needed to borrow those things from Bitwig.

I'm not saying @budislavs work is bad, but I think both sides have valid
arguments and we could do with less aggression.

Sorry I don't see any solution from other side. I see peoples who playing some kind of detective and judges.

If you know some of developers who are willing to help with this code stuff, call him to participate. If you are developer you are also welcome! I would not open your code and start investigating your code logic believe me.

[musikBear]

The best option for peoples who does not like something is to to show their better solution

:+1:

[michaelgregorius]

@budislav Yes, @Wallacoloo started working on using OSC (Open Sound Control) to decouple the GUI code from the core code such that no critical real time code is called from the GUI code (see #2252). Unfortunately this effort is currently stalled due to some kind of vicious cycle: he feels uncomfortable making changes to a code base that has no unit tests but on the other hand to have unit tests the code should be decoupled. I can completely understand his position.

I have also started work to decouple the core from the GUI in some other areas but the corresponding pull requests will only make it into the code once the is a 1.2 branch or another strategy for the next release. @tresf Would it perhaps make sense to create a WIKI page for 1.2 and to list everything there that has to be done, e.g. open bugs and pull requests that would need to be integrated? Right now I have no idea how far we are from a 1.2 release.

Concerning the slow GUI updates: LMMS uses a lot of custom drawing code and I assume that some of that code is not very efficient. The labels on the mixer strips for example are painted using Painter::drawText which calculates a layout each time the method is called (see FxLine::drawFxLine). This layout calculation consumes quite some time. A more efficient solution would be to draw these labels using QPainter::drawStaticText which does not calculate the layout for each call. Instead a QStaticText instance would only have to be updated and have its layout calculated when the text changes (which is not often). There might be more places with similar problems.

@Spekular I agree with regards to the middle ground. If it wasn't like this there would be no progress.

[budislav]

@michaelgregorius everything I read is really a good progress :thumbsup:
Looks like you guys launched a rocket :rocket:
WIKI page you mentioned above is also nice idea for progress monitoring :bulb:

Concerning the slow GUI updates: LMMS uses a lot of custom drawing code and I assume that some of that code is not very efficient. The labels on the mixer strips for example are painted using Painter::drawText which calculates a layout each time the method is called (see FxLine::drawFxLine). This layout calculation consumes quite some time. A more efficient solution would be to draw these labels using QPainter::drawStaticText which does not calculate the layout for each call. Instead a QStaticText instance would only have to be updated and have its layout calculated when the text changes (which is not often). There might be more places with similar problems.

This sounds like we will have faster GUI since you know how to fix it :thumbsup:

[michaelgregorius]

This sounds like we will have faster GUI since you know how to fix it

I have issued pull request #2579 that deals with the repeated layout calculations and a performance problem related to calculating the peaks.

[StakeoutPunch]

I am not going to argue with you any more I see you don't know nothing about UI. You just come here in trying to stop some progress and that is not cool.

I don't need critique from non designers, especially not from someone who does not doing anything about this. Imagine I start to speak like that to developers what is good in their code and what is bad, like I know something about programming.

This is not a good comparison, for everyone one has eyes and can form opinions about what they see in a UI design, but not a whole lot of people can look at code and understand what they are looking at. Everyone has the right to opinion about design whether they have the skill to make something better or not. You can accept their ideas or you can ignore them, but telling someone their opinion is worthless because they are not a designer/not at the same skill level is very rude.

I agree that criticism should bring something new to the table, but sometimes the criticism itself is the substance brought.

[budislav]

@michaelgregorius :thumbsup:

@StakeoutPunch this starts to be funny. I can't go more into this.
What you would say to him on my place? Imagine yourself to spends about three months of work on something and then I (guy who didn't contribute in that problem on any way before, plus you are in that field five years and I don't know anything about that field) come to you and say "you just make exactly copy of something and look on this picture I marked all of bad things! You should be more creative! I want only original solutions!"

Is that respect for you? You will respect that opinion? What you would answer?

This is not a good comparison, for everyone one has eyes and can form opinions about what they see in a UI design, but not a whole lot of people can look at code and understand what they are looking at.

They can form opinions about what they like or don't like in particular design, but what is good and what is not good that is ridiculously.

You can accept their ideas or you can ignore them, but telling someone their opinion is worthless because they are not a designer/not at the same skill level is very rude.

Which ideas? I would like to see some ideas from him or anybody. I respect all ideas but I don't see them so I don't know why you are saying that.

There is a saying that goes: "Opinion is like an ass, everybody has it."

[softrabbit]

They can form opinions about what they like or don't like in particular design, but what is good and what is not good that is ridiculously.

Ok, here's some opinion.

I thought level meters (not saying VU, as they aren't AFAIK) having red at the top makes it easier to see which mixer channel has the hottest levels. Likewise for the solo and mute buttons, color lets you see at a glance what's going on. Do the traffic lights in your part of the world display text in the same color for "stop" and "go" or is it red and green like in most places?

I also thought different icons for different instruments were informative. But if those icons are going away, please at least use your designer superpowers to make it so that a user-set channel name remains even after loading a new preset. That doesn't seem to be the case now.

[budislav]

@softrabbit

I thought level meters (not saying VU, as they aren't AFAIK) having red at the top makes it easier to see which mixer channel has the hottest levels.

Absolutely. I didn't design full level meters to the top so you can't see this but it should go in red.

Likewise for the solo and mute buttons, color lets you see at a glance what's going on

Thanks for explanation I didn't know that!! Yes they are red and yellow when they are active.

Do the traffic lights in your part of the world display text in the same color for "stop" and "go" or is it red and green like in most places?

Yes in "my part of the world display text" buttons "stop" and "go" are in same "traffic lights" color.

like in most places

Like in LMMS

I also thought different icons for different instruments were informative.

In other DAWs I didn't saw different icons for different instruments. I saw same icons for instrument or plugin type (all vst plugins have one icon, all effects on icon,..) If I am right in Logic and FL you can set icon based on preset or sound you design not on instrument itself.

superpowers ??

You don't need to be sarcastic dude, should I say to you "* you"? *Edited @tresf
And now someone will tell me I am rude.
I just don't know how to finish with this kind of people and I don't know why does everyone starts to feel hurt?

@softrabbit did I said something bad to you, because your comment (opinion) looks like some kind of answer to me or you trying to defend someone?

[tresf]

This thread will be locked if we can't be civil.

I agree with @softrabbit, the icons for our instruments are very identifiable and something we're very proud of, if we can talk about keeping some more identity for each instrument type, hopefully we can reach a middle ground.

@budislav you're right, other DAWs don't do this, but we're ok diverging from the norm, which I think is part of the backlash you're receiving here. This is a normal part of the process, but we need to work together to make things happen, and that means dealing with some valid requests and some outrageous requests.

superpowers ??

Take it as a compliment, or with a grain of salt. @softrabbit is an asset to our team and if you read his commit and comment history, he's not one to sling mud around. :heart: :earth_asia:

[softrabbit]

did I said something bad to you, because your comment (opinion) looks like some kind of answer to me or you trying to defend someone?

Just some observations based on what info (i.e. mockups) is available. If red at the top of the meters and colors for the buttons is indeed planned, great. But TBH, what has been shown has been fairly colorless so far, so I thought that particular cat needed to be pulled out of the bag.

not _the first_ to sling mud around.

FTFY. :smiling_imp:

@budislav, I'm sorry if you took the superpower comment as negative. It was totally meant as positive, as you clearly have a lot of skill in that area.

[budislav]

@tresf if you really insist that every lmms instrument should have own icon then I think those icons must be redesigned. TBH I don't see anything special about them. Don't know how to fit them into any new design. If we develop option to change color of each track (instrument) we don't need anything else to identity instrument except maybe of one icon for lmms instrument, vst and other plugin types.

@softrabbit

what has been shown has been fairly colorless so far, so I thought that particular cat needed to be pulled out of the bag.

I agree. There is a place for more colors but we need to go smart with that. I don't like FL studio kindergarten look. He is counteract to all modern UI principles.

I'm sorry if you took the superpower comment as negative. It was totally meant as positive, as you clearly have a lot of skill in that area.

In that case I am sorry because of my reaction. Previous comments were bad for me so I thought you are in chain to slap me. :v: :heart:

[tresf]

@tresf if you really insist that every lmms instrument should have own icon then I think those icons must be redesigned. TBH I don't see anything special about them. Don't know how to fit them into any new design. If we develop option to change color of each track (instrument) we don't need anything else to identity instrument except maybe of one icon for lmms instrument, vst and other plugin types.

Well, insist is a strong word. :)

• I agree with your point, it may not be possible, given the current design
• I also agree that colorizing instruments may help fill this gap as well
• I agree distinction at least between native, vst, patch (SF2/GIG/etc) and sample instruments is critical

On the contrary, I think we'd all be interested to see what the artwork and/or colors may look like if streamlined into this single-window theme and what types of problems we'd encounter if we were to try. :+1:

[budislav]

@tresf I need to make 18 different icons for each instrument to fit size 16x16. I would like to present them in some abstract shapes because it's easier to make crisp small icon and will look modern I hope so. Also all icons would be in combination of 4/5 same colors. So this mean all instruments will got new identity. Goal is to be extremely simple

[musikBear]

Have to mention that colors are important for sight-impaired users. Current instrument-sidebar is visually a great help, and a wanted instrument can be found with one glance. I would have real difficulties with buttons like the ones in @tresf inserted image in the post above.
I have already used this sentence before:
_Design should never be weighted over function_

So imo some kind of colored icons or a customizeable /theme option is needed, if sidebars are to flat colored, like in the above image.

[DeRobyJ]

I've got several questions about a single window UI...
First: what if I want to open more than one plugin, like 5 plugins, together?
Second: dual monitor
Third: smaller screens, are we going to state "1280x720" in minimum requirements?
Fourth: right now we have a FLstudio-like ui, so those users (mostly audio production newbies) can easily switch from one another. But having a flstudio workflow in an ableton ui would prevent that without helping ableton users either.
Fifth: a lot of users would need to re-learn things, and some would probably go away, mostly newcomers from the last two years

It's cool and everything, but I don't see the need of it and it would also slow down other improvements (unless we start working on this feature after we get more human resource)

[budislav]

@DeRobyJ just to say something to you and everybody.
I am done with this.
I spent in this so much time and effort for nothing. I am not blame anyone it's all about what users want. Some of you want ugly and non user friendly UI, some of you don't want to learn new things, some of you don't want any progress in this field and you know what I can't understand that. One thing is for sure. If developers continue to listen only what users want instead off what users really need (what are good things) there will never be a progress. You can afraid of new things for forever if you think that is cool. If you love 15 years old UI workflow go ahead!

So @DeRobyJ to answer on your questions like I did to others above.

First: what if I want to open more than one plugin, like 5 plugins, together?

First you didn't understand this concept at all. Look at my comment on Aug 7, 2015 there is your answer.

Second: dual monitor

Again answer is about somewhere I made proposal for that also but In short you can set your second screen like you want. I have question for you. Dual monitor in present UI design?

Third: smaller screens, are we going to state "1280x720" in minimum requirements?

This is your the best question because you really didn't read anything above. If you open second image from the top under Latest Update you can see that picture is 1366x768 if you can't imagine this on 1280x720 then I am really sorry, I can't help you.

Fourth: right now we have a FLstudio-like ui, so those users (mostly audio production newbies) can easily switch from one another.

No they can't. LMMS is a far far from FLstudio-like ui. Only similar thing are patterns and floating windows and FL have a really big problem with that right now. Good idea I will propose new system to FL studio. That would be really funny just for fun. Question for you, why you care about FL studio users?

But having a flstudio workflow in an ableton ui would prevent that without helping ableton users either.

I do not want to insult your intelligence. But this is a freedom of speech so everyone can speak like he knows everything. Yes man you are right, thank you!! I made a big mistake.

Fifth: a lot of users would need to re-learn things, and some would probably go away, mostly newcomers from the last two years

Yes, humans learning whole life. This is UI for next 10 years and it's easier to learn it than present UI. No, no one will go away, especially newcomers.

It's cool and everything, but I don't see the need of it and it would also slow down other improvements

I am really sorry if you don't see a need for this. I would suggest you to go back in 90's and stay there. You are not ready for the future.
Question for you: What other improvements you are talking about?

Unless someone want to build new DAW, or redesign this with new standards and the best possible UI/UX workflow , I am done with this.
New Zynaddsubfx will have completely new UI and you will need to learn it but you will use it for sure because you will see it is so much easier to learn and use it then present UI.

[tresf]

@budislav When we pull this off we'll need your help.

If opinions on this are too strong or causing too much conflict, we can lock the thread to prevent overly opinionated comments.

Under the covers, this theme is more than just how the software looks, but also about how the GUI component code is written. The libraries we would hypothetically be using would improve the stability and complexity of our code.

Furthermore, focus on a centralized theme would give the software better flow, identity and consistency.

I think the user's concerns are born in merit, as are the designers concerns, but if we can't respect each other's feelings, we'll have to lock this and work on it without public comment.

I spent in this so much time and effort

We all do, it's part of the gig.

[fundamental]

@DeRobyJ

smaller screens, are we going to state "1280x720" in minimum requirements?

There certainly is some tradeoff with moving towards a design which is mostly focused on a single window, but I don't think talking about this in terms of pixels is a particularly helpful measure. Small window sizes in terms of inches or centimeters makes a lot more sense IMO given that things should be able to resize smoothly. To me the mockup is readable to about a 10.5 in diagonal size (880x510 pixels for the record) which is going to be a lot smaller than most screens that people already have. This would mean that it would be impractical to use this design on something like a smartphone sized screen, but I don't imagine that there's that may workflows which would attempt to use a DAW in those environments.

In the case of my work with the zyn UI I could imagine smaller screens getting some use (perhaps in the case where the software might be embedded in a hardware device), but even then I wouldn't expect the screen to go much smaller than a 7 inch diagonal. Beyond that point it's not a challenge of seeing the pixels, but it's difficult to input information using a harder to track cursor or a touch surface.

If you still think this would be a major issue, please take a look at the multi-display detach workflow that unfa has posed near the beginning of the thread.

[DeRobyJ]

Thanks for the replies and I'm really sorry I couldn't find what had already been discussed during the last year. I had read half of this duscussion, and I had no more time, so I didn't get to the bottom. Also I'm not a native English speaker so reading sometimes takes some time.

Now, I'm not here to stop anything of course, I was just concerned.

Why am I concerned? Because some of us (lazerblade, cubician, bearsoundz and many others) run tutorial series on youtube.
I personally spent tents of hours on a tutorial series in my native language with thousands of views.
I'm concerned because most of the episodes of these tutorial series would go to waste after this big change.

And sorry if I don't understand what I don't know, I'm not a programmer yet, but this doesn't mean that I can't take part to such an important discussion.

I now understand that making this big step will be a huge progress performance-wise, so thank you all for your hard work, I'm ok with this change now, because I've been updated on the status, which is quite hard to understand unless you spend half an hour reading.

I was surprised because I just got to know about this. Did I miss some kind of poll somewhere?

Oh, and I'm not "generally tweaking one single instrument at a time".
Simply because it happens that I need to link two knobs from two different windows together, or I need to copy some parameters from an effect that were in a instrument to one in another instrument or in a channel strip.
I happen to do these things from time to time, and I would like to be able to do it!

So, I'd like to contribute by suggesting the option to detach windows, if possible.

Last question: any chance about zynaddsubfx automations? I couldn't understand from the previous posts.

[fundamental]

@DeRobyJ I agree at this point there really should be some nice summary of the more frequently discussed tradeoffs. Traditionally I've seen long discussions like this have a basic FAQ appended to the original posting, but this issue seems to have enough different sides to it that something more flexible like a few wiki pages could make more sense.

Simply because it happens that I ...

Excellent. Workflow based critique and concerns. These are what should really be emphasized in this whole process (IMO) as they address whether the changes make something more or less usable to musicians.

any chance about zynaddsubfx automations?

This is somewhat offtopic, but from the prospective of zynaddsubfx _outside of lmms_ they work (mostly) fine in a number of spots mostly via midi learn and then later CC based control of parameters. There's going to be another release soon enough (~1 week) with cleaned up VST/LV2 support. If you're on one of the platforms supported (linux/osx) then I'd check that out when it comes out.

[tresf]

@fundamental's response came in just in time, mine wasn't as diplomatic.

On the topic of YouTube videos, if your tutorials are so highly demanded, consider joining our social media team and being part of the big picture solution.

• Cubican outright refused to join our team. He has other plans for his channel which are more personal and less pay-it-forward.
• musikBear won't get a wide-screen monitor, which is a hard-requirement. He also refuses to upgrade his OS.
• Lazerblade would be a welcome addition, we featured one of his videos on our homepage for some time. In that specific video, he stated he doesn't use LMMS all that much, so if that has changed (or even if it hasn't and he wants to be part of the team), great. :+1:

@DeRobyJ but I want to remind you of something... there are 107 subscribers to this bug tracker, so keep that in mind when you grow concerned about losing 30 minutes of your time, as starting controversy with the designer can burn right past that 30 minutes (as it already has). All of our time is worth something. :+1:

[tresf]

If you're on one of the platforms supported (linux/osx) then I'd check that out when it comes out.

Agreed, off-topic.... is this statement in regards to Zyn + LV2 + Carla perhaps? We have carla disabled on OSX currently, but since that decision was made, @falkTX created binaries for Windows and Mac here: http://kxstudio.linuxaudio.org/Applications:Carla. Perhaps we re-investigate that decision (preferably on a dedicated topic).

[fundamental]

@tresf this statement refers to plain old ZynAddSubFX i.e.https://github.com/zynaddsubfx/zynaddsubfx which as of the last release officially builds to a standalone program, a vst lib, a dssi lib, and a lv2 lib. VST and LV2 support were done by @falkTX and they're now part of the official distribution. There were some noteworthy bugs in the plugins at the last release (heh, when aren't there), but they have all been resolved to the best of my knowledge. Right now the release is waiting on fixing up the packaging of the LV2/VST libs for OSX which is done by the OSX build scripts https://github.com/zynaddsubfx/zyn-build-osx .

[tresf]

Thanks @fundamental for clarification, I had read over:

outside of lmms

:+1:

[iansannar]

Tres, I'm reconsidering. I think it wouldn't hurt to have the navigation
and usage tutorials on the official LMMS channel. I can do specifics like
mixing and sound design on mine.

As far as redoing tutorials, I planned on it anyway considering the amount
of changes that have already taken place in lmms and the quality I can now
produce. If the UI went through this overhaul, id be glad to redo the
tutorials again and again.

[tresf]

If the UI went through this overhaul, id be glad to redo the
tutorials again and again

@cubician great. This is what developers as well as designers need to hear.

[ashafq]

I really like this UI. Is it currently being implemented in a branch?

[IvanMaldonado]

@budislav There is something I don't like about the newest version of the design. You changed the knobs for horizontal sliders on the controllers and there are no faders in the mixer.
Some programs like GIMP could use these flat graphics for the controls, because they have always used controls of this kind. Every control should stay like it has always been in my opinion.

[tresf]

You changed the knobs for horizontal sliders on the controllers and there are no faders in the mixer.

Likely to save real-estate.

Every control should stay like it has always been in my opinion.

I think a better justification is that there's more control in granularity if the sliders are kept. I tend to favor the sliders too, personally, as they're quite intuitive when placed directly next to the db readout.

[softrabbit]

There is something I don't like about the newest version of the design. You changed the knobs for horizontal sliders on the controllers and there are no faders in the mixer.

Horizontal sliders, I like them. It's easy to read the level (ok, round knobs with a clear highlighted sector around them aren't as bad as traditional hardware-imitating knobs), and they're easy to layout; you can stack sliders in a sidebar and make it pretty narrow without changing the layout.

[zethorpe]

I didnt see anything in this thread about the piano roll. Has anyone redesigned it to use horizontal lines to differentiate between the white and black keys? I didnt see any discussion about the piano roll except for one image that op posted. especially since the icons for the tools in the piano roll window are horrendus

[Spekular]

Horrendous is neither specific nor kind, perhaps you ought to be less rude
and more descriptive?

[zethorpe]

well they just dont look good. they are too detailed to be an icon some of them arent consistant and there is an over use of gradients and drop shadows.

Also on a different note the thing that says "please open a pattern by double-clicking on it" would probably be better as a drop down menu showing all the current patterns.

[grejppi]

@zethorpe Are you aware that there will be a new theme and a new set of icons relatively soon?

[zethorpe]

Are you aware that there will be a new theme and a new set of icons relatively soon?

ive heard about a UI update soon. will it be using this UI design or another?

[Umcaruje]

ive heard about a UI update soon. will it be using this UI design or another?

Check out #2587

[vlad0337187]

I had seen in 30 of May 2015: https://vk.com/wall-87783789_470
Here 16 LMMS users vote "it's good".

Yes, I agree, it's very very good looking. BUT I think that it'll be great to use this color theme and theme of widgets with only change:
-remain design with subwindows in the main window as it's now to allow people choose the best appearance for them.
Because one divided window doesn't give users such freedom like it's now.

[teamblubee]

This is what LMMS looks like on my system. I support this move, if only for the HiDPI support. I am on FreeBSD and the audio tools are all pretty weaksauce over here. LMMS seems to have the best OSS support but trying to do anything useful with UI that tiny is definitely a no-go.

I am even willing to throw in some development time to get this implemented.

With a theme like this in the future people could design their own themes and that will allow LMMS to have multiple themes contributed by the community. I think that we really have to get away from fixed sized display.

[ollieperree]

Is anyone currently working on this? I'm willing to help.

[tresf]

Is anyone currently working on this? I'm willing to help.

No one is working on this. You are welcome to start, but warning it is a very large initiative. If you are not yet familiar with the codebase I strongly recommend you patch a few minor bugs to get familiar prior to tackling such a large first effort.

[ollieperree]

I strongly recommend you patch a few minor bugs to get familiar prior to tackling such a large first effort.

Right, that's what I'm planning to do in the next couple of months, then in July and August I'll hopefully be able to contribute to this project.

[michaelgregorius]

The following steps might be feasible to get this one finally going without getting entangled in the existing LMMS code base:

1. Acquire the assets from @budislav.
2. Add a new library to the CMakeLists.txt which only has dependencies to Qt. This library has no connection to LMMS and its functionality.
3. Implement the different user controls that are needed to compose @budislav's design in that library by subclassing existing Qt Widgets and adjusting their style or by implementing completely new widgets. Use @budislav's assets here and keep the library as generic and reusable as possible. Don't add LMMS specific functionality here.
4. Test the GUI components of that library by adding a new GUI prototyping executable to the CMakeLists.txt which only has a dependency to the new GUI library and Qt. This executable acts as an experimentation playground that can be compiled quickly without having to compile the full LMMS code base. At a certain point it will likely look a bit like the GTK3 widget factory in that it showcases all implemented new widgets.
5. Once most of the widgets are implemented add the new GUI library to LMMS and make the existing LMMS widgets subclass from the classes in the library. Add the LMMS specific functionality, e.g. signals and slots, here.
6. Slowly morph the existing LMMS GUI design towards @budislav's design.

This might also be something nice for an LMMS Git Project as it has several characteristics of a project:

• It must be planned well.
• Several people should collaborate on the tasks.
• It will take a longer time.
• It might succeed or fail.

One nice thing with the outlined approach is that the existing LMMS will not be affected in case the project does not make it to step 5. Because a new library and executable is used it is also possible to implement this in master without the need for a separate branch.

Unfortunately I don't have time to manage such a project but perhaps someone else wants to step into this role and use the steps described above as a first project outline.

I am interested to hear your feedback.

[vlad0337187]

I think, that there's no need in replacing with this standard design. Our new design seems very good to.
Maybe it would be better to do, what @michaelgregorius told, but don't slowly change current design to this, but leave two possibilities:

• use window-based design
• use this mono-window design

And to implement this color scheme as a variant of LMMS theme and add possibility to choose between them.

[budislav]

@michaelgregorius consider first item on the list without a hitch :)
I have all .psd files so that is not problem.

@vlad1777d

I think, that there's no need in replacing with this standard design

Can you explain me what standard design mean?

Our new design seems very good to.
Maybe it would be better to do, what @michaelgregorius told, but don't slowly change current design to this, but leave two possibilities:

• use window-based design
• use this mono-window design

And to implement this color scheme as a variant of LMMS theme and add possibility to choose between them.

This new concept is all about usability, I think it should be nice to have possibility to just load a theme and make a new one with just selecting a colours somewhere in settings but since this is not only theme but whole new concept you will need this design by default and new theme to build on top of this (editing this theme so you you can make it like old lmms). I really carefully designed all of ui elements so it is very close to original design but it have a new redesigned look. It would be very hard to make this new concept live based on old theme because you don't have this whole new concept designed in old theme. But if they make system for editing theme completely that would be nice.

Leaving possibility to have window-based design is not something I would use and I am sure that nobody would, so that would be just a wasting a time and effort. I don't see a single reason for doing that. It is a very old concept where you wasting your time with click, move, resize a window, close it, find it open it,.... Please try to explore this new concept more I believe you will find it more useful.

But they can make an option to detach this tabbed windows (like in krita) but I really don't see a point.

[tresf]

@vlad1777d, if LMMS is able to, the single-window design is going to happen. This isn't really a vote on current theme versus single-window. At our current rate, single-window is 5yrs+ out and by then we'll be ready for a new theme anyway.

The existing MDI window interface is not well received by newcomers and it's really a design element of the 90s that had it's place but in modern age computing needs to die a horrible peaceful death.

This deep hatred dislike for MDI isn't so much of an opinion as it's a measurement of effective UX/UI over 20 years of computing. The major problem with MDI interfaces is that they require a very good task launcher and keyboard shortcuts to continually bring focus to commonly used windows. A good use-case for this problem is to try to use the mixer window at the same time as the piano roll editor. The two windows don't fit in most monitors without sacrificing critical real estate of one window.

Another downside to MDI is no-docability or non-obvious docability. For example... get one critical element (e.g. the play button) and imagine it moved to the middle of the screen. This is what occurs when there's no reliable location for critical inputs. Single-window solves this by putting critical inputs in sane, predictable areas.

In theory, MDI is a nice concept because it encourages stacking which looks tremendously useful on display however in execution it usually fails because once one window falls behind it's hard to get back to the front.

For these reasons, single-window interfaces have become better options. There are still limitations and downsides which I think have all been mentioned above, but the concept is the best we have at the moment.

[vlad0337187]

@budislav , under "new design" I mean such colors in theme:



(I couldn't find images in issues, so I uploaded them here)
I like this style. I'm not sure, I want to change it to colors from this topic. But I like colors from this topic too, so, I think, would be better to add them both, for example, to .css files and add ability to change themes.

@budislav , @tresf , about single window. I agree, that current MDI system has problems. If new system would be something like is in Blender (you can move plane borders and change type of all planes (for example, one plane is Piano Roll, but you can resize it and switch it to display Song Editor) - than I like this idea.

If it would be something like fixed-length (for example, 300px) areas, that I cannot resize or change their type (to change layout) - I dislike it.

The reason for me to like approach with windows - I can resize them and move. So I can change the layout (for example, Song Editor was in the top of screen, I resized it and moved into the bottom of screen)

[tresf]

If it would be something like fixed-length [...] I dislike it.

It would be as dynamic as humanly possible.

I like [current] style [... and ...] ability to change themes.

If we keep it .css, this will be possible.

[budislav]

If new system would be something like is in Blender (you can move plane borders and change type of all planes (for example, one plane is Piano Roll, but you can resize it and switch it to display Song Editor) - than I like this idea.

No, not like blender but more easier, faster and suitable for LMMS. You can resize those tabbed windows and reorder them, move them on a second monitor, and they are automatically snapping to all edges so you don't need to worry about overlapping, resizing them ect. You can make a lot of personal layout with this system depending on your screen size.

You only can't resize width of controller rack, and height of instrument and effect rack or both of racks if you split them. They simply have fixed height or width. Now just imagine a freedom of making your own layout. And on the top you have a list of saved layouts you can switch between them so you don't need to touch anything and if you do, you can save that layout. Is that enough control for you?

[vlad0337187]

@budislav , @tresf , than all is well =)
It would be great if we could switch from this color theme to that dark, that's currently in LMMS.

[tresf]

It would be great if we could switch from this color theme to that dark, that's currently in LMMS.

@vlad1777d changing the color is always going to be possible however the mockup above would most likely be the initial target for the first release.

[budislav]

@vlad1777d Theme from this design is already "dark" (white on black), just with blue tones. I choosed that color scheme because of LMMS 1.1.3. I wanted to make something common, to look like a child of old LMMS, not to destroy him completely. It is made to be good on laptop screens with very low screen brightness and for good monitors. Contrast should not be a problem but I didn't received any feedback on this so, It is what it is.

[budislav]

I just noticed it have past two years and 33 days since I presented this to community.

[michaelgregorius]

@budislav I think we are all aware that this issue is open for quite some time now. :) However, it's no small feat to implement a completely new design. That's why I proposed to handle it as a project with a coarse plan to get it going.

I think a big factor in what's holding LMMS back is that most of the features are implemented by individual developers and that there is only so much an individual developer can do. Another thing is that even if a developer decides to implement a big feature on his/her own that there is the risk that the changes don't make it into the project and that this work is wasted then. An official project approach might also help with this because it can be seen as some form of commitment of the LMMS team / project that the big new features are really wanted.

@tresf Do you think it makes sense that @budislav commits his assets to the LMMS artwork project? This would be a feasible first step which might in turn motivate others to use the artwork to implement new widgets using it.

Another question would be whether we can use the PSD files or whether we need them in another format? Can GIMP open PSD files? Do the PSD files have some useful features that are not covered by open source equivalents and that might go missing with a conversion?

[tresf]

@tresf Do you think it makes sense that @budislav commits his assets to the LMMS artwork project?

I don't think it has a whole lot of value in lmms/artwork as a proof of concept.

This would be a feasible first step which might in turn motivate others to use the artwork to implement new widgets using it.

I'm not sure if that's true. Most of the mockup above is a style sheet, font or very small glyph (or perhaps eventually an svg). The small glyphs really don't have a home until the UI starts to take shape I think and if for some reason @budislav becomes unavailable we have several capable people that can re-create them based on the mockup.

I think the largest task here and what's sure to drive momentum is what you've already identified, and that's a commitment by the team as well as well as what I believe was mentioned previously, the start of a second UI that eradicates the MDI container.

Perhaps another approach is to start Core/UI separation first with our existing codebase, but that's less sexy so it has less marketing appeal in general.

Part of me wonders if we could take this in a brand new direction and actually start a spinoff project; something that's loosely based off of LMMS.

Hard to see the forest for the trees.

[BaraMGB]

Part of me wonders if we could take this in a brand new direction and actually start a spinoff project; something that's loosely based off of LMMS.

Do you mean a complete rewrite?

[budislav]

@michaelgregorius @tresf I am aware this is not small task but why two years just to make a new branch or fork or to start Core/UI separation? :)
I think @Wallacoloo started doing Core/UI separation?

I am not programmer and I don't know how LMMS code works but this is what I would do if I am developer like you guys.

Decide you really want this new UI. I think almost everyone from community agreed this is the the best way for LMMS future. I am not selling anything I think this is just good enough to sell itself :)
But if you think this is really good, don't ask anyone else for opinion. You are not genie from the magic lamp or goldfish, you are not here to satisfy all wishes.

You are working on something you think it is good, or you want to make it good right? Because on the end nobody will pay you to do anything. I see some conservative users who don't like new design, they also don't like new gnome, or kde, they never liked unity or anything new. You don't need to care about them. If you have a fear that nobody will use new UI you shouldn't be. If you make new UI I can bet nobody from old users would click on download button of that old version ever again.

If you think that old LMMS will fall apart then make a fork of old LMMS and make a completely new project. When I started redesigning I had just idea about how it should look, but on the beginning that was just an idea. After a half year I completed it. Zyn Fusion project lasted over one year with 4 different versions.

How much it could have been done for two years? Don't judging anyone, just asking, only curiosity :)

If you decided to do new UI in this same LMMS, I am sure you need to stop doing old design, old way, implementing new features on that way. Stop doing bug fixes and focus only on how to make this UI possible.

If you need more developers ask them on g+ community, facebook, email old developers, friend developers, ask on kde forum, here, anywhere. How many developers you need for this? If nobody are willing to contribute, not a big deal, right? Maybe it is better if one or two brains do the whole logic :)

In my case I like that. I think if someone start changing this concept he would just broke that consistency. That is the problem with present design it looks like 300 peoples worked together but everyone on his way. let's put this and this.. There are no guidelines, nothing, everyone design how ever he want, so it looks like alpha version not like it's how many years old? Design is not the thing you can just jump in.

So without guidelines you can just broke design. With this kind of design I think you can't broke it so easily because it's modular, if you just using ui controls you have, following the guidelines. It's like GUI framework for music software. Maybe you need to make this. I don't see knobs not in gtk or qt framework and I don't understand that. But I think @fundamental made this?

After I proposed this design you guys started working on new GUI theme based on this design instead doing exactly on this design. And now users like @vlad1777d want to have that new theme instead of this theme? Is there something wrong about this design? I didn't get any feedback on that, if you just said me we don't like gray and blue, can you make black and green I would say yes I can, but first can we make this.

I worked on Photoshop in that time because Krita just started implementing .psd layer styles so I thought it would be really compatible but it is not. Krita do not open .psd so good so I need to redo everything in Inkscape .svg because GIMP and Krita are not the tool for UI design. It's not hard for me, I mean I would redo everything in Inkscape but I would like to know if someone really going to start developing this?

Nobody said you have a deadline but this experiment could have started two years ago right? :)

Did anyone knows which year was the first release of LMMS? Is there are one screenshot of that release? I would like to see it :)

I just found first message on source forge developer mailing list from Tobias Doerffel from 2005-06-27 (12 years ago) there are no messages before that.

Hi everybody,
finally after 324 days of development LMMS 0.0.9 has been released! Compare to 0.0.8 it has been almost completely rewritten. The result is a quite stable, clean and powerful new LMMS, which brings a lot of new features.

Maybe it's time for one more complete rewrite. :)

[tresf]

This says it all:

finally after 324 days of development LMMS 0.0.9 has been released!

It's a lot of work. Let's not criticize or minimize the ongoing effort to get this done. For example, the theme change is hardly related to single window. They both change appearance and require new art, but that's where the similarities end. This task will start when someone has either 324 days of extra (thankless) time on their hands -- or alternately -- a very organized (lead-devel styled) rewrite approach.

[vlad0337187]

@budislav , I told about that new design, because I made several mockups for it =)

Your design I saw first time near 2 years ago, so I got used to it. I posted it in our Russian LMMS community: https://vk.com/wall-87783789_470 , that's proof that I liked it (19 people liked, 2 disliked, 17 people want this into LMMS, 4 - don't).

Why do people started to work on new instead of implementing this? I think, because making new colors is easier, than making new GUI + colors.
But we have what we have: 2 good color schemes. I don't know exactly why, but it's so.
I think, we must save what we have. Taking in mind, that tastes differ, I think, it would be better to make 2 color themes and add ability to switch between them.

If I could - I could write GUI, but I know Python\GTK\Vala\Coffeescript, not C++ and QT. Learning C++ can take near year, so I cannot do this now. QT is enough large too, so I cannot start working on it.

I think, would be better to do, what @michaelgregorius told here: https://github.com/LMMS/lmms/issues/1911#issuecomment-298107170 :
to start making core and GUI more separate. after this, can be created second GUI, which launches functions of core. It can have this looking, loaded from .css file (or something like it, if QT doesn't support .css theming).
Also we could create two types of widgets: one - for this theme, one - for black. And load them according to chosen theme. (some widgets can be copied from current theme) This will allow to have differences not only in colors, but also in shapes of UI. So we will have current theme in single window + this theme.

We need now only to wait =)

[RebeccaDeField]

@budislav I do not mean to bring this thread off topic but I could not find your email address anywhere to message you. I would like to invite you to our server on Discord at https://discordapp.com/invite/3sc5su7. This is where the design related developers on our team post UI wips and where much of the informal dev communication takes place. Would be quite nice to have you included in those conversations.

[budislav]

@RebeccaLaVie Thanks, I didn't know for that chat on Discord, I will join for sure :)

[RebeccaDeField]

I know we all want to see the Single Window Concept implemented as soon as possible, but we also must acknowledge that it may take quite some time to get there. I do believe that just because we have not yet realized the goal of eradicating the floating windows yet, that we can't put @Budislav's work to good use. I think we agreed on that particularly with the Instrument Plugins project and future projects I had planned to improve the UX can utilize many of the ideas illustrated in his mockups even with our current limitations.

I have touched base with Budislav about this and we both agree that any effort spent on integrating his work would be better spent on the layout and usability, while still keeping to the color palette we are using in the current default theme. We can think about recoloring the LMMS skin in the future, but what we have now works well. Unfortunately, we discovered that in order to use his designs in Inkscape, they will have to be recreated from scratch. I have attached a very rough mockup of the Single Window Concept made in GIMP using our current colors. We can use this as a reference to make use of his layout ideas without worrying about clashing colors, if needed.

The plan is to take this one project at a time, starting with the instrument plugins, then moving to the areas of the program that need the most help to make the LMMS more user friendly. :)

cc @Umcaruje @BaraMGB

EDIT: I do not know if this is only on my end, but the link somehow made the text of this comment garbled when posted. For some reason, taking out the link has fixed this for me. I hope anyone confused in email understands my updated message on Github now.

[musikBear]

we discovered that in order to use his designs in Inkscape, they will have to be recreated from scratch

Is that because of incompatible graphic-files?
There are covertion tools that can do (almost) everything, surely inkskape exports as BMP.. or?

[budislav]

@musikBear nothing to worry about.
There are no need for .svg's at this point, because LMMS already contains all elements I used in mockup like knobs and buttons.. They will use same css styles from Noir theme so there is no need for designing or changing anything in Inkscape. Everything will be drawn from software this is one of main feature of my design so UI will be ready for retina one day.
They just need to use measure tool in Gimp or any plugin for browser which can do that :)

[ghost]

This looks so good! I

[NETMANSKY]

@budislav your job is great! I don't understand why developers stubborns. I wanna this UI. New UI now!!!

[RebeccaDeField]

@netman2k8 I pulled some comments about what our developers think of this concept from this thread.

For your (awesome!) LMMS-UI-Concept I fear this requires a complete rewrite of LMMS's GUI.

Very interested to know the possibility of this.

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!

What type of overhaul are we looking at here if we were to adopt this new UI?

To do this proper, we probably would be best splitting this initiative into some higher level components and go from there.

If LMMS is able to, the single-window design is going to happen. This isn't really a vote on current theme versus single-window. At our current rate, single-window is 5yrs+ out and by then we'll be ready for a new theme anyway.

None of the developers are actually apposed to @budislav's work. We are a very small team, without the resources to implement the single window mockup at this time. The complexity of the task if we are to even have anyone join our team with the skills or time needed to pull this off has very little to do with stubbornness.

[NETMANSKY]

@RebeccaLaVie I read these comments early. I'm not coder and disigner but soundproducer. And I can not help you directly but I want to do. I love LMMS, but as an end user I had to move to a commercial DAW that is developed by only two people! And yet they do not limit their DAW at the end of the trial period, and the price is only 60$. Won't mention the name here, but it is one of the most quoted DAW. It has everything, but I want to see it in LMMS: VST stability, usability, openness to communicate with other DAW. Only two guys made it. And You write about a small team and lack of resources. That's no reason not to make a good product.
But in my opinion may be it should to change a conception? May be need to try gather up some money on kickstarter or another place if you have no resources? @unfa offered money but I found no answer for this. Your slogan - Made by musicians, for musicians, in my opinion, mismatch reality. Your forum thread -Suggestions: Got a great idea for the future of LMMS? almost unrequited. I know my posts:
https://lmms.io/forum/viewtopic.php?f=15&t=25821#p47118
https://lmms.io/forum/viewtopic.php?f=15&t=25821#p47128
will not requited! I fear I will never see it in LMMS. I will never see @budislav GUI...

[tresf]

Only two guys made it. And You write about a small team and lack of resources. That's no reason not to make a good product.

Stop this rubbish now. Get this conversation off of our tracker. If you want endless discussion, go to Discord. If it continues, we'll lock the thread.

[NETMANSKY]

@tresf I'm so sorry that my opinion hurt and angered you. So sorry...
@budislav Брат. искренне тебе сочувствую, но ты сделал отличный прорыв в GUI этой программы! Но это же Европа, что они еще могут... У них свои понятия.

[michaelgregorius]

Won't mention the name here, but it is one of the most quoted DAW. It has everything, but I want to see it in LMMS: VST stability, usability, openness to communicate with other DAW. Only two guys made it. And You write about a small team and lack of resources. That's no reason not to make a good product.

I think it's no problem to mention that it's REAPER. Yes, it is produced by only a handful of people. One of them is Justin Frankel who became a multi millionaire from selling Winamp to AOL and who likely has lots of free time at hand. They are also in a position where they can develop their product as full time jobs (combined with a lot of passion).

This is quite a difference to having a software developed by a handful of people who do it in their spare time over the internet with no real project management tool (but also with a lot of passion). All these points make it hard to focus on specific features or have a real focus at all. However, I have already written about most of the problems that I see in another comment in this thread and don't want to repeat myself.

[tresf]

@netman2k8, we want to channel your interest and enthusiasm, this just isn't a good place for it, I'm sorry. The developers hang out on Discord and this type of conversation is permitted in #general and #programming (please not #devtalk). Let's continue there. Then you can voice your opinion and get proper feedback without the risk of bulking up our GitHub tracker. For discussion around a Kickstarter campaign: #2745.

[winniehell]

I really love the design suggested here and understand that it's a lot of work, so I would like to help.

I can imagine that the following change in concept would be a first iteration into the right direction:

• Make all windows (song editor, beat editor, piano roll, ...) always full screen in the main window.
• Allow to detach each of them in a separate resizable window.

That is each window has one the following states:

• visible in main window (like this)
• visible as separate window (like this)

• hidden

  The following states would be removed:

• non-fullscreen in main window (like this) — replaced by detached window state

• minimized in main window (like this)
  — unnecessary state because we have "hidden" already

Does this suggestion make sense?

---

/cc @blinry because you mentioned interest in this, too :smiley:

[winniehell]

To explain a bit the reasoning behind my suggestion:

I don't think implementing this new design all at once is a good idea because it does not only change how things look but also changes several workflows. In my experience it helps to break down such a big task in small bits that can be released individually. That way the maintenance cost for the fork or feature branch is reduced and also user see small improvements earlier.

Most of the suggestion in my previous comment (https://github.com/LMMS/lmms/issues/1911#issuecomment-520149997) is actually to remove existing functionality in the UI. My hope is that this does not only improve user experience but also code complexity (without having looked at the code at all). The only part which requires new functionality being added are the detached windows. I'm happy to make that a separate issue in case it needs further discussion.

I'm a developer and have worked with C++ and Qt in the past, so I'm willing to give implementing my suggestion a try.

[NETMANSKY]

@winniehell As you know @budislav offered a new one-windowed design of LMMS. It was absolutely revolutionary idea in that time. But community rejected him... I still looking his design and crying. Maybe yet is not late? Is not too late?..
In my opinion:

• Song editor must be main window always. And transport panel must be general for each module, react on Space button and must be moved into top near sinusoidal visual output. There is too much of empty space.
• Bars in BB editor must be numbered.

I'll risk to offer to re-look @budislav idea as main direction to development of 1.3 version.

[tresf]

@winniehell I believe your argument is, "lets cripple change the interface now to prepare the users for the inevitable". I'm not sure I agree (I'm only one opinion, so take it with a grain of salt).

• The codebase suffers from a slow adoption of change. We will be improving this now that stable-1.2 is released, we plan to start releasing nightly builds of our master branch. This means that something like removing "minimize" could be a 1-year or 2-year change. It's like removing the ice from an ice-chest a year before it's replaced with a refrigerator.
• The single-window may have to live as a toggle-able interface. MDI layout needs to be decoupled from classes and that will most likely happen by treating the Qt widgets as generic, embeddable objects that can resize to a container. This widget rewrite effort (in my opinion) is what's going to really make this change something we can ease into.
• Lastly -- and this part is going to be a tug-of-war -- is bad code. There are many areas where core touches UI and UI touches core. This lack of separation is going to be a sticking point with PRs and is likely to be a lot of work as each PR will break other PRs due to merge conflicts and a lot of refactoring is going to happen.

So although I appreciate the top-down design, I don't think removing a minimizing button is going to help the effort.

I'll risk to offer to re-look @budislav idea as main direction to development of 1.3 version.

Perhaps when we get away from conceptual talk. @budislav's interface design is pretty clear to me. @winniehell is trying to help plan these changes, not necessarily dispute design.

I'm a developer and have worked with C++ and Qt in the past, so I'm willing to give implementing my suggestion a try.

👍 👍

[winniehell]

The only part which requires new functionality being added are the detached windows.

It looks like this is already being worked on in https://github.com/LMMS/lmms/pull/3532. Sorry for the noise! :see_no_evil:

[tresf]

@winniehell here's what I'm talking about in regards to responsive layout: https://github.com/LMMS/lmms/pull/2068

This is an attempt by @michaelgregorius to make all of our LADSPA plugins "just fit" inside a container. I feel we first need to move all UI components into responsive containers in order for single-window to be viable.

[winniehell]

I believe your argument is, "lets cripple change the interface now to prepare the users for the inevitable".

@tresf No, my argument is "let's not change it all at once". :smiley: Given that from what I can tell shipping new things takes a while in the LMMS project (just to be clear: no blame here!), I would advocate against making the UI worse as a temporary state because "temporary" can be a while.

Of course "worse UI" is subjective in many cases. :sweat_smile:

This means that something like removing "minimize" could be a 1-year or 2-year change.

Thank you for this insight! It seemed like a small change to me but like I said earlier I didn't look at the code yet.

The single-window may have to live as a toggle-able interface.

This sounds like a good idea to me even if the MDI layout gets removed in the future. :+1: I'd like to see it as some sort of feature flag. Whenever there are bugs in the single-window approach, a user can still switch to the old interface. I would also suggest to postpone the discussion if the single-window approach becomes the default or the only interface to that point in time where we are confident that it is usable.

Lastly -- and this part is going to be a tug-of-war -- is bad code.

I'm not discouraged by this yet. I had to deal with bad code much more often than with nice code in my career. :wink:

---

I offered my help in https://github.com/LMMS/lmms/pull/3532 and https://github.com/LMMS/lmms/pull/2068 because they seem to be the next steps necessary here.

[winniehell]

The following states would be removed:
[...]

• minimized in main window (like this)
  — unnecessary state because we have "hidden" already

This has already been done in https://github.com/LMMS/lmms/pull/2983 and shipped with 1.2 but I didn't notice because I was still on 1.1. Sorry! :see_no_evil:

[tresf]

already been done in #2983

I had forgotten as well. My apologies. :D

[fpesari]

@tresf No, my argument is "let's not change it all at once". smiley Given that from what I can tell shipping new things takes a while in the LMMS project (just to be clear: no blame here!), I would advocate against making the UI worse as a temporary state because "temporary" can be a while.

I understand, but this issue has been around for more than 4 years. That's a lot of time.

I've been around free software for a while, and I remember that for many, many years people complained about the fact that GIMP was not single-window. When the single-window mode was released, the complaints mostly stopped but by shortly after that, many people who had been frustrated with it for years helped Krita take part of GIMP's userbase, and Krita is now the graphics editor I hear users recommend the most to newcomers (even if has a different aim than GIMP and GIMP is actually more powerful for image processing).

Which is a good thing, in my opinion, but that's not the point - if LMMS wants to keep its status or become a DAW ready for professional use, this change needs to be made. Multi-window is simply not a common paradigm outside of GNU/Linux, and a more modern interface like OP's attracts users to LMMS.

[winniehell]

@fpesari Sorry, my comment wasn't clear!

I definitely agree that we¹ want a single-window mode. However I also get that this is a big refactoring. So far I have never seen a refactoring of that scale being successful if done all at once.

¹ by "we" I mean the users of LMMS, including myself, and also potential contributors, including myself

[Lathigos]

Hey all! What is the status of this project? If nobody is currently working on implementing this great design, I would love to help. I have got plenty of experience programming in C++, as well as a decent amount of experience with Qt5.

Since doing everything at once is indeed a very large task, I'm eager to tackle it section-by-section. I would like to start to implement the toolbar (containing tempo and such) as designed above. Having looked at the code, it seems like it's a nicely bounded beginner project that won't break the usability of the program. Currently it's implemented inside SongEditor.cpp, but I would like to create a separate widget for it with the newly designed layout. This should increase modularity and help us move to a single-window design. Is that alright?

[michaelgregorius]

@Lathigos, I don't really know if there's a redesign project going on as I am not the most active member here. :smile: I am also not on LMMS' Discord channel where such things might be discussed. However, in general I agree that it would be a good idea to start on something that's rather contained like the time display/tempo/BPM toolbar.

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?

I also tried my hands on the time display in #5097 which more or less became superseded by the changes in #5118.

[Lathigos]

@michaelgregorius Great! Thanks for the heads-up, and thanks for pointing me towards those pull requests. I'm not sure if I'll be able to use them, though :smile: — I have already started working yesterday, so I've managed to separate the code from SongEditor.cpp into a separate widget that now controls all of the toolbar's items (the PRs you referenced would therefore unfortunately likely be incompatible with my implementation). I've also reimplemented the min/sec/msec, tempo and time sig widgets, as well as added a new sound volume visualizer widget. It currently looks something like this.

It's still a bit rough, of course, but the main things are there. I'll still need to work on the sliders a little bit and fix a bug with the mouse-drag behaviour of the spinboxes. The gradient of the background I've added to keep it consistent with the rest of the UI for now, but that can easily be changed using the CSS file.

Still a question, is this thread the right place for this kind of talk? Or should I open a new issue purely for the toolbar?

[Umcaruje]

I've also reimplemented the min/sec/msec, tempo and time sig widgets, as well as added a new sound volume visualizer widget. It currently looks something like this.

@Lathigos loove how this looks. My main issue is the sliders though. They are a tad too long , and also the fader knobs aren't pixel perfect. I could make you some pixel perfect assets, I'll just need the size in pixels though.

Still a question, is this thread the right place for this kind of talk? Or should I open a new issue purely for the toolbar?

I think you could just open a PR with the proposal once you get all your code working.

[Lathigos]

@Umcaruje Thanks! And yes, I agree entirely about those sliders! :stuck_out_tongue: They still need a lot of work. I was planning on making a pixel-perfect fader knob asset for it myself, but if you have a very specific one in mind, I'd love to see it! I don't really care what size you use. Currently it's 14x14 px, but I think I'll make it a little thinner (8x14 px or something).

On a general note, I'm still not quite sure about whether to use sliders or the smaller green spinboxes as designed by @budislav. I feel like sliders are more easy-to-use controls for the volume setting. On the other hand, for the pitch setting it might be better to use a spinbox. I'd love to hear all your opinions on that.

When it comes to the slider _length_, interesting point! I am inclined to agree from a visual perspective, but I also feel like having the sliders smaller could make it harder to control as well. (Especially the pitch slider, where each semitone step is currently about five pixels apart). I'll try to find some sweet spot. What slider length did you have in mind? Or would it be better to not use sliders whatsoever and go for small green text instead?

Another idea is to use a slider for the volume and a spinbox for the pitch, but I don't see how that'll look visually appealing.

[RoxasKH]

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

[winniehell]

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 (https://github.com/LMMS/lmms/pull/5125, https://github.com/LMMS/lmms/pull/5148). Unfortunately I didn't have time to continue that recently.

[Lathigos]

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

@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?

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]

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

[RebeccaDeField]

@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 :100: and I think any other fine details can be finalized with the PR

[mxmilkiib]

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

[Lathigos]

@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]

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]

@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]

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]

@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 :smile:).

@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 :smiley:! 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]

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]

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]

@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]

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]

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]

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

[RoxasKH]

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]

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]

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

[Krvstal]

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

[qnebra]

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]

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]

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. :+1:

[Spekular]

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.