Roadmap?

[kybos]

What's next?
MusE 4? Or better finish unfinished things for 3.2 or even 3.1.1?
I guess there should be at least 3.1.1 for fixes (and things like the currently open PR).
If release 4 should be targeted at some point, what about the muse3 folder in the master? Will the complete source tree be copied into a new muse4 folder?

[spamatica]

We generally leave a little space for bugfix releases 3.1.x and breathing. Then go for the next big one (which historically has meant we have gone into hibernation for way too long before getting it together again ;) ) Maybe this time we can have it a little more coordinated. Feels like the wheels are still moving at least. I definitely think the next feature release should be called 4.0. As for the muse3 folder, good question. I can't think of a good reason to keep it though, so maybe just rename it? Should we try to compile a little list of wanted improvements? We have the latency compensation and time stretch features that will keep Tim occupied for a while atleast.. And maybe some UI polish, like dark theme as we discussed a bit. Reminds me I have a branch somewhere where I started improving part resize, mostly for audio but midi too. I would want to finish that if I can find it again. Den tors 27 feb. 2020 kl 08:48 skrev kybos <notifications@github.com>:

…

What's next? MusE 4? Or better finish unfinished things for 3.2 or even 3.1.1? I guess there should be at least 3.1.1 for fixes (and things like the currently open PR). If release 4 should be targeted at some point, what about the muse3 folder in the master? Will the complete source tree be copied into a new muse4 folder? — 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/34?email_source=notifications&email_token=ABCFAN5LZKFVDPYGDZ472TTRE5UW3A5CNFSM4K4VP3J2YY3PNVWWK3TUL52HS4DFVZCGS43DOVZXG2LPNZIG643UVJRW63LNMVXHIX3JMTHAAAMCBU>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCFANZUZGHJLGYJYOC26E3RE5UW3ANCNFSM4K4VP3JQ> .

[kybos]

Sounds good.
Renaming muse3 could be a bit of a problem (as Tim mentioned already), as that will most probably break the links to other branches. I think it has to be done at some point, but then a more neutral name should be chosen, to avoid further renaming in future. Or remove the top level node completely, this would at least avoid the confusion with the releases?

I would add some more items to the to-do list for the start ;-) :

• Remove obsolete/fully merged/otherwise unnecessary branches from the repo.
• Close obsolete issues. I tried, closed some, but mostly I don't have enough background knowledge to be able to do so.
• Move relevant README.xxx files to the wiki (or documentation), remove irrelevant ones if appropriate.

[terminator356]

I have started a new item on the 'Projects' github tab. Check it out ! It's the place for this stuff.
I added a TODO list.
The first item of business I added is an Ardour-style welcome screen where
at the very least and most importantly, audio driver can be chosen before launching.
This is because there's too much confusion about which actual driver is being used to run.
With -a and the selection of driver in Settings, I find myself wondering a lot which one is being used
and it's a pain to have to go to Settings, change it, and then restart.

[terminator356]

Meh... the Projects tab is kinda weird. The TODO column is kind of cluttered.
I guess try to keep each TODO item as brief as possible... ?

[terminator356]

The next TODO item I added is... the long-forgotten user manual !!!
See the comments there. We generate both PDF and HTML.
Why HTML? Because there was the possibility of using the HTML together
with Qt Help features for context-sensitive help.

[kybos]

Meh... the Projects tab is kinda weird. The TODO column is kind of cluttered.
I guess try to keep each TODO item as brief as possible... ?

Each task should go to a separate project IMO, otherwise it defeats the purpose and is not manageable.
Also we should not forget that the project tab is public.

[kybos]

The first item of business I added is an Ardour-style welcome screen where
at the very least and most importantly, audio driver can be chosen before launching.

I agree that this needs more transparency, but it should be optional (like the current splash screen). For a standard use (like with jack in always the same environment) it would be an unnecessary annoyance to have to confirm an additional popup at every start.

[kybos]

Why HTML? Because there was the possibility of using the HTML together
with Qt Help features for context-sensitive help.

Does is mean that the HTML version is not used?

I noticed that the master documents are written in LaTeX, no fun editing... at least for me. I wrote my thesis with LaTeX, but that's a long time back, my current knowledge is near zero...

[spamatica]

Den fre 28 feb. 2020 kl 08:45 skrev kybos <notifications@github.com>:

The first item of business I added is an Ardour-style welcome screen where at the very least and most importantly, audio driver can be chosen before launching. This would be a very nice improvement with a setup screen.

On some computers I have to be careful with how I start MusE as it can lead to a lockup with the sound drivers, I think it is pulse audio and jack competing for using the sound card. I tried the flatpak image of MusE yesterday and ended up with this problem. When I unblocked the soundcard the flatpak build seemed to work.

I agree that this needs more transparency, but it should be optional (like the current splash screen). For a standard use (like with jack in always the same environment) it would be an unnecessary annoyance to have to confirm an additional popup at every start.

Yeah, it should be possible to disable. I hear several people that like that starting MusE and getting to composing has so few steps.

…

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/orgs/muse-sequencer/teams/musedevteam/discussions/34/comments/7?email_source=notifications&email_token=ABCFAN3YQ4NXIFG6VZFVBMTRFCZQ5A5CNFSM4K4VP3J2YY3PNVWWK3TUL52HS4DFWNCGS43DOVZXG2LPNZIG643UKJSXA3DZVJRW63LNMVXHIX3JMTHAAAWC2I>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCFAN66TMMLI66SKONEKSTRFCZQ5ANCNFSM4K4VP3JQ> .

[terminator356]

