New GUI concept

[kybos]

Hi guys,

I hope you are doing well, it's been very quiet here recently ;-).
I've been working on the new GUI concept, and have some results now.
I investigated a lot, and I am still not convinced that a pure docking concept is the right way - our graphical editors are not really suitable for docks, they are full windows in their own right, with a lot of editor-specific tools/menus. For them Florian's basic concept is superior.

So my solution is a kind of mix of both MDI and docks, partly reusing Florian's functionality. But I discarded the outdated classic MDI in favour of more state-of-the-art tabbed MDI, and implemented all list based editors as docks. The arranger as a central window is fixed and can't be closed (people complained in tickets about it "disappearing").

I think one big problem with the old concept was that, although technically pretty progressive, it was difficult to understand for the user, also due to the terminology - subwindows, top level windows, references to Cakewalk or Borland as their software was 20 years ago... I tried to avoid that and make it as simple as possible. There was also a bad memory leak, the MDI subwindows were never properly destroyed (you can partly see it in the current Cakewalk mode - just minimize a window - not the Arranger, but one of the other editors - and restore it: the content disappears, but the subwindow remains).

There are still issues of course, the state/geometry saving of the docks is apparently buggy in Qt, the handling of keyboard shortcuts is tricky, because the docks are in the global scope so conflicts arise. Anyway, I will prepare a pull request so you can check it out.

EDIT:
This is how the settings look, I hope this is clear and understandable for everybody ;-):

[terminator356]

Hey that's really cool! You've put a lot of work into this. I will check it out later this weekend.

Still here! Swamped with work. But I too have some really intense sweeping changes coming.
I will prepare a PR because it is bound to cause conflicts.

First, I fixed the Settings 'midi division' (ticks per quarter note) problem that I mentioned to a forum user.
MusE was not behaving correctly when the setting is on anything other than 384.
It was because all the 'snap' coding was using hard-coded tick tables based solely on 384 tpq.
The tables are now dynamic, and when the division setting is high, say 12288 tpq, there are
now more snap choices in the now-dynamic snap combo boxes. This will help with high-resolution
editing and importing from the kind of high-res midi files the forum user was attempting to import.
This was sweeping in its scope. There were many other things that needed changes.
Midi division is such a fundamental timing and graphics element of the whole app.
[Edit] At 12288 tpq, the resolution rivals that of single-audio-frame resolution editing !

Second, I made sweeping changes to all those forward references seen in all our header files
that we so casually use. I cleaned most of it up, and compilation should be smoother for
folks that complained about build race conditions with -j settings.
At first I tried to completely eliminate ALL forward references and replace them with proper #includes.
Oops! No, there are very many circular dependencies in MusE that completely broke when I did that.
So I reversed course and carefully re-worked all the forward references.
My solution involves something I've not seen talked about: For items that are forward referenced,
I placed corresponding #includes at the bottom of header files, so that all the cpp files wishing
to include some header do not have to also know about or include all the other headers that are
required to make that header file work.
My fingers are soooo sore from all of this! Tired from intense late-night editing...

[spamatica]

Hola! Yeah, still here! Actually I'm going back to school on Monday 😮. Oh my, at my age? Anyway, I need to get back into muse development again.. As per usual I HAVE been using muse quite a bit (even Tim's time stretching, with good result!) but no coding for too long. Screenshot looks cool! Though it must be said, I'm very conservative in the ways I like UIs, current state works for me. ;) But I'm sure I can realize the benefits of this design, trying it out. In the end I'm (as I've no doubt said before) usually of the philosophy that the one who writes the code decides. /Robert Den lör 22 aug. 2020 19:36Tim <[email protected]> skrev:

…

