4.0 final

[spamatica]

To put an end to this I thought I would aim for doing the final release during the weekend, sunday-isch. If you guys are ok with that. :)

[kybos]

Yes, I agree, it's high time to get it out ;-).
I will try to create some "original art" for the splash screen (if it's ok with you of course, or do you have something already?).
Maybe Tim finds time to fix the lv2 startup issue by then.

[spamatica]

Den tis 30 mars 2021 kl 18:58 skrev kybos ***@***.***>:

Yes, I agree, it's high time to get it out ;-). I will try to create some "original art" for the splash screen.

Alright, that'd be nice :) Maybe Tim finds time to fix the lv2 startup issue by then.

Any luck Tim?

[terminator356]

I think all I will have time for is getting my fixes in there. I'm finishing up.

For the LV2 load time, if we are going to go with a worker thread, that will take some work.
Otherwise without a worker thread I could rig something up, but some thread somewhere,
likely the GUI thread, will have to wait those eight seconds or more, either at startup or when clicking
on the presets menu or something like that. Eight seconds is a long time to wait for a popup menu...

[kybos]

Don't worry about the lv2 issue Tim, it was not my intention to put stress on you (especially if you have other things to finish).
I've fixed it anyway in the meantime (not yet in master, I wanted to do some more testing on my main system this evening).
I think there is a basic misunderstanding with these 8 seconds. This is the time the many hundreds lv2 plugins need at program startup to construct the LV2Synth class (with all the parsing done in there), including loading all the presets for each. For an individual plugin the loading time is of course much shorter, so it's no big issue to load the presets for just one plugin at the time the preset menu is populated.
The build-up time for the menu object itself is already quite long when there are very many presets (=menu entries) so it doesn't matter much (and with my fix the preset loading is done exactly once when the menu is opened for the first time, not every time).

[kybos]

@spamatica
Could you please check if the start-up time is shorter now on your machine?

[terminator356]

Patch looks clean. Basically what I would have done, without a worker thread.
Thanks.

[spamatica]

On my test now it looks to have shaved around 1.5 seconds from the startup. In other words, it has helped but the bulk is still there.
Did it help more on your system kybos?
Regardless I'm still set to make the release during the weekend unless something comes up :)
Btw the splash looks slick!

[kybos]

Thanks!
1.5 seconds less seems not too much in your case but it's better than nothing, and it saves system resources in any case.
With my main system (quite state-of-the-art, with 16 cores, NVMe SSDs etc.) it's definitely more in relation, the start time is reduced from ~7-8 to ~4-5 seconds. It also depends on the number and kind of lv2 plugins installed, of course, possibly release vs. debug version etc.
But as I wrote earlier, the presets were only part of the problem. All the other data from the TTLs are still parsed at start for all plugins (like the controls/parameters - many plugins have hundreds of them as well).
That's not so easy to change and certainly nothing that should be messed up with so shortly before the final release, but I will keep it in mind for later, I'm sure there is still room for improvement.

[kybos]

BTW: With the -2 switch (i.e. without lv2) MusE is up in 1 second on my system.

[kybos]

I added some timestamps to stderr so it should be clearer now where the time gets lost. There is also a timer output showing the overall startup time. What does it say on your PC?
(It already helped me to spot an issue with the appimage start time, just fixing...)

[kybos]

Back to the original topic - the final release:
I went through the documentation in the wiki, removed/changed some obsolete parts (like the references to the old midi Track info) and updated many of the screenshots. So the docu should be acceptable for 4.0 as it is now, at least it's not wrong or totally outdated, though very incomplete of course. E.g. there is nothing on midi recording, maybe we could link the nice tutorial from oscillator there at least.
An area that doesn't seem to be documented anywhere and that I think no user has any chance to understand is the drum editor (the drum list part).

[terminator356]

Hey @kybos feel free to add yourself to the AUTHORS file, in whatever form you wish !
I don't think we even know your first name, or was that revealed at some point?

[spamatica]

Oh man, I'm very thankful that you are such a fixer @kybos, otherwise things would progress much slower :)

Today didn't go as good as I would have wanted, bad sleep, headache and various other diversions.. I got in a few hours documentation fixes tonight anyway but I better stop now or I will fuck up another night and tomorrow will be a pain... oh well.

Anyway, going through the documentation and checking out stuff in MusE while adding info about the editors I found out many new things I didn't know about MusE! For instance that the drum editor instruments have a midi output again, that was gone in the new style drum tracks, right? Very cool :)

A question -I think to @kybos, what does the Display->Group options in the drum editor actually do? Looks interesting but I couldn't figure it out.

I got stuck on the pianoroll so not much documented for the drum editor yet but hopefully tomorrow.

Finally, I learned a few new tricks about editing github markdown, maybe this is known but it helped me quite a bit so I thought I would share.
Previously I would edit the pages directly in the wiki but it was a pain to preview the additions. Like most other things on github the data is actually stored in git so the wiki can be checked out with:

git clone https://github.com/muse-sequencer/muse.wiki.

Whereupon all pages will show up as .md files which can be edited with a local markdown editor.
I struggled a bit with finding a good markdown editor, in the end I found that Visual Studio Code with the 'Markdown Preview Enhanced' extension can show a side-by-side rendering while editing which works great.
Also adding screenshots is much easier working locally.

[terminator356]

drum editor instruments have a midi output again

Oh, you mean the midi port and channel 'redirect' columns? Yes that was missing from Florian's
new drums and held us up for a while until I managed to unify them, eliminating old drums.

what does the Display->Group options in the drum editor actually do?

That's Florian's new drum stuff. It has to do with grouping similar instruments, if they can be.
I believe it only has an effect when viewing multiple drum parts in the same editor.
Normally all the instruments from the multiple parts are shown stacked on top of each other.
But if they can be grouped together that setting will allow it.

[kybos]

what does the Display->Group options in the drum editor actually do?

That's Florian's new drum stuff. It has to do with grouping similar instruments, if they can be.
I believe it only has an effect when viewing multiple drum parts in the same editor.
Normally all the instruments from the multiple parts are shown stacked on top of each other.
But if they can be grouped together that setting will allow it.

Right, I'd had to analyze the code to find out, as it's not obvious at all. I suppose the menu items should be at least greyed out when only one part is opened.
But what I still don't understand are all the settings/options in the context menu of the drum list (like Set row/column/field etc.). So many functions that seemingly do nothing... Very confusing without an explanation/documentation.

Finally, I learned a few new tricks about editing github markdown, maybe this is known but it helped me quite a bit so I thought I would share.

Yeah, I'm also using VSCode with the Preview function on a local wiki clone. I suppose it's the best you can get, even if the source editing is a little buggy in Code if you have the preview opened in parallel and there are screenshots in it, then the source window sometimes jumps up and down erratically.

Hey @kybos feel free to add yourself to the AUTHORS file, in whatever form you wish !
I don't think we even know your first name, or was that revealed at some point?

Sorry for that, I'm a little paranoid about privacy in this never-forgetting, never-forgiving internet, trying not to leave any identifiable personal traces... I don't use "social" media and similar things either... I hope my old nickname is as good as any other name for all purposes of the inet ;-).
Otherwise I'm quite "normal", nothing to hide. I've a family, I work for one of the big software companies (albeit in a very different area and programming language from what I'm doing here ;-) ).

[terminator356]

Ugh. I think I broke drawing of midi notes inside arranger parts in playback mode with my last fix.
It updates them very 'choppy', not drawn fully.
If you can hang in there I'll fix it.
I just have to get those new pesky comparison lines correct. I'm being too strict there.

[terminator356]

Done.
Fixed in master, again.

[spamatica]

Alright, no worries, I got stuck with updating the manual (in a good way) so there will be a few more days before I'm thinking about pushing the big button. Saturday probably

[spamatica]

So, I didn't get to complete all the things I wanted to add to the documentation yet but I feel on a roll so I hope I can keep it up.

I have however pushed the button now so 4.0 is officially out the door! Yay to us! :)

