slow synth instantiation

[spamatica]

Not sure when it changed but on my system I experience sluggishness with certain operations, like launching synths.
I was going to to have another look at saturnin51s issues from the forum and I discovered that starting fluidsynth takes several seconds and before it was instantaneous.

I first blamed my system but it turned out I have an old build of muse4 (I think it is pre1) and it starts fluidsynth instantly.
Have you guys noticed anything similar?

[kybos]

What do you mean starting Fluidsynth (the MESS one?). Creating a track for it, starting the GUI?
I tried both and it was immediate.
However, I can't compile the current master with your latest changes.
You used QPalette::PlaceholderText, but this enum value was introduced in Qt 5.12.
We are supposed to support Qt down to 5.7, though (I have 5.9).

[spamatica]

Ok, so maybe it is system dependent...
I used the old style right click menu and created one instance of MESS/fluidsynth I think it is like that for all.
We got a ton of snow again so I'm currently passed out on the sofa, when I get some energy I will try to backtrack and see if I can find out more.

Regarding the PlaceholderText, I did reenable an old commented out code for QPlainTextEdit but it seems to be supported since 5.3. Search tells me there are some instances in the ui file, maybe QtCreator added one. I will try to sort it out. I indeed have qt5.12.

[kybos]

That's what the Qt docu says:

QPalette::PlaceholderText | 20 | Used as the placeholder color for various text input widgets. This enum value has been introduced in Qt 5.12

[spamatica]

If I understand correctly it was the ui file, I had fiddled with some settings that I did not need. Looked a bit more and it seemed to be easily reverted so I checked in a cleaned ui file, hopefully that is all that is needed.

[kybos]

I can compile now, thanks.
Perhaps I could try to create another CI action, just to build MusE on the oldest supported Qt release. That could help to recognize these kind of problems faster.

I looked at the new revision saving dialog - what is the difference between this and the normal Save as... function? The behaviour seems to be exactly the same.
And if you don't want to see the project dialog, there is the option in Global Settings->GUI->Use project save dialog, which skips it when unchecked.

[spamatica]

Den tors 21 jan. 2021 kl 20:04 skrev kybos <[email protected]>:

I can compile now, thanks. Perhaps I could try to create another CI action, just to build MusE on the oldest supported Qt release. That could help to recognize these kind of problems faster.

That sounds like a super idea. I looked at the new revision saving dialog - what is the difference between

this and the normal Save as... function? The behaviour seems to be exactly the same. And if you don't want to see the project dialog, there is the option in *Global Settings->GUI->Use project save dialog*, which skips it when unchecked.

I like the project dialog (I added the first version a very long time ago :) ) but since the change you added it cannot be used for saving revisions (if you use a project folder, files after changing the name will end up in the wrong place). I was thinking of adding options to it for handling that but it would be a bit hard to explain exactly what it does. So I thought that it might be better as a separate feature that explicitly focuses on this. Basically all I want is for common operations to be as easy as possible, and personally I do create revisions a lot. :) The old-style save-as dialog could in principle be used for this but you need more mouse clicks and there are more possibilities to do the wrong thing. AND I want the 'create project' dialog too so it does not make it any easier. Missing from the revision dialog is that it should detect if there is a number at the end of the filename and increment this automatically, then the process would be as simple as it possibly can get.

…

— 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/70/comments/5>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCFANZ5SWK6LZBYYOS32JLS3B265ANCNFSM4WNBYOYA> .

[spamatica]

Back to the sluggishness. I did some timing and testing of different versions of MusE and it turns out that on my system, thinkpad t450 (not the most recent laptop but works nicely with MusE) launching of MusE takes takes around 25seconds up to checkin "Add track shortcuts" b712c05 from january 13.
With this checkin the startup time doubles, and I get the slowness with instantiating synths (fluidsynth goes from instant to maybe 4 seconds).

I'm looking at the diff but cannot spot anything obvious..

Though I am a bit curious about the new shortcuts shown in menus, which of course are great! But do they play well with our home built shortcut system? Not sure if this is the first checkin with such shortcuts, if it is that would be my first candidate.
It's getting late (and is still snowing...sigh) so won't be doing any more to night, maybe tomorrow.

[kybos]

Thanks for tracing that down. I couldn't reproduce it on my main system, but I will try this evening with a KDE VM (I assume KDE is what you are using). Or perhaps it's the newer Qt version - they made some changes recently affecting shortcuts in context menus.

