View Issue Details

IDProjectCategoryView StatusLast Update
0001698OpenMPTUser Interfacepublic2023-04-29 19:43
Reporterharbinger Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Platformx64OSWindowsOS Version7
Target VersionOpenMPT 1.31.01.00 / libopenmpt 0.7.0 (upgrade first)Fixed in VersionOpenMPT 1.31.01.00 / libopenmpt 0.7.0 (upgrade first) 
Summary0001698: Inputting notes in PE doesnt step to next pattern with Shift
Description

I can't believe in all my years of using modplug that I haven't seen this bug, and I didn't see any previous reports on the matter..

Im using 1.30.03 on an offline Windows 7 64-bit.

I have set up a series of empty orders because I know how many measures I'll need to input (I'm transcribing a score). When I input or enter a note with an edit step that should take me past the current pattern, normally it moves to the next pattern waiting for more input. But whenever my input involves the shift key, it only moves to the end of the current pattern and does not step over into the next one.

Steps To Reproduce

You'll need a keyboard shortcut that enters notes with the shift key as well as a regular key, such as Shift-Z (what i use for C4 at Octave 4).

  1. Prepare two empty patterns in succession. Step count doesnt matter, altho for this example, use an Edit Step > 1.
  2. Starting anywhere in the 1st pattern beginning entering notes with your normal keypresses.
  3. As you approach the last rows of the pattern, begin using the keypress that uses the shift key to enter more notes.
  4. It will not proceed past the current pattern as normal, but simply move the input focus to the last row, refusing to budge until you enter a keypress that doesnt use the Shift key.
TagsNo tags attached.
Has the bug occurred in previous versions?Dont think so, but maybe.
Tested code revision (in case you know it)1.30.03.00

Activities

Saga Musix

Saga Musix

2023-04-29 17:13

administrator   ~0005705

Last edited: 2023-04-29 17:58

Please always update to the latest version before reporting a bug. For all we know, you could have wasted 10 minutes writing a report about a bug that has already been fixed over a year ago (because that's how old OpenMPT 1.30.03.00 is at this point).

To be precise, this has nothing to do with the Shift key as such but with Shift being your selection key. When you hit Shift, OpenMPT goes into selection mode, and because a selection cannot span multiple patterns, any sort of navigation will stop at the pattern boundaries - even if the selection, as far as you are concerned, may not exist, but it's there, it's just 1x1 fields (it's your edit cursor). Maybe we can ignore the selection specificly when applying the edit step, I'll see...

Saga Musix

Saga Musix

2023-04-29 19:43

administrator   ~0005708

As of r19140, the selection key no longer influences cursor wrap behaviour if the cursor move was initiated through the Edit Step feature.

Issue History

Date Modified Username Field Change
2023-04-29 16:49 harbinger New Issue
2023-04-29 17:13 Saga Musix Note Added: 0005705
2023-04-29 17:58 Saga Musix Note Edited: 0005705
2023-04-29 19:43 Saga Musix Status new => resolved
2023-04-29 19:43 Saga Musix Resolution open => fixed
2023-04-29 19:43 Saga Musix Fixed in Version => OpenMPT 1.31.01.00 / libopenmpt 0.7.0 (upgrade first)
2023-04-29 19:43 Saga Musix Target Version => OpenMPT 1.31.01.00 / libopenmpt 0.7.0 (upgrade first)
2023-04-29 19:43 Saga Musix Note Added: 0005708