Lmms: Random notes deleted upon project reopen

[fyrebreak]

I can't find a way to consistently reproduce this bug, it always happens randomly

Whenever I close and reopen LMMS to the project I was once working on, a segment of notes would be deleted randomly from the Song editor. I always have to type in the notes again after that and risk them being deleted again.

I'm using LMMS 1.2.0 RC4, is this an already existent bug?

[zonkmachine]

is this an already existent bug?

No, it's not been reported in 1.2.0-rc4 , Not to my knowledge anyway. The closest would be https://github.com/LMMS/lmms/issues/3636 . The loading window has a cancel button and this one is connected to some standard set of buttons. <Cancel>, <Return>, <Space Bar> and <Enter>. If you press play to quickly, <Space Bar>, the project loading is interrupted and may be in an incomplete state. This would make you loose data if you saved it. Could this fit your case?

Do you use external plugins like VST's?
Do you have projects that are big and take a whole lot of time to load.

[musikBear]

@fyrebreak Please post your:

• OS (+service-pack-version)
• hardware specification (ram & soundcard is the most important)

Loss of song-editor blocks was seen in 1.1.3. I managed to record it, but there was indeed no way to reproduce.
However i found a method that would ensure that no blocks was faked in song-editor:
If you can COPY a block, it is a real block!
If you get a blanc when you try to copy, it will disappear. It is faked
You can take a faked block, and turn it into a real block, simply by moving it inside song-editor. After that, it will copy normally, and be a real block.
I show pictures of this in #2191

[fyrebreak]

@musikBear
OS: Windows 7 Ultimate, Service Pack 1
Intel i5-4278U 2.60GHz
8 GB RAM
LMMS runs on ASIO4ALLv2 (if that's a soundcard, I'm noob)

Do let me know if you need any other information.

If the song-editor block is still playing notes could it still be fake? I am certain the block was playing notes before I closed LMMS.

[fyrebreak]

@zonkmachine I was using one TripleOscillator plugin and 4 Zyn plugins. And a couple of samples. So I would not consider that 'big', to be exact. No external VSTs either.

[zonkmachine]

I would not consider that 'big'

No. That small a project should open in a snap. So, from #2191 I gather that we need steps to reproduce this to be able to tackle it. I've never experienced this. Do you think that what @musikBear describes fits in on your issue?

[EtornaZ]

I have also experienced this problem, and I'd have to agree with @musikBear. It seems to be the exact problem he described.

[fyrebreak]

I acknowledge and understand the bug that @musikBear was talking about.

However as for my case the loading was rather not interrupted, but not complete. For instance the very first track (at the top) has one random song editor block missing upon full loading of the entire project.

[musikBear]

@fyrebreak

However as for my case the loading was rather not interrupted, but not complete.

That is the case. After un-interupted loading 'fake-blocks' will be missing. They do not need to be the last one added, nor does they need to be acting strange in the project (except for copy behaviour)
Eg

If the song-editor block is still playing notes could it still be fake?

Yes, they exists as completely normal blocks IN the project, but it would be a logical way to explain the bug as "fake-blocks are not written to file, when save is pressed"
So you cant identify a fake-block, unless you attempt to copy the block. Copying will not happen, then move the block side to side, re-attempt to copy, and if it is a success the block is now 'normal'

As i said i recorded it: https://www.youtube.com/edit?o=U&video_id=4U6EtpvfUcA

[fyrebreak]

Thanks @musikBear . I think that should be the bug I was talking about.

If there is already an awareness of this issue then I shall interfere no longer. Thank you!

[zonkmachine]

Can anyone of you save such a defective project, in .mmp format, zip it and attach it here?
The smaller project the better.

[zonkmachine]

Incidentally this just happened to me for the first time. I created a triple oscillator track with one note, cloned this track and dragged the note of the new track to a new position. Upon cloning the track once more this third track turned up with an all empty track. When saving and comparing the project with a reconstructed file, as it was intended, the only difference is the missing pattern.

https://gist.github.com/zonkmachine/b2d8235918cf6654c2b5c4828279f6f8

--- /home/zonkmachine/Desktop/blankpattern.mmp
+++ /home/zonkmachine/Desktop/fullpattern.mmp
@@ -38,6 +38,9 @@
           <midiport inputcontroller="0" fixedoutputvelocity="-1" inputchannel="0" outputcontroller="0" writable="0" outputchannel="1" fixedinputvelocity="-1" fixedoutputnote="-1" outputprogram="1" basevelocity="63" readable="0"/>
           <fxchain numofeffects="0" enabled="0"/>
         </instrumenttrack>
