Better transport/playback/playhead behavior

[musikBear]

Edited by @tresf

• Global playback/transport A Better Transport #1357 [Milestone: 1.3]
• Project should remember the last-used playhead behavior per Saving condition of playback management button #4192, Fix #5461 and ensure consistent use of check gate #5475
  • Piano roll should also remember playhead behavior Playhead stop-behavior isn't saved for piano roll #5938 [Milestone: 1.3]
• Better keyboard shortcut behavior when mixer is in focus Mixer playback shortcuts #1140 (related: New default shortcuts (table) #1488)
• Better keyboard shorts in general Global transport shortcuts #1144 (related: New default shortcuts (table) #1488) [Milestone: 1.3]
• Proposal to use >> as default playhead behavior Better transport/playback/playhead behavior #3740
• Stop and return |<< versus "pause" default behavior Better transport/playback/playhead behavior #3740
• Link JACK transport with LMMS transport When Jack is used, start / stop jack transport #4412
• Stop button should stop ALL sounds Making "Stop" button actually stop ALL sounds #1535 [Milestone: 1.3]
• Playback should stop at the end of a track The playback head does not stop #4643
• Position indicator and line behavior inconsistent between Song-Editor, Piano-Roll, Beat/Bassline and Automation Editor Automation editor in playBack -Moving Playhead? #857, Link Piano-Roll editor and Automation editor playback #2123, Position indicator and line behavior inconsistent between Song-Editor, Piano-Roll, Beat/Bassline and Automation Editor #3052

See also:

• Better MIDI support: Better MIDI support #1472 [Milestone: 1.3]
• Better JACK support: Better JACK support #1467 [Milestone: 1.3]

---

Original bug report, modified by @tresf for readiblity

LMMS has 3 play-head behaviours |<< , << , and >>. Currently |<< is selected as default butI think it will be best if it is >> that is default.

Really often i start playing a track, then i hear a [part that needs correction] and hit [space]. I should have [clicked pause] but that's a mouse-event, and intuitively space is pressed. [Unfortunately] the play-head jumps to [the beginning of the track]. If >> was default the play-head would [behave like pause by default]. [The Home key can still be used to quickly jump to the beginning of the track.]

This is why i believe that >> is the best option for default behaviour, it is simply inducing fewer arghh situations :)

[tresf]

I too find this default behavior intolerable when editing a track.

[Spekular]

Isn't the real solution here to add a keyboard shortcut for pause? If the stop button doesn't move the cursor back to start there's no real reason to have it there instead of just having a pause button.

…

On Jul 31, 2017 17:17, "Tres Finocchiaro" ***@***.***> wrote: I too find this default behavior intolerable when editing a track. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3740 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIgVmoiznS_A5KuZkvtbmclFpfAvhdXcks5sTfAOgaJpZM4OoiHT> .

[zonkmachine]

Isn't the real solution here to add a keyboard shortcut for pause?

Yes. There was a PR/patch submitted for this some six months ago. I'll do some digging.

[zonkmachine]

I remembered it wrong. It was this one teknopaul@1f9a610
No pause key in there but some improvements nonetheless.

[Umcaruje]

I also don't like the default behaviour But I use << when working. I think LMMS should just preserve this setting across sessions and tracks, that way everyone can set it however suits them the most.

[husamalhomsi]

Related: #3288.

I agree with Spekular and Umcaruje.

I was going to suggest that we use "Alt + Space" in Windows and "Command + Space" in macOS because these keys are very close to each other and they're name descriptive because we are altering what a normal "Space" would do, which is stoping, but "Alt + Space" in Windows is used for pop up window menu, unfortunately.
I suggest we either use Ctrl + Space or Shift + Space. These shortcuts are not used by the system in the major operating systems. I prefer Ctrl + Space because they are on the same row and closer to each other than Shift + Space.
Or we can use "P" like Audacity, but that's a bad idea, and Audacity's playback system is different from LMMS's.

I think LMMS should just preserve this setting across sessions and tracks

There are a lot of settings that are also not preserved but should be, like the timeline position.
This deserves another issue.

[tresf]

As part of a pruning effort, this enhancement (and all of the bugs that it consolidates) are archived into a dedicated "Better Workflow" checklist here #4877.

[musikBear]

@Sawuare wrote

Or we can use "P" like Audacity, but that's a bad idea

How about
static Qt.Key | Key_Pause
The key top, outmost right on qwerty kb?
If that is acceptable(?), i will ask for assignment to implement that key for pause

[zonkmachine]

If that is acceptable(?), i will ask for assignment to implement that key for pause

I believe there is an assignment for this in one of the duplicates for play/pause behavior. You also have three assignments already and you're kind of new to lmms developing so maybe you should focus on those ones before taking on any new tasks?

[zonkmachine]

#5301
#5332

[musikBear]

@zonkmachine wrote

maybe you should focus on those ones before taking on any new tasks?

I have made them

Done

• Humanize note-pos and humanize velocity
• new default envelope for general instrument-class
  Also done
  (needs a new default template that uses a new 3oc, but that is very simple

So 'slate empty' thats why i asked.

[zonkmachine]

Done

Done where? That's a screenshot. Of what? We need to see the actual code. If it's not merged it's actually not done. Here, no code here: https://github.com/LMMS/lmms/pulls/musikBear

Just push your branches to your github lmms fork and then via the github web interface you open a pull request.

[musikBear]

You are correct i have not made any PR. I thought it was to little for a PR, and asked on 'Discord, when it was common to make PR, answer was no rules, make one when you like.
I will make one then.

[tresf]

I thought it was to little for a PR

That's in regards to PR vs. committing directly. If you commit directly, you can still link the commit here! Note, only admins and developers have the ability to commit directly, so a PR is the ONLY way to do it if you're not in those two groups. If it's a small commit and slated against another PR, reference it here. We should always be able to attribute the bug to a code change.