So far it is uploaded to sourceforge and github with a release note.
In the end I decided on a very short release note mainly stressing the new UI. Left to do is the homepage, wikipedia the forums at linuxmusicians and the linux audio mailing lists. And any other places we can think of.

I think I will hold off mailing and forums until tomorrow so you guys can react if, in my hurry, I forgot some other big change that really should be in the release note. I mean all the announcement places this far are updatable.

[kybos]

Cool!
I will add the AppImage to the release files.

[spamatica]

Okay, first bug, seems the wave extension got broken again :P
Doing some celebration recording and it's acting up. I can get it to work sometimes but can't see a pattern yet.

[terminator356]

Assuming your apparent hardware issues have been worked out, he he... ;-)

As far as I can see the arranger seems to be working, record and playback of waves seems OK,
and using the border resizing 'hidden' features seem OK.

The wave editor seems OK as far as placement of wave events and playback and so on.
Might you be talking about editing the waves using the 'functions' in the wave editor once recorded?
Yes, I recall an editing offset problem when using the border resizing 'hidden events'.
In fact I recall an existing editing issue even if the wave event is moved forward ie. when the left
part border is moved to the left exposing more space.
So there seems to be an existing offset problem perhaps.

If that is the case I can get in there and fix it, thanks for waiting to announce.
Lemme know if that's the case.

"The inevitable post release fix release" as you once said.

[spamatica]

Ey oh. Maybe it was my build that was wonky, this was tested on my regular machine (not the one with the wierd midi devices) but I only did an incremental build of master. Tiny chance there is a configuration problem.

My description was not very clear, it was the resizing that I was trying to use in a real use-case. I made several guitar takes and tried to stitch the best parts together. But then the resizing, neither left nor right worked. Curiously it seemed to make a difference whether I had imported a wave file or recorded it live.. very weird. Never got it to work fully though... but I will test more.

In any case, I thought I would go ahead with the announcements tonight, any bugfixes will go into the inevitable 4.0.1 :)

[terminator356]

OK. I'm fixing the wave editor 'functions', yes they were broken with resized borders.

As for stitching wave parts together, I'm not surprised it doesn't work.
There are still some things that need correcting with these new resizing features.
Not everything could be fixed in time.
The most radical thing is of course that events can have negative time,
but also that the event list is now sorted by signed integer instead of unsigned.
So there are a lot of places that choke on that when iterating the event list to 'do things'.
I have fixed the most up-front things so it just works, but now we must dig in and correct
the remaining areas.

[spamatica]

Once again I was probably not clear enough. ;)
I didn't mean stitching in the sense of gluing them together. I reported another issue with that before (which might be what you mean).

I have wave files that I have cut up and at the cut-point I want to nudge the position so I don't lose any of the waveform I'm after.
Right now I got it to work with a wave file I imported. Both sides of the cut get the hidden event marker. What I experienced earlier was that the hidden-event marker would not show up, or just on one of the sides was marked with hidden event. Maybe some unintialized variable or something? I mean, it shouldn't really make a difference how the wave got there?!

[terminator356]

Ah I see. Maybe nothing wrong here.
Keep in mind when you split a wave part, the resulting wave part on the right
does not get a hidden events marker at the left border.
That's because the part's wave event already has an offset (the 'spos' member)
where it was split. So there is actually nothing hidden at all at the left.
The wave event really does start at zero time and thus is not 'hidden' at all,
and really it's just that the wave event's 'spos' offset member has a value other than zero.