Issues with BB Editor on project load

[badosu]

So, the BB Editor simply disappears after loading a different project:

You should be able to reproduce this by simply loading a project that has as many BB Tracks as enough to overflow the BB window vertically, something like 10 tracks should be enough.

You can use this project as a reference: Sidechain. Load the project and click on the BB Editor button to show it. Notice how the BB Editor does not show anything inside the container, and you can't add or edit tracks.

[tresf]

Recent changes are here.

https://github.com/LMMS/lmms/commits/master/src/gui/editors/SongEditor.cpp

P.S. @lukas-w is already looking into this.

[romabysen]

I have the same problem except I can't get the Beat+Bassline editor window working, no matter how much a click on it or resize it.

[badosu]

@romabysen Even after clicking play?

[romabysen]

Oh wait, I do but only after I have loaded a few songs. After making a new project and then load a song it's back to not working and then I load a few songs and I can get it working by resizing the window.

Edit: it seems a bit random, sometimes I can get it working after loading one song, sometimes I need to load two or more.

[musikBear]

is this graphic glitch on all platforms -? Never saw it on win 32 (?)
However sometimes some of the gui sliders are 'obscured' (1.1)
'windowing' and back to full-screen fix it, but theee are of the type i like to call 'glitch' or bug2, annoying, but not critical

[badosu]

@musikBear @romabysen This was introduced recently and should not be present on any stable version.

I am going to take a look at it.

[romabysen]

Yep, it was introduced after the 1.1.0 release. I've only built from git source on Linux but I presume it also happen on Windows.

[tresf]

Partly closed with #1657. Will leave open for BBEditor.

[badosu]

Ok, so used git bisect to try find out which commit introduced the bug on the B/B Editor.

However I wasn't able to determine if some commits were good or bad. This is due to the fact that a change on the Timeline source file introduced compiling issues, so I had to skip these. Certainly one of these commits is the offending one:

git bisect skip
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
86f2c86
d8db894
3e9cc61
ec9158c
02006f9
e9d841d
4b27569
c6ee614
44b52eb
d029c85
11898a5
We cannot bisect more!

This is the commit that introduced the Timeline build issue: 11898a5. Let me try fixing this manually and re-running git bisect.

[badosu]

So, I really want this issue fixed because it affects the most basic usage of LMMS, and I can't move on to other issues while this is present.

I have a strong feeling that this problem was introduced on d029c85 . @lukas-w Any idea on what should I be looking for to fix this?

[lukas-w]

Hm… What exactly is the issue here? Is the BBEditor's content just not showing up at all or is it misplaced like it was in the song editor? What steps fix the issue when it occurs?

[badosu]

@lukas-w

Just updated the description, just load a different project with many BB Instruments, if the quantity is enough so that it overflows the window vertically then the BB Editor becomes unusable.

Here is a project that presents this problem: https://lmms.io/lsp/download_file.php?file=3587&name=sidechain.mmpz

[badosu]

@romabysen I discovered the reason why this bug seems random, read the updated description of this issue.

[lukas-w]

@badosu Thanks for the detailed research :)

[badosu]

Thanks @lukas-w, I am sorry I could not find it by myself. I am still trying to get the hang of the code. :-)

[lukas-w]

Huh? No worries. :) I'm the one who introduced the bug so I'm quite happy that I'm the one who cleans up the mess.
Also note that those parentWidget() calls in saveSettings and loadSettings are more of a hack and we actually shouldn't have them there.

[badosu]

Thanks for the description @lukas-w. Let me just ask how did this commit fix the overflow issue, was it by fixing the closeEvent override?

[lukas-w]

The closeEvent thing is just a clean-up. @DanWin introduced this in #1495 while I took a different approach to solving the issue in a different branch in d8db894.

The saveSettings and loadSettings override fixes it (at least I hope it does, have you tested it?). The bad commit was indeed d029c85. In #1426 (Editor Refactoring) I split all editors in two classes, one for the window+toolbar, and one for the actual inner widget (that's BBEditor and BBTrackContainerView here).
The saveSettings and loadSettings methods were supposed to save and restore the editor window's position, size and visibility on project load. They still reside in BBTrackContainerView, the inner widget, though, so when loading a project, the saved data would be applied on the inner widget instead of the actual MDI window. This happened here with hiding the track container widget instead of the window.
I fixed this by overriding the two methods to apply saved settings to the parentWidget(). The right solution (architecturally) would have been to move thm up to BBEditor, but I'll save that for another time.

[badosu]

@lukas-w thanks for the detailed explanation, I'll take a look and study it to understand the codebase better. :-)

The saveSettings and loadSettings override fixes it (at least I hope it does, have you tested it?).

Yes it works. Thanks!