Lmms: LMMS freezes if you replace Mallets with any instrument

[vlad0337187]

Hello.

Sorry me, I didn't had time to check all issues if this is already present.
Also to save some time I recorded video: https://youtu.be/utVlb8dQaeU

Here you can see that if to replace any instrument with any other - all will be well.
But if you'll replace Mallets with any instrument - LMMS will become unresponsive.
Only thing I can do - force quit from it.

Also there is no any console output for it.

This bug is present in Appimages for RC5 and RC6. (I didn't checked earlier versions, but, seems, version 1.1 can do this task).

Steps to reproduce:

• Open LMMS.
• Open Beat / Bassline Editor
• Add Mallets to it. (now it can be replaced to any other instrument)
• Change it's preset from Marimba (default) to vibraphone (if you'll don't do it, it could be replaced to any other instrument successfully)
• Gotcha! Now when you'll try to replace it, LMMS will freeze (if you'll change preset to default again before replacing instrument, you'd be able to replace it successfully)

Such a strange bug =)

System: Linux Mint 19 Cinnamon x64.
LMMS: 1.2.0-rc6-linux-x86_64.AppImage

Project with example: glass 04.mmpz.zip

Hope, this could help.

Thank you.

[DeRobyJ]

Confirmed on LMMS 1.2 RC7 64-bit, Windows 10 64bit.

As long as you change the Mallets instrument from Marimba to any other, replacing Mallets will freeze LMMS.
You can delete the track, you just can't replace it.

[zonkmachine]

I'll look into this.

[musikBear]

Related #4269

[zonkmachine]

Related #4269

Not related.

[musikBear]

ok, i thought the various flawed-states in Mallets, would influence the exchange event of an other instrument. The reported ones are similar to the erroneous dropdown-choices from 4269

[zonkmachine]

Bug introduced in 8fa5afbd2a64cf325a0c68da5e3cfa0536fd33c4

Removing this line fixes the issue but reintroduces the loud transient noises when switching pattern while a note is sounding from Tubular Bells and below.

https://github.com/LMMS/lmms/blob/fbdd09dbf56f0912ed8750cc72dda8403f5a01ca/plugins/stk/mallets/mallets.cpp#L582

[PhysSong]

I think InstrumentTrack sometimes call lock redundantly and requestChangeInModel can replace such calls. I have a simple fix for this issue.
@zonkmachine Can I fix this if you don't mind?

[zonkmachine]

@zonkmachine Can I fix this if you don't mind?

Absolutely!

[zonkmachine]

Also, the silenceAllNotes() maneuver shouldn't be done on master notes.

[JohannesLorenz]

@zonkmachine Did you want to fix this? I'm just asking because you said, but assigned @PhysSong .

[PhysSong]

I think I wrote a fix a while ago, but I almost forgot this.

[zonkmachine]

@zonkmachine Did you want to fix this?

My only idea for a fix would be to revert the commit that introduced it. Better if @PhysSong hacks this properly.

[zonkmachine]

I think I wrote a fix a while ago, but I almost forgot this.

Push it and I'll test it.

[PhysSong]

@zonkmachine Thank you for reminding it. I need to decide the scope of the fix before opening a PR, though.

[zonkmachine]

I think we can just revert https://github.com/LMMS/lmms/commit/8fa5afbd2a64cf325a0c68da5e3cfa0536fd33c4 for 1.2.2 and fix this in master if you lack the time to do this now.

[JohannesLorenz]

@zonkmachine 8fa5afb was a bug fix, so then we'd close this bug and open a new one. I prefer LMMS freezing than producing unwanted noise. :grimacing:

[SecondFlight]

An unrecoverable freeze has the potential for data loss... My opinion carries less weight than @JohannesLorenz, but I would prefer a short noise over losing all unsaved data / all data since last autosave.

[zonkmachine]

The noise is annoying but it's only when switching instrument. You can automate the instrument change and then the noise would be present when you render the project but that's more of an edge case. It will mostly annoy people trying out mallet instruments when arranging. To me the crash is worse. I have a hunch the fix is on its way anyway... :)

[PhysSong]

Sorry for the delay, now it's the time for me to fix this issue.

[PhysSong]

Fixed in #5428.