LMMS / lmms

Cross-platform music production software
https://lmms.io
GNU General Public License v2.0
7.81k stars 987 forks source link

Blocks can disapear at random #2191

Closed musikBear closed 8 years ago

musikBear commented 8 years ago

win32 Master 12.07.15 So far i have no ways to reproduce. This happens at random

The situation is that blocks can exist but not being recognized, and not saved as seen in related #2147 (which need to be reopened) a block can exist in song-editor, but not being recognized as a real object But! It replays inside its own pianoroll -eg there is no warning, that this block is fake! If the project is saved with such a 'faker-block', the block is simply not included in the saved file, and will have disappeared, the next time the project is opened. How a block can replay, but not being copy or saveable, that is the thing that needs to be investigated.

Umcaruje commented 8 years ago

@musikBear I consider this a duplicate of #2034 - do you agree?

as seen in related #2147 (which need to be reopened)

You know you can reopen your own bug reports, right? There's that shiny 'Reopen' button on the end of the page. There is no need to post duplicates for your own bug reports.

musikBear commented 8 years ago

I consider this a duplicate of #2034 - do you agree?

@Umcaruje No, this is different. From 2034 tresf says

His problem is the opposite as it reads, his blocks are being explicitly deleted and they still play.

in This bug, a block will be lost even though it playback in pianoroll!!!!* but properly not in song-editor. That part i still havent nailed, because there is no warning. So in summery: 2034 describes blocks that are user-deleted (explicitly deleted) and are 'invisible' but DO play! This describes blocks that are visible before** normal saving, but are completety gone visible as well as logical, when the project is reopened - The block in question is lost, for good. This bug is however intimate linked to 2147, because the appearance of 2147 will result in both.

iow If a block cant be copied (video & 2147) that same block will be lost, next time the project is reopend (this report) The real problem is that, so far, there is no obvious event-based reason for the appearance of the bug -It is random, and i cant figure out a test-methodical sane way to hunt for it, other that just use lmms...

and

You know you can reopen your own bug reports, right? There's that shiny 'Reopen' button on the end of the page. There is no need to post duplicates for your own bug reports.

I think that is because you have high access-rights (Owner). I do not have that button :)

musikBear commented 8 years ago

I have managed to capture the second copy-behavior where empty blocks appear when full-'faker'-blocks are dropped

This picture shows the large noteblock hold in ctrl+lm, and ready to be dropped

vlcsnap-2015-07-22-16h41m46s503

Here it has been dropped, but there is only an empty container-block, there is no block with the notes vlcsnap-2015-07-22-16h40m53s393

The 'parent-block' played in both piano-roll, and in song-editor! But it did not behave as a logic noteblock, after the project was saved and reopend, the parent-block was not included in the file.

I also have low-Q video of the full behavior

tresf commented 8 years ago

I think the symptoms can be explained a bit easier to understand. By "CTRL + LMB" you simply mean, Copy/Paste, right? .. or is this bug only reproducible with shortcut keys?

And by "empty container block", you mean "Paste to another track", right? I would recommend you clean this up a bit so others can reproduce. The dedication is noble, but we'll need to have the clear steps to reproduce, and a good bug report should be updated to reflect that.

tresf commented 8 years ago

Also, in this case, they don't disappear, they are pasted as blank blocks and therefore are displayed incorrectly, right? Or do they eventually disappear?

musikBear commented 8 years ago

you cant reproduce - its a completely random occurrence wheater or not it is the same with context-option copy/paste, i will have to test if it re-occur, i expect it will

Also, in this case, they don't disappear,

It is, as written the PARENT block that disappear Not the block that was copied, but the block that was copied from It does not exist logically

tresf commented 8 years ago

It is, as written the PARENT block that disappear

"source" and "destination" would be a more proper term, "parent" is confusing and inaccurate as there is no child/parent relationship with copied patterns.

Either way, the title and description needs improvement and that's on you.

tresf commented 8 years ago

I understand this is a problem that randomly crops up from time to time, but to fix it, we need steps to reproduce. Please reopen when you have properly written steps to reproduce. If it can only be created randomly, then please accept that we will close this at a random time in the near future (when someone randomly stumbles upon the offending code).

musikBear commented 8 years ago

This will be an issue for 1.2, IF! Master still has this problem. I just looked in a project and to my surprise, a block that i worked om yesterday, was not there anymore ..and yes - i did save before closing ..

tresf commented 8 years ago

When you have steps to reproduce, we'll work on this.

StakeoutPunch commented 8 years ago

I think that is because you have high access-rights (Owner). I do not have that button :)

For future reference: image

musikBear commented 8 years ago

@StakeoutPunch nice reference, but i may be stupid, but not a complete idiot :package: noreopen

I do not have that button :) Not even my trusty firefox can 'find' it -not as object, nor as code on page.

musikBear commented 8 years ago

I have news in respect to the behavior. Unfortunately, not a method to reproduce, but i have found a way to make lmms recognize the dodgy block. A block with the fault has this 'no-copy' & 'no-saving' behavior, but it is still movable After it has been moved a couple of bars in song-editor, it is again recognized by lmms, and can now both be copied and will also be saved. This is imo interesting, and perhaps a dev can see something in this, that could point to where the actual flaw comes from?