Yes, the lockup problem is what I had in mind.
It is caused when the Pulse-Jack bridge is not set up properly.
I think a lot of systems are not set up properly out of the box. Mine wasn't.
I believe I solved it simply by opening the Pulse control panel and setting it up.
Once I did that, everything worked. Try it!
It's great. I can run Pulse and Jack apps together. I can run MusE without fear of lockup.

There are a few other things we might put there. For example we could allow them to open
the Settings (or say, a mini-panel ) and examine and set plugin paths for example,
before starting all of the subsystems and before starting the audio driver.
A few of the command-line options could be conveniently put there as well.

It would be nice to be able to start/stop and change the audio driver on the fly.
In theory this is possible, but it would require some heavy changes chiefly because
the segment size might change and we need to re-allocate all processing memory blocks.
[ Edit ] (And it's more than that: Certain local 'counters' would need to be reset to zero
because they might currently point to positions beyond the new segment size.)
The OOM team did a lot of work on that, I think possibly more in anticipation of Jack's
'segment size changed' notification callback, but possibly with an eye towards this idea of
switching drivers on the fly.

And yes, of course it will have a 'don't show again'. I would not propose it without such a thing ;-)

[terminator356]

@kybos We generate and install both the PDF and HTML versions.
Simply because we could. Or rather, for whoever desires either one.
But mostly because Qt has a context sensitive HTML help API that we might
try to leverage.

Yeah I hear ya about the Latex. Incredibly tedious. In part because Florian
found that he needed to impose a strict set of rules (found in the latex file)
such as line width and so on, for consistent output.

If you look at my script 'build_docs.sh', you see what a nightmare it was to generate
both PDF and HTML. Several packages are required.

Really I would soooo like to have a nice latex IDE open beside me so that any time I
make even the slightest change or addition, I can quickly and dutifully update the manual
right while it's fresh in my mind, instead of typing into a LM topic or yet another README.
But I tried that and the IDEs didn't really produce the same output or didn't provide
easy ability to generate both types.
(Forgive me it's been almost ten years since we did any work on that manual stuff.
Things may have improved by now.)

[ Edit ] I would happily abandon those strict rules imposed (above) if it just meant
we could get the docs out much quicker with reasonable results, using a nice IDE.

[kybos]

It's a shame that so much information and knowledge is scattered over LM / PR / README and other places, where nobody will find them. Now if it's only technical obstacles that keep us from updating the docu, then there is something wrong with it and should be changed urgently.
I'm also sure that a 10 years old docu content doesn't really motivate potential new users, and the good old TeX "Computer modern" font looks anything but modern these days ;-).

Moreover, this kind of local documentation is quite outdated nowadays, you will hardly find any application that does not take you online for its Help/Manual/Documentation (just check it out if you don't believe me ;-) ).
IMO it would make sense to use the gibhub wiki for the manual, as so many other apps do. It's easy and quick to maintain, it supports several markup (or down, or out...) languages. It can be easily structured, e.g. in main docu, FAQs or similar for special topics etc. And there are editors like Haroopad if one prefers to edit the markdown completely offline.

[kybos]

No reaction, I guess you guys are just shocked by my disruptive ideas ;-).

I did some rework on the wiki, I created a custom menu and integrated the manual and some of the READMEs that seemed relevant to me. All the existing format converters to markdown I used are quite lacking unfortunately, it required a lot of post-editing (especially the images and the cross references in the manual...), so I hope that it will be of some use at least ;-).

The big manual file could be split into smaller chunks of course for still easier maintenance, would be no problem now that it's properly converted, but before I do it I would like your opinion on all that - do you support the idea of putting all the available documentation in the wiki/online and maintain (and reference) it there?

[spamatica]

Yep, in shock :D More likely just bad at prioritizing and no time right now either... Will try to read up on this thread during the weekend! Putting documentation in the wiki sounds like a plan anyway. Den fre 6 mars 2020 kl 22:14 skrev kybos <notifications@github.com>:

…

No reaction, I guess you guys are just shocked by my disruptive ideas ;-). I did some rework on the wiki, I created a custom menu and integrated the manual and some of the READMEs that seemed relevant to me. All the existing format converters to markdown I used are quite lacking unfortunately, it required a lot of post-editing (especially the images and the cross references in the manual...), so I hope that it will be of some use at least ;-). The big manual file could be split into smaller chunks of course for still easier maintenance, would be no problem now that it's properly converted, but before I do it I would like your opinion on all that - do you support the idea of putting all the available documentation in the wiki/online and maintain (and reference) it there? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/orgs/muse-sequencer/teams/musedevteam/discussions/34/comments/13?email_source=notifications&email_token=ABCFAN7ZLG6C7NEIJP66HFDRGFLUXA5CNFSM4K4VP3J2YY3PNVWWK3TUL52HS4DFWNCGS43DOVZXG2LPNZIG643UKJSXA3DZVJRW63LNMVXHIX3JMTHAAAWKLM>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCFAN4T5Y6DXU4YVE7UWMLRGFLUXANCNFSM4K4VP3JQ> .

[terminator356]

Thanks @kybos, great work, looks good.
Hey, this is HTML. Maybe later, finally get around to using the Qt context-sensitive
HTML help to index into it. And maybe possible to roll all the HTML up into a PDF at some later time.

[spamatica]

Now I've read. It's great that you have moved the text to the wiki. I support this completely.
As for context sensitive help as Tim mentions. I see that it's perfectly possible to link to chapters in the wiki, if we ever get to that point.
Having the manual easily accessible and easily editable is a great improvement, I guess that means we'll change the link in the help menu to point here too, right?

[kybos]

I guess that means we'll change the link in the help menu to point here too, right?

Yes, that would be the next step.
I changed it in master.