On fire!

[spamatica]

Hey Kybos,
it's christmas several times a week with all the recent checkins :D

Haven't really been able to test it out but it looks stable enough (just kicking the tires) so maybe I should update my recording environment :-o

It looks very good, pretty much everything I've seen so far. See you even managed to fix the pan widget! Which incidentally is the only complaint I have so far. Make the line a little bit thinner? Very minor detail :)

Looks like the graphical redraw of the arranger is taken care of also.

What is your own feeling, how much is still on your todo list before you feel it's ready for release?

In other news, I just found out how stupid I am. Again.
Been complaining about my tv-computer having nvidia drivers and weird font issues, not the least causing some layout issues in MusE. Turns out it goes away if I use the force-dpi setting for fonts! I've had these problems since forever... oh well

[kybos]

Glad you like it ;-).

See you even managed to fix the pan widget! Which incidentally is the only complaint I have so far. Make the line a little bit thinner?

No problem, I made it a style sheet property so it can be changed very easily (even by the user). I was unsure myself what the appropriate width would be.

What is your own feeling, how much is still on your todo list before you feel it's ready for release?

I would say 2-4 weeks. I have one bigger project in the works and a couple of smaller things. I will open a new thread on the project anyway to discuss it with you and Tim, since it's also about removing outdated (in my eyes ;-)) functionality.

Cheers
kybos

[terminator356]

About next release: If you can wait a bit I am trying very hard to finish the latency crash fix.
I promise to try and have it done by the end the weekend.
I'll work on it tonight (Saturday).

[spamatica]

Den lör 17 okt. 2020 kl 19:31 skrev Tim <[email protected]>:

About next release: If you can wait a bit I am trying very hard to finish the latency crash fix. I promise to try and have it done by the end the weekend. I'll work on it tonight (Saturday).

That won't be a problem, realistically the release will happen later than that, need to test more. I think I missed the report about the latency crash, what triggers it? I have latency compensation turned on pretty much always and crashes (regardless of origin) are pretty far between. —

…

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/56/comments/2>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCFAN5ZBUZ6UUKDISOWHXTSLHIIXANCNFSM4SGL7MDQ> .

[kybos]

For the latency crash, there is a ticket:
#853

BTW: Are you planning a pre-release or a full one?

[spamatica]

Ah, yes, that rings a bell.
As for releases, I didn't plan too much and am of course open to suggestions.
Prerelease for such an invasive change seems like a good idea.
Also, 4.0 seems like a good round number for the same reasons 😊

[kybos]

I agree.
I was not sure about version 4, as the repo source folder is called muse3. Or is it technically irrelevant?
Renaming (or copying) it to something more neutral (e.g. src) would break a lot of things, I'm afraid.

[spamatica]

Yeah, in retrospect it was a mistake to create this sub folder with the version number embedded.

I wonder though where issues might crop up if we change it. (Seems silly to be stuck on version 3 for ever)
Greping the sources for muse3 only shows a trivial amount of paths.

Packaging I guess would be affected?

We have four options, more or less:

1. keep muse3 and suffer forever with it.
2. change it to muse4. Nearly as bad but would be easier to debug if anyone external has problems.
3. change it to src. Future proof but slightly harder to understand for an external persons.
4. abolish muse3, move everything to the root. Suffers much the same as point 3 but is closer to a "normal" repository structure.

[kybos]

I was not 100% sure if git can handle it (w/o losing the history etc.). But from what I get from the docu, it should be no problem (git mv).
I personally would go for 4), as it's closest to "standard". And clean up the root dir a little (e.g. the many README files - put them in a subdir, remove those available in wiki...).

[terminator356]

I have several branches, I am worried a switch like that would likely really mess them up
I recall that's what seemed to happen when we went from 2 to 3.
The problem is that I have no idea now when I can finish the branches.
Things are just super busy and crazy for me now. I'm back at work full time.
The state of this world is messing me up too, psychologically.
I come home from work and I just want to shred on the guitar, for fear of losing it !
This is terrible. It's like a paralysis.
My branches are suffering from bit rot and I am forgetting what the hell I was trying to do.
I am the only person who knows (knew?) what's going on under the hood with the audio/midi engines,
and where they are (were?) headed.
I was sooo intensely into the code, in my mind. Now everything is messed up.
Sigh. What can I do?

[spamatica]

I hear you, these are weird times. We are all affected in different ways and the psychological part will last a while.. but it will get better so I hope you can hang in there. And shredding is good! :)

As for knowledge of MusEs internals, Yeah, as having written most of it, you are the one that knows most. But the code isn't impossible to understand. And personally I've been around a long time so I know how a lot of it is supposed to work anyway.
The branches you have lying around, would it be possible for you to check them in (in separate branches of course)? Or some of them. I think that might be a first step to get them to progress.

In either case, sometimes we have to accept reality and drop some of the balls, I know I have to...
With MusE we are still in a pretty good place, sure there are a lot of things that can be improved but MusE is a very capable machine by now and I use it to produce nearly daily! :)

Changing the paths and affecting rotting branches.. that is a legitimate concern. Git /should/ be able to resolve it, but in reality (due to whatever, quite possibly my own fault) I sometimes find it necessary to merge by hand, which is not very fun. We will have to come back to this.

[kybos]

Changing the paths and affecting rotting branches.. that is a legitimate concern. Git /should/ be able to resolve it, but in reality (due to whatever, quite possibly my own fault) I sometimes find it necessary to merge by hand, which is not very fun. We will have to come back to this.

Git got better support for directory renames with version 2.19 from 2018 (e.g. https://github.com/git/git/blob/4d34dffbdd2226034df9d7612f1e221b7143fc6a/Documentation/technical/directory-rename-detection.txt).
Still, after having read quite a lot about it, I'd abstain from my preference to move the muse3 folder to the root. This obviously can be done (without losing history), but it's complex and thus risky.
Simply renaming the muse3/ folder to src/ is the more secure option. The important thing is to do it in one single commit and not change anything else in this commit.

Strategically a new major version number would be appropriate, I think, it usually gets more attention and visibility, and that's what MusE needs and deserves ;-).