4.0pre3

[spamatica]

I see you went ahead and fixed the midi recording modes kybos, very cool. I suppose there may be some duplicate effort with one of Tims branches but as this is a good and requested feature it feels like the right call. Hopefully there won't be that much backtracking necessary for TIm.

I just merged the changes for project handling, hopefully it's mostly correct :)
I thought I would do the name changing to 'src' from 'muse3' and then we might do another test release?
The name change can still feel a bit scary but it is the right thing to do, we have to bite the bullet sometime.

[kybos]

I see you went ahead and fixed the midi recording modes kybos, very cool. I suppose there may be some duplicate effort with one of Tims branches but as this is a good and requested feature it feels like the right call. Hopefully there won't be that much backtracking necessary for TIm.

I know but from what I got from Tim's comments in the tickets, he has a more substantial rewrite of the functionality in mind (addressing other issues as well). So my fix will be probably removed anyway then, should Tim's branch get finished. He has many branches and little time, unfortunately ;-), and this fix is quite important IMO (MusE is supposed to be the best MIDI editor for Linux after all, isn't it ;-) ?)
There is also the PR for it, so the changes can be easily traced and even reverted if necessary.

I thought I would do the name changing to 'src' from 'muse3' and then we might do another test release?
The name change can still feel a bit scary but it is the right thing to do, we have to bite the bullet sometime.

Yes, ok with me.

[spamatica]

I pushed a 4.0pre3 commit, including the muse3 to src change. And (as expected) the automated builds were not too happy. I can't find the yml files, where are they? :-}

[kybos]

Looks good. I only had to adjust the repo path in the Actions (the scripts are in .github/workflows in the root folder).

[terminator356]

Yeah it's always a fail somewhere when you do that.

For my latest commit, my code base was from a few weeks ago. I had not updated since then.
Before taking a chance with 'pull', I decided to 'stash' my changes, then pull, then see what happens.
For safety backup, I created a text diff from the stash. At least I would have that to shoe-horn in later
if all else failed.

After pulling, KDevelop did not like the new arrangement. (It never does).
The tree was blank except for the build folder.
I have learned from the past that I needed to remove the project from the KDevelop session
and re-add it. That usually works and it did, presto, the source tree was back, under src.
(Gee I wish there was some menu or git command I could execute to force KDevelop to refresh).

Thankfully, any code stashes remain after doing that.
So I simply 'pop'd my stash in KDevelop and it merged fine.
I guess that's the embedded good ol' patch command finding the correct files,
since the stash referenced the old muse3 folder. Whew!

So now I have a decent idea of how to handle much larger WIP based on the older code base,
such as the one I'm currently doing (the border resizing thing).
It merged fine with just one conflict in arranger/structure.cpp, but conflicts are a normal thing.
Strange, I only changed one line in structure.cpp but the diff said the entire file was changed.
A couple of other places in the diff also said that an entire file changed.
Hm, someone got their DOS CR/LF on again?
Perhaps those are some of the files I forgot to switch back from CR/LF a few months ago
when that disaster happened?