Hey that's really cool! You've put a lot of work into this. I will check it out later this weekend. Still here! Swamped with work. But I too have some really intense sweeping changes coming. I will prepare a PR because it is bound to cause conflicts. First, I fixed the Settings 'midi division' (ticks per quarter note) problem that I mentioned to a forum user. MusE was not behaving correctly when the setting is on anything other than 384. It was because all the 'snap' coding was using hard-coded tick tables based solely on 384 tpq. The tables are now dynamic, and when the division setting is high, say 12288 tpq, there are now more snap choices in the now-dynamic snap combo boxes. This will help with high-resolution editing and importing from the kind of high-res midi files the forum user was attempting to import. This was sweeping in its scope. There were many other things that needed changes. Midi division is such a fundamental timing and graphics element of the whole app. Second, I made sweeping changes to all those forward references seen in all our header files that we so casually use. I cleaned most of it up, and compilation should be smoother for folks that complained about build race conditions with -j settings. At first I tried to completely eliminate ALL forward references and replace them with proper #includes. Oops! No, there are very *many* circular dependencies in MusE that completely broke when I did that. So I reversed course and carefully re-worked all the forward references. My solution involves something I've not seen talked about: For items that are forward referenced, I placed corresponding #includes at the *bottom* of header files, so that all the cpp files wishing to include some header *do not* have to also know about or include all the other headers that are required to make that header file work. My fingers are soooo sore from all of this! Tired from intense late-night editing... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/orgs/muse-sequencer/teams/musedevteam/discussions/54/comments/1>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCFANZONJTZPQFV6X33F6DSB762TANCNFSM4QIFX7DQ> .

[terminator356]

My solution involves something I've not seen talked about: For items that are forward referenced,
I placed corresponding #includes at the bottom of header files, so that all the cpp files wishing
to include some header do not have to also know about or include all the other headers that are
required to make that header file work.

Scratch that. After brushing up on forward declarations, it turns out it is recommended
to put the #include line in the corresponding .cpp file, or some other source file.
This is what I have originally done all along, and it turns out it was apparently correct.
Apart from solving problems, it also speeds up compilation time, which was my goal
when I started putting all those forwards in there after Orcan removed all the
pre-compiled header stuff. I believed it would help keep the compilation time down
in the absence of pre-compiled headers. But I don't know much about them or how we
would use them here or how to tell cmake to use them.

Ah well. Benefits of all this work so far:
Stuff that shouldn't be somewhere got removed or moved into more 'proper' places.
Many circular dependencies that could be broken, were.
Many headers and source files are very 'clean' of included cruft now.

Stay tooned...

[terminator356]

@spamatica Don't let the other children bother you ;-)
You may have mentioned it before, but what will you study?
I could use some brush-ups and some degrees in a few things!

[spamatica]

Haha, we will see who prevails!
But, yeah, I've been thinking about doing something different for some time, it's been rather undecided what I would do though. Applying for different things earlier this year I got into an art school that is nearby so that is what I will do the coming year. Quite a break from my previous life, that's for sure. :)

[terminator356]

@kybos Built, tested OK, OpenSuse Tumbleweed.
(Actually, my first attempt at compiling, I chose Release mode and the compilation soon hit...
Drum roll please: A circular dependency! Yeah, the very thing I'm fixing. Ironic.
I'm sure you've seen it, where some file attempts to reference one of the ui files not located
in components, before it has even been built. Yeah, that's the kind thing I'm fixing.)

So I like this modern concept.
That being a fairly 'big' app, it may be best used in 'container' mode (ie. MDI or this docking mode),
floating windows are fine but they can be on top of other windows, which can be a hassle to
move things around they way you want.
That the Master List or Marker View opens beside another window is a very nice touch!
They are like 'companion' windows or simulated extra tabs.
If you can get the Event List to do that would be cool (but I can see that it might need special work -
there can be multiple Event Lists open).

But speaking of Event List and Master List and Marker View, there seems to be some wonky behaviour,
I see that more than one window can have tabs, but after a clicking around on a few of the 'main' tabs
(say Arranger), that window with the extra tabs seems to change, the tabs are gone I think.
Not sure how to describe or recreate it... Testing...