+        <pattern steps="16" muted="0" type="1" name="TripleOscillator" pos="0">
+          <note pan="0" key="54" vol="100" pos="36" len="12"/>
+        </pattern>
       </track>
     </trackcontainer>
     <track muted="0" type="6" name="Automation track" solo="0">

[zonkmachine]

The earliest account of this issue could be from the old bug tracker, issue 3585927, as mentioned in https://github.com/LMMS/lmms/pull/3692#issuecomment-314916491.

[musikBear]

Incidentally this just happened to me for the first time.

@zonkmachine that is sooo strange it should happen now 😮 -But was that also on 1.1.3 or have you now seen this on rc4, and what OS?
__
btw i have NO method for reproducing, and has so far not seen it in rc4, only 1.1.3

[StinaIsNormallyDistributed]

Still having this issue, 1.2.0-rc5.17 on Arch (4.15.3-1)
8G Ram, i5-6200U
Intel Corporation Sunrise Point-LP HD Audio (rev 21)

[DomClark]

Steps to reproduce:

• Create a new instrument TCO (or use an existing one, but be careful not to break your project!)
• Click on the very right of the TCO. If successful, the cursor should remain a hand cursor, and not change to a move cursor.
• Try to copy the TCO. It should fail, creating an empty TCO instead. (You can also save and reload the project to see that the TCO is missing, as in the original report, but as musikBear observed, these situations are equivalent.)
  

  Cause:

The journalling for the block is turned off, which means it does not get serialised:
https://github.com/LMMS/lmms/blob/dbf5f47149fbb7584bf48ce9e767b9e90ee2df7e/src/core/JournallingObject.cpp#L67-L83
The journalling is meant to be disabled on mouse-down on the TCO, and re-enabled on mouse-up.

void TrackContentObjectView::mousePressEvent( QMouseEvent * me )
{
// ...
    else if( me->button() == Qt::LeftButton &&
        /*  engine::mainWindow()->isShiftPressed() == false &&*/
                            fixedTCOs() == false )
    {
// ...
        // move or resize
        m_tco->setJournalling( false );
// ...
        if( me->x() < width() - RESIZE_GRIP_WIDTH )
        {
            m_action = Move;
// ...
        }
        else if( !m_tco->getAutoResize() )
        {
            m_action = Resize;
// ...

```cpp
void TrackContentObjectView::mouseReleaseEvent( QMouseEvent * me )
{
// ...
if( m_action == Move || m_action == Resize )
{
m_tco->setJournalling( true );
}
// ...

The journalling is re-enabled on mouse-up if the action is `Move` or `Resize`. The action is set after disabling journalling on mouse-down. However, it is possible for both of the conditions there to be false, in which case no action is set and the journalling gets stuck off. This happens when you click on the resize grip part of a TCO, but the TCO is not one that can be manually resized.

I guess more sensible/intuitive/correct behaviour would be to disable the resize grip if the TCO cannot be resized, which should just involve changing the conditions like this:
```cpp
void TrackContentObjectView::mousePressEvent( QMouseEvent * me )
{
// ...
        if( me->x() < width() - RESIZE_GRIP_WIDTH || m_tco->getAutoResize() )
        {
            m_action = Move;
// ...
        }
        else
        {
            m_action = Resize;
// ...

[zonkmachine]

Great! Any idea where it happened? I can't replicate this in 1.1.3 .

[DomClark]

It looks the code in src/core/Track.cpp which leaves journalling turned off was introduced in e81c970. The code in src/core/JournallingObject.cpp which disables serialisation of objects with journalling off was introduced in c3c5501.

It looks like in 1.1.3 that instrument TCOs were not correctly flagged as auto-resized, which meant that the second condition in mousePressEvent was always true. You can see in 1.1.3 that when following the second step above, the resize cursor appears, and dragging from there shows a text float indicating that the TCO is being resized (although it isn't). This was fixed in 86c2673, which is probably when the bug first appeared.

I can't find any evidence of this bug occurring in 1.1.3 - the only such report is from musikBear in a comment above, but if you look at the issue he linked (#2191), he was using the master branch. That issue was opened six months after the commit that probably introduced it.

[DomClark]

Fixed in #5537.

[zonkmachine]

but if you look at the issue he linked (#2191), he was using the master branch

Yes, the master branch labelled after the last merged stable is pretty confusing.

which leaves journalling turned off was introduced in e81c970

Right. Jurassic code.

Thanks for fixing this.