Piano Roll Playhead Stop vs. Pause

[musikBear]

The 2. playhead behaviour 'go back to pos' (<<) will be different depending weather user chooses to use the Pause-button, or stop-button

~12 bars of notes needed :

Use of stop button/space
switch to <<
place playhead at bar3
press play (space)
play ~4 bars
press stop (space)
playhead will jump correct to bar3 as expected
move playhead with mouse to bar4
play ~4 bars
press stop (space)
playhead will jump correct to bar4 as expected

Use of pause
place playhead at bar3
press play (space)
play ~4 bars
press pause
playhead stops correct at current position
move playhead with mouse to bar4
play ~4 bars
press stop (space)
playhead will now jump incorrect to bar3 and ignore the mousemoved position at bar4

or iow, playhead-behavior ignore start-posistion, if pause has been invoked.

[Umcaruje]

!?

[tresf]

It's been discussed several times over. Sure it's a dupe of a bug somewhere.

[musikBear]

doubt this specific behavior has been up before. The other one is for compulsive scrolling -This one is new
I will try to find the references
@Umcaruje cant you reproduce? -Or do you find it insignificant?

---

Here are those other references:
#656
#1735

[Umcaruje]

@Umcaruje cant you reproduce? -Or do you find it insignificant?

No, I can't understand the issue. I don't have the time to read it 10 times, just to understand it.

[tresf]

More references:

#2236 #2145

@musikBear can you take a look at how I had to re-write your #1735 description? That shouldn't /ever/ be needed in a PRPRLYWRTTN /bug report/.

What should happen is a developer such as @Umcaruje should be able to follow a few simple steps and reproduce.

This below is unacceptable. You have been on the project team long enough that you are one of our leading bug reporters and testers. You should be setting a good example for the rest of the team.

Use of stop button/space
switch to <<
place playhead at bar3
press play (space)
play ~4 bars
press stop (space)
playhead will jump correct to bar3 as expected
move playhead with mouse to bar4
play ~4 bars
press stop (space)
playhead will jump correct to bar4 as expected

Use of pause
place playhead at bar3
press play (space)
play ~4 bars
press pause
playhead stops correct at current position
move playhead with mouse to bar4
play ~4 bars
press stop (space)
playhead will now jump incorrect to bar3 and ignore the mousemoved position at bar4

[musikBear]

WHAT?!?!
its two step by step instructions for the different behaviours for resp. stop and pause.
How i t h can that be wrong?!

[tresf]

How i t h can that be wrong?!

Unacceptable != Wrong.

For example, this above sentence is unacceptable from a quality control perspective, but when I read it enough times, I can decipher what you're shouting!?

[tresf]

its two step by step instructions for the different behaviours for resp. stop and pause.

1. Step 1
2. Step 2

Was that so hard?

[tresf]

How i t h can that be wrong?!

It also lacked the proper research before filing a new report. You haven't made comment yet on whether or not the other bug reports are duplicates of this or how they are related. This puts the burden on the coders, and the coders should be spending their time coding, not managing 1,000 duplicate bug reports. 👍

[tresf]

or iow, playhead-behavior ignore start-posistion, if pause has been invoked.

What is iow ?

Edit: We value your input, but we really need help with the tracker and sometimes your bug reports make things harder than they have to be. Can we work towards better standards please?

[Umcaruje]

Ok so @musikBear

How proper issues should look like

Finding the bug

In your daily endaveours through the mystical paths of music, if you encounter a bug in LMMS, you should first find a valuable way of reproducing it. If there is a non reproducible glitch, it's hard to fix. If it isn't an issue that affects your workflow in LMMS drastically it's not worth submitting in the first place, until you find a way to reproduce it.

Before even looking to make an issue about a problem, Search the issue tracker for the problem you experienced. There is a big chance someone (maybe even you) had the same problem and submitted it.

Issue title

After finding the problem, you should make an issue for it. Issues should have a nice title. No /this/ or Master bug please fix or --this--(asdfg). no need to write everything with no interpunction and small letters. It should look like a sentence, because it is one.

Don't try to put labels in your title. If you are not in the developers group you can't. When someone from the dev team reads your issue, he'll label it properly. If we don't do that in like a week or so, you can politely poke me or @tresf to do it.

Issue description

After a nice title, here's what you need to have in your issue:

Most importantly, your issue should be clean. /There/ _is_ no need to have excessive -formatting-.

Also, your issue should have steps to reproduce the issue. When writing the steps,

• You should use lists
• Lists are much more readable.

1. There are also numbered lists.
2. You can use them too, if you fancy that kind of thing.

If the issue is a graphical bug, you should provide a screenshot or a screen recording of it (preferably as a GIF).

If the issue is a crash, you should go and take a backtrace of it. We have a tutorial for that here. Note that this is not applicable for windows atm, but soon will be.

At the end you should provide your LMMS version, and your OS. If the issue is somehow hardware related (faulty MIDI controller or whatever) provide the name of the hardware that makes that problem.

Nobody needs to know your Processor or your Motherboard or your RAM. 99% of the times that's not needed, so don't put it there. If its needed, someone will ask you to provide that info.

A word or two about enhancement issues and feature requests

When filing enhancement issues, you should also follow the simple rules from above, always search before you make an issue, and have a clean title and description. Note that Please fix these 146 things or Make LMMS work like FL Studio or Add this here cause I said so kinds of issues aren't good and there is a big chance they will be closed.

Your enhancement should be reasonable, and doable in some amount of time. If you just have a vague idea instead of a clear concept, its best that you post on the forums first, to get feedback from users, and then come to the issue tracker when you reach some kind of concept for your idea to be implemented in LMMS.

[tresf]

Closing as duplicate of meta-bug Better Playhead Auto-Scroll #2291. Please feel free to comment here if needed.

[musikBear]

wont report bugs, so dont worry

[tresf]

wont report bugs, so dont worry

Let's not get cynical. Any project this size suffers these quality control issues. It is up to the seasoned bug reporters (such as yourself) to set high standards for those just arriving to the project team. Asking for better bug reports is not an attack against you or any one individual (with the exception of punitive measures taken against repeat offenders) but rather, it's a standard we require to make this tracker work.

The tracker is how the developers manage their work.

We can't afford to have code or code comments that are hard to read, hard to maintain or difficult to understand. What makes a bug report any different?