Re dynamic event lengths in Pianoroll:
This is a pretty cool addition! IMO it shouldn't be hidden in the GUI tweaks where nobody will find it (and it's not a tweak anyway but an essential function) - what about putting it into the toolbar as a checkable button next to the snap (which it's related to)? So it would be easy to spot and also easy to switch quickly.

[spamatica]

I think you can wait with further investigation for now... I tried it on another computer with same OS and it does not have this problem. I will do some more digging, very curious.

Ah yeah, it was a pretty cool idea. As I wrote it was from a forum thread on linuxmusicians, apparently FLstudio works similar to this. But as it was so trivial I didn't think it through, it should at least be a menu option. Thinking more it should be extended to velocity too. Velocity is actually remembered but not through this and the functionality is kind of weird, last event you clicked on or something like that.

[spamatica]

I discovered the source and it left me even more confused :D

Currently I have a bit too many old laptops and for reference I tried my old and tested thinkpad t420 and found that it did not have this problem, infact it started muse twice as fast as the t450, wtf!?

Tried lots of things after that and long story short, I have an external monitor connected to the t450. It is connected through VGA and the problems vanish when I disconnect the monitor?!
Too wierd. Hmm, maybe a graphical memory issue, perhaps I can increase it somewhere.. will have to do some more testing.

An unrelated question while I remember, I saw that you changed something for simpledrums, I still can't see it on my self built muse though, should it be there?

[kybos]

I don't remember changing anything in Simpledrums - perhaps you mean the compile error connected to it?

As to your problems: Sounds like your external monitor grabs too much of the main memory (in laptops it's mostly shared with the graphics memory). Then the system is forced to swap, which makes everything slow.

[spamatica]

Not compile error but linking, the Rasterisation-something that wasn't properly linked, I think I saw you commenting on that? It still says it can't find the symbol here so simpledrums never shows up in MusE.

I think you are right it is a system resource that is lacking but not main memory. The laptop has 8GB ram (not a lot by todays standards) the system rarely goes above 1.5GB in actual usage.
Really annoying...

[kybos]

Ah yes, it's documented here:

https://linuxmusicians.com/viewtopic.php?f=61&t=22595&sid=b25e13613719f153f35c7fc19ee9ddd4

And I found Tim's comment on the widgets folder:

#812 (comment)

BTW: I created the new action (Compatibility build) and after fixing some things it now compiles with Qt 5.7.
Not sure why 5.7 was chosen as the lowest release. Usually the oldest still supported Ubuntu LTS is taken as reference, which is currently 16.04, and it has only Qt 5.5.
But now with the AppImage it's perhaps not so relevant any more, it should run on 16.04.

[spamatica]

Tried it now with the appimage and simpledrums is there so that seems fine. It doesn't appear when I build it myself though. Is there something I need to do?
Btw the appimage seems to lack rtaudio so it cannot use pulseaudio as backend, no biggie but if it's possible to add it.

My view this morning:

[kybos]

Really crazy with the snow... You probably can't even leave your house?

You have to build with the MODULES_BUILD_STATIC.
It's of course no solution, only a workaround, until Tim has time to fix his rasterizer code.

rtaudio: I will look into it. But if it's missing then it most probably also means that it's missing from our installation instructions in the readme file (despite being activated by default in the cmake).

EDIT: rtaudio is there in the README, also in the appimage build (librtaudio-dev is installed), but still not found by cmake (version in Ubuntu 16.04 is 4.1, so that should be ok.) No idea what is wrong with it...

[terminator356]

Crud. Broke my own rules. Fixing it right now...
Moving the rasterizer widgets from widgets folder into components folder...

[terminator356]

Done. Sorry about that. Try it out.
@kybos Can you undo your workaround? Or, if you would like to keep that workaround,
can you point me to what exactly was done so that I can see if it is sane to leave it in there ?

[kybos]

The workaround was to compile with MODULES_BUILD_STATIC, nothing else.
I had added it to compile_muse.sh, we can remove it now.
I would keep it for the appimage builds, as it does no harm and seems to make the appimage smaller, which is good.
I have used this option for my own dev builds too, as you suggested in the PR linked above.

[terminator356]

Ah yes, the static thing is also mentioned in README.
Some packagers use MODULES_BUILD_STATIC together with
-DCMAKE_SHARED_LINKER_FLAGS=-Wl,--no-undefined
I use both all the time now.
That's because together they provide some pretty rock-solid errors that reveal
undefined symbol linkages, which would not be revealed without those two options.
Virtually guaranteed that if MusE builds with those options, it'll build without 'em
(normal build shared modules + undefined symbols allowed, because the modules are shared).

[spamatica]

Yay, cool, had missed the part about build static, no worries :)
Haven't gotten around to making a pre2 yet but I will give it a go tomorrow.

Really crazy with the snow... You probably can't even leave your house?

Actually it's fine now. It's been more than usual but we always have snow so we are prepared. There have been tractors driving around here all day shoveling snow and the street is clear now, got my car free too. The rest of my driveway is pretty oversnowed though :D

Happy to see you here Tim, how is it going over there?

[terminator356]

We finally got snow, and lots of it. And now finally the temperature has dropped for a few days.
Our world famous Rideau Canal ("The worlds longest man-made skating path") winter skate-way
will be open soon, if you'd like to visit, ha ha.
Actually, because of the situation this year authorities have asked for "local folks only, please",
as in folks only the immediate neighborhood of it.
Some taxpayers in other neighborhoods naturally are complaining.

[kybos]

Btw the appimage seems to lack rtaudio so it cannot use pulseaudio as backend, no biggie but if it's possible to add it.

I found the problem. The rtaudio package on Ubuntu 16.04 is missing the .pc file that pkg-config needs to identify it. I updated the action - it now installs a newer rtaudio (from 18.04) that has the .pc file, so the support should be there in the latest appimage.