Planning MusE 3.1 (again)

[spamatica]

Hey guys!
I can hardly keep up with all the fixes I see coming, you're a machine kybos :D And you too Tim but I knew that already ;)

The little I manage to help with I try (atleast sometimes) to focus on getting a new release out. What are your current opinions on the state of MusE, are there any big issues in current master that need to be adressed or are we getting ready for 3.1?

I understand the stretching is not really ready and there are some warts on the latency correction (I'm thinking mainly of the missing midi events at the beginning when pressing play). So I thought we don't make a big deal of the stretching and in the case of latency we don't enable it by default in 3.1.
After this we go for 4.0 and apart from improving "everything" what about switching the default theme to a dark theme? To give a very visual change.

Thoughts?

[kybos]

Exactly my thoughts (recently I pinned our first discussion about 3.1 here, to follow up on it - now you were faster ;-) ).
For my part, I have no open developments, so I would say, it all depends on Tim.

I don't know how you did it in the past, from what I know, a simple process could look like that:

• Stop doing text relevant changes.
• Ask translators to update the translations.
• Create a new version.

But I can imagine that's not quite realistic ;-). Anyway, I would at least update the German translation.

As for 4.0 and visual change: I absolutely agree, but IMO there is a little more to it than just switching to Dark theme. I got some feedback from (younger) users about the UI, and I must say they are right claiming that the look is not exactly state-of-the-art ;-). But that's a topic for another discussion.

[terminator356]

Hi. I've got stretching changes in the works but they are dragging on because of
complications, and other fixes, and health. Latency fixes are being further pushed back by these delays.
I'm afraid for now they may have to remain, as you say, 'un-promoted' and disabled respectively.
However there are some fixes immediately in the pipeline which I have have cherry picked from my
pos_ctrls_fixes branch, and I want to commit them:

1. Long-time crashes when using global cut/insert with markers.
   The markers had to be completely redesigned and markerview as well.
   The reason for the crashes was that marker functions were not undoable.
   When undoing a global cut for example, non-existent marker pointers were accessed.
   Marker functions are now fully undoable and no more crashes.

