Lmms: Better transport/playback/playhead behavior

[musikBear]

Edited by @tresf

• [ ] Global playback/transport #1357 [Milestone: 1.3]
• [ ] Project should remember the last-used playhead behavior per #4192, #4556
• [ ] Better keyboard shortcut behavior when mixer is in focus #1140 (related: #1488)
• [ ] Better keyboard shorts in general #1144 (related: #1488) [Milestone: 1.3]
• [x] Proposal to use >> as default playhead behavior #3740
• [x] Stop and return |<< versus "pause" default behavior #3740
• [ ] Link JACK transport with LMMS transport #4412
• [ ] Stop button should stop ALL sounds #1535 [Milestone: 1.3]
• [ ] Playback should stop at the end of a track #4643
• [ ] Position indicator and line behavior inconsistent between Song-Editor, Piano-Roll, Beat/Bassline and Automation Editor #857, #2123, #3052

See also:

• Better MIDI support: #1472 [Milestone: 1.3]
• 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" [e-mail] 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
https://github.com/LMMS/lmms/issues/3740#issuecomment-319099174, 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 https://github.com/teknopaul/lmms/commit/1f9a610bbf29a1f963655b0f6a467f841db00e55
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.

[Sawuare]

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]

https://github.com/LMMS/lmms/issues/5301
https://github.com/LMMS/lmms/pull/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.