Now of course I am obliged to protest "What about Mac mode -
Florian's original space-saving floating window mode, where toolbars are minimal ".
He had a point, that in any open floating window there tends to be too much toolbar stuff.
However, as I mentioned above if we accept that the app might be best run in a 'container' mode,
your hybrid system may be the best thing for it.
Still... Some folks like floating windows. Any ideas how we might cure this - what could possibly
replicate Florian's brilliant Mac mode?

Cheers.
Tim.

[spamatica]

@kybos I tried your pull request, I'm digging it! Was scratching my head how to get it to show the midi editors but then I saw you added info above about it.
Not sure it's new but I see it's possible to rearrange the info in the trackInfo now too, really cool and useful.

I see it's possible to ctrl-tab between the different tabs, looks very usable.
I see the markers and mastertrack windows are global. Hmm, that seems impractical, but we'll figure that out.

I see clicking on a midi-part that is already open, opens a new one. That should probably just pop up the already open midi editor (I know we support multiple windows now, but why, I'm not sure)

Btw, just remembered, incase it's been lost in the noise. The paint issue with the new style on Ubuntu/Kubuntu for the trackInfo is still there.

[spamatica]

Another thing, which I think was added before the pull request, the new piano roll. Lovely! As I recall it wasn't a bitmap anymore? Does that mean that we can change it so the keys/note lanes can have arbitrary hights?

[terminator356]

@spamatica I suppose often school is not only about studying but also social thing.

[terminator356]

@spamatica

I see the markers and mastertrack windows are global. Hmm, that seems impractical, but we'll figure that out.

But there is only one global instance of those anyway, which is why i said it looks smart
when it opens beside another window. If the Event List could do that would be cool...

[terminator356]

@spamatica

Btw, just remembered, incase it's been lost in the noise. The paint issue with the new style on Ubuntu/Kubuntu for the trackInfo is still there.

If you mean that 'flashing' half track list inside the arranger canvas, yeah I'm seeing that too.
I first reported that some months ago right after the track list splitter was added.

@kybos I see that multiple part opening with Event List doesn't seem to work?
Pressing Alt Left/Right does not switch Event List window to the other parts?
[ Edit ] Oops, sorry Event List never supported that.

[spamatica]

@spamatica

I see the markers and mastertrack windows are global. Hmm, that seems impractical, but we'll figure that out.

But there is only one global instance of those anyway, which is why i said it looks smart
when it opens beside another window. If the Event List could do that would be cool...

Yeah, I wasn't very clear. They are global and it looks cool to place them in a pane like that. I've seen it in other programs and like it.
I do however generally not like when things take space from the arranger, I usually run MusE on a laptop which doesn't have the biggest screen, so it would be good if this 'pane' had a shortcut for toggling if it is visible. Or some other solution.

[kybos]

Thanks for your feedback, guys. I will try to comment tomorrow. I’m on vacation this week and the next, so there’s not much time left 😊.

…

On 24. Aug 2020, at 10:28, spamatica ***@***.***> wrote:  @spamatica I see the markers and mastertrack windows are global. Hmm, that seems impractical, but we'll figure that out. But there is only one global instance of those anyway, which is why i said it looks smart when it opens beside another window. If the Event List could do that would be cool... Yeah, I wasn't very clear. They are global and it looks cool to place them in a pane like that. I've seen it in other programs and like it. I do however generally not like when things take space from the arranger, I usually run MusE on a laptop which doesn't have the biggest screen, so it would be good if this 'pane' had a shortcut for toggling if it is visible. Or some other solution. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[kybos]

The basic idea:

1. One monitor setup: Default, everything in one main window/container, tabbed and/or docked.
2. Multi-monitor setup: Set all/some of the graphical editors to open in separate top windows, so they can be moved to another monitor (this is even possible for the docks). This can be pre-set in the settings, or you can do it dynamically for each editor window - use Display menu or just press F4 to toggle between tabbed/floating mode. Here I think it makes sense to have all the toolbars/menus in the editor, so you don't have to jump between monitors.

Technically they are two different implementations:

1. The graphical editors tabbed/top level: This is partly our own implementation, a lot of the original code reused/simplified/corrected, but instead of the classic MDI I am using the (relatively new) tabbed MDI mode (provided by Qt).
2. The docks (used for the list based editors): This is 100% provided by Qt. Simple and nice, but still a little bit buggy and not as flexible as one would wish, but state-of-the-art and used in most current programs.

And there again are 2 kinds of instancing:

1. Toggle one instance, like Markers/Cliplist.
2. Multiple instances, like all the rest. I don't understand why things like Master track should need multiple instance, or even the midi editors should have more than one instance per track, but this how was (explicitly) implemented, so I did not want to change it, not knowing why it's so.

Toggling the docks:
I don't think there is a function in Qt to just close all the docks (and possible recreate them all). You must toggle/close them one by one. But probably something like that could be implemented.

"Mac" mode:
I don't see a sensible use case for that (as also explained above), and it's quite flawed IMO. E.g. you never know if the menu displayed in your main window belongs to the floating window or the main window (focus not always clearly visible) etc.

"Flashing" of the mixer strip:
I thought that had been solved and confirmed, sorry. I can't see it in any of my systems/VMs. Will have to investigate that further.

[terminator356]

I don't understand why things like Master track should need multiple instance,

Master, by it's name, will never have more than one instance, there is only one master track.
(By the way, the term originates from type 1 - multitrack - midi files, which reserve the very first track
in the file for 'timing' messages and no notes, ie. a 'master timing' track This is something I had to
consider and fix in my last commits - the first track should not be shown to the user, we extract all
the messages anyway and put them into our tempo/sig/key lists, but we were still showing a blank track.)

or even the midi editors should have more than one instance per track

Careful, that's instances per part, where sometimes it is desirable to have more than one editor
open on the same very long part for say, easy copy and paste operations.
It could be argued why not do the same for the master graphic editor, but nah, it doesn't really need it.

@spamatica Whaddya think R.J. Shall we go with this?
We would need to get this merged in first before I can push my own big update. It's a whopper.

Thanks guys!
Tim.

[terminator356]

Hi. Soon my fixes might be complete enough to commit.
That should be done after this PR, otherwise I believe this PR will likely be really messed up.

I've no real objections to this PR, other than to mourn the passing of MacBorland mode,
which I never used anyway, but at least one user said they did (I think maybe that was you?).
At least the windows can be floating, which would be foolish not to have.
There are important bug fixes in there. And we know the interface will please users of simpler
desktops since you've tested it on Mint. I trust you've put a lot of thought into it.
(I was surprised to see What's This is not on Mint's title bar. I've put a lot of detailed useful info
into those, I had no idea many people don't even know they are there. It means we must manually
add a What's This button to our window toolbars, as seen in a few of them already.)

I'm pleased with all my fixes and changes.
Snap now works correctly regardless of midi division, and has more choices at higher divisions.

So I've done some neat things here.
When global midi division (ticks per quarter note) changes, all editor horizontal scroll/mag bars
automatically adjust for a reasonable range.
The range of divisions is 48 - 12288, that's quite a huge range, and without dynamic
adjustment of the mag bar ranges a static range was not adequate.
So now for example when mag is at minimum, regardless of division it always shows
consistently the same number of bars total. It was horrible before, range was way out of whack.

Another neat thing I did was, you know that space just before bar # 1 in the Arranger and Midi Editors?
Currently when you zoom, that space shrinks or expands. At extreme zoom in, especially
at high division values, you can't even see bar # 1 yet! At division = 12288 bar # 1 is waaay to the right.
So now that space is fixed width! Regardless of zoom or division, that space now has consistent width.
It was relatively easy, some rewriting of the stuff in view.cpp regarding xorg/yorg (the x/y view origins).

I also added this space to the Wave Editor. I am happy that it now clearly delineates the end of the
background from the start of a part, it was not quite clear to users before that they were even
looking at a 'part'. I'd like to change a few dimensions and things in there to make it clearer what
users are really looking at - wave events inside of wave parts inside of a wave track.

This space before bar # 1 being in all the editors is also generally helpful to clearly show the
red, blue and green lines and complete 'flags' at the top.

Cheers.

[kybos]

Sounds good to me. The fixed space before bar 1 is perfect (I don't understand how some DAWs can do completely without this space, it makes bar 1 practically unusable).

Yes, we should merge this PR before other actions. I will be back home on Sunday this week, so if there are problems or substantial complaints from users, I will be ready. If there are really convincing reasons for the "Mac mode" even in the new GUI concept, I am prepared to reinstate it (I myself never used it either, I personally don't like that kind of UI).

Later I would add a function to show/hide all open docks, like Robert suggested, and also change the master track editors from the current multi instance to single instance toggle.

Cheers
kybos

[kybos]

Another thing, which I think was added before the pull request, the new piano roll. Lovely! As I recall it wasn't a bitmap anymore? Does that mean that we can change it so the keys/note lanes can have arbitrary hights?

Yes, the piano is now vector-drawn, no bitmaps.
In theory the keys can have arbitrary heights, but in practice the piano is bound to the view class and zoomed/scaled by it (if I remember right). I would certainly prefer a finer granularity for the zoom too, not sure if it's possible with the current implementation. Some of the extreme zoom levels we have now make little sense IMO, and the default zoom level is a tiny bit too high for my taste.

[terminator356]

Pushed my fixes. Will do ChangeLog later.
Still todo some things, possible movement around of a few things, still toying...
Some unrelated crashes/bugs found along the way, to do.
(For example building Release mode fails on LV2 here.)

Apologies if it makes things difficult (for my branches too).
These two major changes were tough enough to merge together, but that EOL screw-up made it worse.

---

Here are some notes of mine, the ones marked OK are done, keep in mind
the whole rasterizer and snap system has been rebuilt, so tests were needed,
go ahead, try midi division = 12288, observe the new snap box entries.

OK. Check Robert's SHRT_SET_QUANT_OFF addition in keyPressEvent() in pianoroll and drumedit.

OK. Check Robert's QUANT shortcuts addition in keyPressEvent() in arranger.

Fix Wave Editor grid raster lines not drawn properly (but snap is actually OK).

Fix PianoRoll: Notes can be drawn to left of bar # 1 ! Pre-existing bug.

Fix CtrlCanvas: Marker lines are black not green. Actually, they are not drawn at all. Pre-existing bug.

OK. Settle on an x origin for the canvases.
OK. Move the overlay text further into the canvas, after the origin.

OK. Midi Division: Create new song tag midiDivision, save the current midi division to it.
and
TODO: Scale songs loaded with a different division (just like midi importing, just like audio sample rates) !!

!!! Midi Division: Scale an existing song when Midi Division changes.

OK. Remove never-used GUI Division !

Check midi editor Plugins menu: All of them seem to destroy controllers ! Pre-existing bug.

Remove LV2 makepath, Zita, experimental cmake warnings. Pre-existing bug.

Fix Release mode: Linker unresolved LV2 stuff (link with core?). Pre-existing bug.

Fix annoying crash in dummy audio mode when (re-)loading another song - heartbeat starts too soon,
or something wasn't deleted between loads? Pre-existing bug.

[kybos]

I tried the midi division, looks good.
There is a small UI issue with the cursor position display in the toolbar when division is set to a higher value like 12288 (e.g. in pianoroll). The number of decimals in the position output changes permanently between 3 and 5, so the box width is changing and the UI elements to the right of it jump with it. The fixed number of decimals in the position output should probably reflect the division value precision.

[terminator356]

Yup. I noticed that. Rather annoying. Will try to fix at some point...

[kybos]

@spamatica

I do however generally not like when things take space from the arranger, I usually run MusE on a laptop which doesn't have the biggest screen, so it would be good if this 'pane' had a shortcut for toggling if it is visible. Or some other solution.

Now there is a menu entry (View->Show Docks) and a shortcut (F7) to show/hide all visible dock windows.