View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001246||OpenMPT||[All Projects] User Interface||public||2019-08-11 16:40||2019-09-20 06:44|
|Reporter||dem1||Assigned To||Saga Musix|
|Product Version||OpenMPT 1.28.06.00 / libopenmpt 0.4.6 (upgrade first)|
|Target Version||OpenMPT 1.28.07.00 / libopenmpt 0.4.7 (upgrade first)||Fixed in Version||OpenMPT 1.28.07.00 / libopenmpt 0.4.7 (upgrade first)|
|Summary||0001246: Entering chords using multiple Record Select channels with a large Edit Step causes notes to fall on the wrong row|
The chord detect interval does not work how I expected when the Edit Step is large enough to move the active row past the end of the pattern. Please refer to the attached IT module, which has one pattern with 64 rows. I set the first three channels to Record Select, and entered four chords by mashing keys. The chords at rows 0, 16, and 32 are fine. The chord at row 48 has two notes placed at row 47, which is problematic if "record Note Off" is enabled.
|Steps To Reproduce|
Create New (I have tested with IT and OpenMPT Module so far)
|Tags||No tags attached.|
|Has the bug occurred in previous versions?||1.28.04.00|
|Tested code revision (in case you know it)|
Edit Step Bug.zip (52,597 bytes)
I found a workaround for now: turn off continuous scrolling. (see line 5085 of View_pat.cpp).
Also, when continuous scroll is enabled and there is another pattern ahead, chord detect interval does not work as advertised:
"If you have the Pattern Editor’s Edit Step setting set to some other value than 0 and have a record group set up, OpenMPT will put all notes detected within the Chord Detect Interval on the same row, regardless of the Edit Step setting, i.e. the notes are interpreted as a chord."
The first note is placed on the row, the cursor jumps ahead by the edit step (into the next pattern), and since continuous scroll is enabled, the pattern does not jump back (in fact, it looks like the code to make the jump back, starting on line 4883, assumes the pattern did not change after placing the first note). Instead, the second note is placed in the second pattern.
Yes, it does not work as advertised because it's buggy. The problem basically is that the chord detect interval has to "undo" the pattern change; this currently not possible because it doesn't remember in which pattern the chord was started. Fixing this is probably as trivial as remembering the current pattern in which a note is entered.
Please try r12065, it should fix the issue.
It works great, thank you!
12066 is the backport for OpenMPT 1.28 (rather than bleeding-edge 1.29) but apart from that it's the same. Good to hear that it's working.
|2019-08-11 16:40||dem1||New Issue|
|2019-08-11 16:40||dem1||File Added: Edit Step Bug.zip|
|2019-09-19 04:36||dem1||Note Added: 0004075|
|2019-09-19 20:57||Saga Musix||Note Added: 0004077|
|2019-09-19 21:22||Saga Musix||Assigned To||=> Saga Musix|
|2019-09-19 21:22||Saga Musix||Status||new => feedback|
|2019-09-19 21:22||Saga Musix||Note Added: 0004078|
|2019-09-19 21:22||Saga Musix||Target Version||=> OpenMPT 1.28.07.00 / libopenmpt 0.4.7 (upgrade first)|
|2019-09-20 03:26||dem1||Note Added: 0004079|
|2019-09-20 03:26||dem1||Status||feedback => assigned|
|2019-09-20 06:43||Saga Musix||Note Added: 0004080|
|2019-09-20 06:44||Saga Musix||Status||assigned => resolved|
|2019-09-20 06:44||Saga Musix||Resolution||open => fixed|
|2019-09-20 06:44||Saga Musix||Fixed in Version||=> OpenMPT 1.28.07.00 / libopenmpt 0.4.7 (upgrade first)|