2. Global cut/insert was not working properly with tempo map.
   I am working on this right now. Unfortunately, the extremely weird nature of the tempo map
   has left me stuck for two weeks just on this one little small detail.
   It did not help that I got sick which zapped me of all brain power, just at the exact time when this
   tempo map difficulty hit me. Man, cold and flu really messes with your mind :-(
   Hang in there, I'm making progress...

@kybos Something seems not right with the track header. To verify, I wiped out my config and started fresh.
This is what it looks like without a stylesheet, the columns are too wide and despite that, the icons
are not centered:

[kybos]

Yes, I've been struggling with that. The support for icons in headers in Qt is quite lacking, to say the least... Centering the icons seems completely impossible. And then every Linux desktop + theme handles it differently.

I am sure I had tested it, but tried again: I also reset the config, and it still looks OK in my DE (Cinnamon):

I guess you are on KDE, I will try to check there. I installed Manjaro/KDE recently in a VM for comparison and there are strange UI issues indeed (misplaced/cut-off texts), like that.:

But even there the track header looks OK (on a fresh install).

[terminator356]

Just a side note, my cherry pick already changes the colour of the tempo graph
to that of the midi ctrl graphs (golden yellow), as promised before.

[kybos]

Checked again: The header columns with the icons are fixed and explicitly resized to 22px in the constructor. So I have no idea...

[spamatica]

Ah, I think I have seen this one too.. and promptly forgot to report, yea.. I've got access to a few different machines and one of them shows something similar, it's got ubuntu 19.04 if I recall correctly, the others got 18.04. Could it be a qt problem? I can check if the qt versions are different. Den lör 25 jan. 2020 kl 22:07 skrev kybos <notifications@github.com>:

…

Checked again: The header columns with the icons are fixed and explicitly resized to 22px in the constructor. So I have no idea... — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/orgs/muse-sequencer/teams/musedevteam/discussions/19/comments/5?email_source=notifications&email_token=ABCFAN5LVYGLOC2X2IWNBS3Q7SS2TA5CNFSM4KLQ6CT2YY3PNVWWK3TUL52HS4DFWNCGS43DOVZXG2LPNZIG643UKJSXA3DZVJRW63LNMVXHIX3JMTHAAAVCLE>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCFAN4RB473MSHZ3QFPVGLQ7SS2TANCNFSM4KLQ6CTQ> .

[terminator356]

Notice that the index column '#' is also affected.
I cannot resize it below the width shown.
So it does not seem to be icons' fault at all.

[terminator356]

Definitely something wrong here.
Three places use our header class: Track list, Drum list editor, and (same) Drum list in the Instrument editor.
All three will not let me resize any column below exactly 50 pixels wide, despite the fact
that the Drum list explicitly sets the sizes, like:
header->setColumnLabel(tr("H"), COL_HIDE, 20);
That exact value of 50 I am seeing seems suspiciously like some default value.
Maybe some previous 'minimum size' line got lost in all the changes?
Or... Qt changed something? I use a cutting edge rolling distro here.
Must check our header class (and its usage) against older MusE versions...
And check Qt help carefully for changes in the header base class QHeaderView.

[kybos]

FYI:
I updated my test VM (KDE/Manjaro), there is also a newer Qt version now, and I recompiled/reset MusE.
I can reproduce the problem now. It really looks like there was some change in Qt.
I am quite sure we don't set the min section size for the Header. I checked the default minimumSectionSize in the Header constructor, it is set to 49! That was definitely not the case before.
Setting the parameter to a lower value solves the problem.
There still remains the issue with the placement of the icon, it seems to be very different in KDE and the GTK-based DEs. Looking into it...

[kybos]

On my main dev system (Qt 5.9), the default min section size is 50, still the header resizes correctly to 22.
Obviously a Qt bug that was fixed recently.

Oh, I found the issue:
https://bugreports.qt.io/browse/QTBUG-64173

[spamatica]

Den lör 25 jan. 2020 kl 18:46 skrev Tim <notifications@github.com>:

Hi. I've got stretching changes in the works but they are dragging on because of complications, and other fixes, and health. Latency fixes are being further pushed back by these delays. I'm afraid for now they may have to remain, as you say, 'un-promoted' and disabled respectively. However there are some fixes immediately in the pipeline which I have have cherry picked from my pos_ctrls_fixes branch, and I want to commit them: 1. Long-time crashes when using global cut/insert with markers. The markers had to be completely redesigned and markerview as well. The reason for the crashes was that marker functions were not undoable. When undoing a global cut for example, non-existent marker pointers were accessed. Marker functions are now fully undoable and no more crashes. 2. Global cut/insert was not working properly with tempo map. I am working on this right now. Unfortunately, the extremely weird nature of the tempo map has left me stuck for two weeks just on this one little small detail. I did not help that I got sick which zapped me of all brain power, just at the exact time when this tempo map difficulty hit me. Man, cold and flu really messes with your mind :-( Hang in there, I'm making progress... Flu is for spending your time in a sofa doing nothing. Got it a few years

ago at the same time as the Awesome Games Done Quick Marathon which streams game speedrunning 24/7 for a week. Nothing productive came out of it but I did enjoy the week despite being sick. I'll wait a bit more and see if you can get the above one nailed then and release after that? As for the release process kybos asked about, we never really went asking for translations (maybe a long time ago). As we have been doing prereleases they should know. Still, I can put up a notice on the forum. Regardless if we get any translations I think we should get a new release out asap, we can (and will) make minor releases for such things.

[terminator356]

@kybos Great snooping work! I see a patch has been merged. Thanks.
The docs say it is supposed to default to either system global strut (which is supposed to be zero by default)
or the font metrics of the header widget.

@spamatica I finally found the true nature of my problem.
It is with the undo / operations system w.r.t. the tempo list itself.
Upon undo, during the 'gathering' stage of non-realtime stage 1, it tries to search for existing
items and operations that it can optimize, but those items may not exist yet in the tempo list
until realtime stage 2 has been executed ! After execution the result is a messed up tempo map.
Mystery solved, now I finally have a plan and way forward today ! Hang in there...
After that, I am good with a release barring further graphic or unforseen low level problems.

[terminator356]

@kybos For a while your changes had no effect on my track header. I still could not shrink the columns.
Then I wiped my config, et voila!
Sneaky devils, those saved MusE.conf Qt configs. They're always doing that sort of thing.
Looks like a strong call for the songfile version to be bumped up as I outlined to kybos the other week.
Users' existing Qt config might make it not work, like mine.
Bumping up songfile version is the only way to detect when the config contains stale Qt config stuff.
IIRC It automatically ignores the Qt config upon detection of old file version, so that it can start from fresh.
I'll try to take a look. Last time was 12.04.2019. (Too bad I wiped out the config. I could have used it to test.)

[kybos]

Yes, even I noticed this strange side-effect on my Qt 5.9 system, where this never happened before.
I deleted the line starting with <tlist_header> from the config file, then it was OK again.

[kybos]

I updated the language files + completed the German translation + updated some more inconsistent English texts. So the language part is ready for release from my side.

[spamatica]

Oh, missed the last message here, Jumps sounds like fun. First step to making MusE turing complete? :D
Oh well.
I just wanted to say that I thinking to try and do the 3.1 release coming weekend unless someone stops me. I haven't seen any show-stopper bugs so I'm hoping we can to get it over with.

[terminator356]

Sure. Just finishing up MidiName support for LV2 (automatic note names for DrumGizmo and AVDrums etc.)
Should be done soon, hopefully... today... ?

One thing I would like to take care of if possible is tracklist items' left-click and right-click confusion.
At the very least I would like to try and move the 'Port' right-click items into the left-click menu.
I find it kind of annoying. I imagine users also find it annoying having two menus there.
Also try to copy the name column's right-click items into all columns' right-click menus.
That way all columns have a common right-click menu with delete track, add track etc.
We'll see...

[kybos]

I just wanted to say that I thinking to try and do the 3.1 release coming weekend unless someone stops me. I haven't seen any show-stopper bugs so I'm hoping we can to get it over with.

OK with me, I mostly stopped my activities for the 3.1 release anyway, so as not to destabilize it unnecessarily.

What about the new cursor in the drum editor? It's quite broken in the current state. Shouldn't it be finished or removed for the final release?

[terminator356]

Working on it.
I think I will replace it (somehow) with the pencil (or a similar looking cursor),
since the pencil works well when dragging newly placed notes.
It's a pinpoint dragging tool that works well - shows you exactly where you're dragging the note.
The 4-pole arrow thing, meh... ugly no matter how you paint it.

Another consideration is to blank the cursor completely - thus the note itself becomes the cursor.
But no, due to the snapping to grid, we need to see where we're dragging.

[kybos]

One thing I would like to take care of if possible is tracklist items' left-click and right-click confusion.

A very good idea. It's one of the top usability killers for new users, being a very central place, and it sure takes a lot of time to get used to and find the right thing.
I'm not sure if it's so trivial to implement a clean and user-friendly concept for all that, seeing that the menus partly differ depending on track type etc. If it has the potential to delay the 3.1 final release again, then it should perhaps be kept for the next one...

[spamatica]

Hi guys, The release is out but not published on any forums yet. If you have the time to look through the text if I got something wrong or missed something crucial there's still time to correct it. Den tis 18 feb. 2020 kl 10:26 skrev kybos <notifications@github.com>:

…

One thing I would like to take care of if possible is tracklist items' left-click and right-click confusion. A very good idea. It's one of the top usability killers for new users, being a very central place, and it sure takes a lot of time to get used to and find the right thing. I'm not sure if it's so trivial to implement a clean and user-friendly concept for all that, seeing that the menus partly differ depending on track type etc. If it has the potential to delay the 3.1 final release again, then it should perhaps be kept for the next one... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/orgs/muse-sequencer/teams/musedevteam/discussions/19/comments/26?email_source=notifications&email_token=ABCFAN67UR7LYB4MXNJ5HDLRDOSUJA5CNFSM4KLQ6CT2YY3PNVWWK3TUL52HS4DFWNCGS43DOVZXG2LPNZIG643UKJSXA3DZVJRW63LNMVXHIX3JMTHAAAVX7Q>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCFANYK6ZXKJND23YFIEX3RDOSUJANCNFSM4KLQ6CTQ> .

[spamatica]

@kybos I changed the url on the Download page to point to sourceforge again.
The tarball on the github release page is provided by github so it's not the same as we build with the build script.

I suppose it is a good thing if this process could be automated, making the release work even less. So I'm not against making this change, but our directory structure in git has one extra folder so we should atleast adjust the README to reflect how it works.

Adjusting the directory structure in git seems like it could have a lot of side effects so that is probably a bad idea, but maybe move the README and build files to the root folder?
Haven't thought it through but I don't think the currently created tarball is ideal.

[kybos]

Hi guys,

The release is out but not published on any forums yet. If you have the
time to look through the text if I got something wrong or missed something
crucial there's still time to correct it.

Den tis 18 feb. 2020 kl 10:26 skrev kybos notifications@github.com:
…

OK with me, nicely written.

[kybos]

@kybos I changed the url on the Download page to point to sourceforge again.
The tarball on the github release page is provided by github so it's not the same as we build with the build script.

But you could add the "right" tarball to the github release page manually, couldn't you? Or am I missing something?
I checked your release instructions README and it seems that the upload to SF is a manual action too.

Not that I care much, but SF has become quite an ugly place, with all those intrusive ads and privacy issues. I try to avoid it if I can ;-).

[terminator356]

I guess Robert changed the download url back to github? Makes sense to me.

The write-up looks good. Agree, nicely written.
Especially the part about latency and stretching. Tastefully and tactfully done there, thanks!

Consider announcing on LM announcements page as well.
The LAD/LAU mailing lists seem kind of dead these days. Or is it just me...

[spamatica]

Den sön 23 feb. 2020 kl 18:04 skrev kybos <notifications@github.com>:

@kybos <https://github.com/kybos> I changed the url on the Download page to point to sourceforge again. The tarball on the github release page is provided by github so it's not the same as we build with the build script. But you could add the "right" tarball to the github release page manually, couldn't you? Or am I missing something?

Ah, you can? It all seemed so static and prebuilt. It makes sense if you can but I could not see how you did it, will look again. Then most of my rant can be ignored :P

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/orgs/muse-sequencer/teams/musedevteam/discussions/19/comments/30?email_source=notifications&email_token=ABCFAN475AKYXDIETSW33JLREKTWXA5CNFSM4KLQ6CT2YY3PNVWWK3TUL52HS4DFWNCGS43DOVZXG2LPNZIG643UKJSXA3DZVJRW63LNMVXHIX3JMTHAAAV5WM>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCFAN47OE26TSILYRUVEQDREKTWXANCNFSM4KLQ6CTQ> .

[spamatica]

Den sön 23 feb. 2020 kl 19:55 skrev Robert Jonsson <spamatica@gmail.com>:

Den sön 23 feb. 2020 kl 18:04 skrev kybos ***@***.***>: > @kybos <https://github.com/kybos> I changed the url on the Download page > to point to sourceforge again. > The tarball on the github release page is provided by github so it's not > the same as we build with the build script. > > But you could add the "right" tarball to the github release page > manually, couldn't you? Or am I missing something? > Ah, you can? It all seemed so static and prebuilt. It makes sense if you can but I could not see how you did it, will look again. Then most of my rant can be ignored :P

And of course you can. I blame it on having too small screen, I didn't see the drop point :P Oh well. I added the release. Might change the links back to github then.

…

> — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/orgs/muse-sequencer/teams/musedevteam/discussions/19/comments/30?email_source=notifications&email_token=ABCFAN475AKYXDIETSW33JLREKTWXA5CNFSM4KLQ6CT2YY3PNVWWK3TUL52HS4DFWNCGS43DOVZXG2LPNZIG643UKJSXA3DZVJRW63LNMVXHIX3JMTHAAAV5WM>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABCFAN47OE26TSILYRUVEQDREKTWXANCNFSM4KLQ6CTQ> > . >

[spamatica]

Den sön 23 feb. 2020 kl 19:16 skrev Tim <notifications@github.com>:

I guess Robert changed the download url back to github? Makes sense to me. The write-up looks good. Agree, nicely written. Especially the part about latency and stretching. Tastefully and tactfully done there, thanks!

Okay, great.

Consider announcing on LM announcements page as well. The LAD/LAU mailing lists seem kind of dead these days. Or is it just me...

Yep, I will send it out as soon as all pages I can recall have been properly updated.

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/orgs/muse-sequencer/teams/musedevteam/discussions/19/comments/31?email_source=notifications&email_token=ABCFAN2CVHAJS3V5QVY5FZTREK2UVA5CNFSM4KLQ6CT2YY3PNVWWK3TUL52HS4DFWNCGS43DOVZXG2LPNZIG643UKJSXA3DZVJRW63LNMVXHIX3JMTHAAAV5X4>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCFAN7Q2PQL6NCDF4V5IODREK2UVANCNFSM4KLQ6CTQ> .

[spamatica]

As someone on LinuxMusicians pointed out the final commit isn't in the master branch. No idea what might have happened, did I commit and release on some other branch? A quick view of the history suggest the release is uptodate though... Btw I saw we got a flatpak pull request. Maybe we should add Flatpak as an option to our Download page. Den sön 23 feb. 2020 kl 20:00 skrev Robert Jonsson <spamatica@gmail.com>:

…

Den sön 23 feb. 2020 kl 19:16 skrev Tim ***@***.***>: > I guess Robert changed the download url back to github? Makes sense to me. > > The write-up looks good. Agree, nicely written. > Especially the part about latency and stretching. Tastefully and > tactfully done there, thanks! > Okay, great. > Consider announcing on LM announcements page as well. > The LAD/LAU mailing lists seem kind of dead these days. Or is it just > me... > Yep, I will send it out as soon as all pages I can recall have been properly updated. > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/orgs/muse-sequencer/teams/musedevteam/discussions/19/comments/31?email_source=notifications&email_token=ABCFAN2CVHAJS3V5QVY5FZTREK2UVA5CNFSM4KLQ6CT2YY3PNVWWK3TUL52HS4DFWNCGS43DOVZXG2LPNZIG643UKJSXA3DZVJRW63LNMVXHIX3JMTHAAAV5X4>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABCFAN7Q2PQL6NCDF4V5IODREK2UVANCNFSM4KLQ6CTQ> > . >

[spamatica]

I think I figured it out. I did 'git push --tags' but no 'git push' (thinking that push --tags would still make a push). Probably this ended up in a situation where tag is there but not the actual commit. I'll do the push tonight. Den mån 24 feb. 2020 kl 09:47 skrev Robert Jonsson <spamatica@gmail.com>:

…

As someone on LinuxMusicians pointed out the final commit isn't in the master branch. No idea what might have happened, did I commit and release on some other branch? A quick view of the history suggest the release is uptodate though... Btw I saw we got a flatpak pull request. Maybe we should add Flatpak as an option to our Download page. Den sön 23 feb. 2020 kl 20:00 skrev Robert Jonsson ***@***.***>: > > > Den sön 23 feb. 2020 kl 19:16 skrev Tim ***@***.***>: > >> I guess Robert changed the download url back to github? Makes sense to >> me. >> >> The write-up looks good. Agree, nicely written. >> Especially the part about latency and stretching. Tastefully and >> tactfully done there, thanks! >> > > Okay, great. > > >> Consider announcing on LM announcements page as well. >> The LAD/LAU mailing lists seem kind of dead these days. Or is it just >> me... >> > > Yep, I will send it out as soon as all pages I can recall have been > properly updated. > > >> — >> You are receiving this because you were mentioned. >> Reply to this email directly, view it on GitHub >> <https://github.com/orgs/muse-sequencer/teams/musedevteam/discussions/19/comments/31?email_source=notifications&email_token=ABCFAN2CVHAJS3V5QVY5FZTREK2UVA5CNFSM4KLQ6CT2YY3PNVWWK3TUL52HS4DFWNCGS43DOVZXG2LPNZIG643UKJSXA3DZVJRW63LNMVXHIX3JMTHAAAV5X4>, >> or unsubscribe >> <https://github.com/notifications/unsubscribe-auth/ABCFAN7Q2PQL6NCDF4V5IODREK2UVANCNFSM4KLQ6CTQ> >> . >> >