View Issue Details

IDProjectCategoryView StatusLast Update
0001220OpenMPTPlayback Compatibilitypublic2021-03-16 10:13
Reportermrbumpy409 Assigned ToSaga Musix  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Platformx86OSWindowsOS VersionXP
Product VersionOpenMPT 1.28.04.00 / libopenmpt 0.4.4 (upgrade first) 
Target VersionOpenMPT 1.29.01.00 / libopenmpt 0.5.0 (upgrade first)Fixed in VersionOpenMPT 1.29.01.00 / libopenmpt 0.5.0 (upgrade first) 
Summary0001220: incorrect panning behavior in IT files related to initial channel pan
Description

Open the .it file in the attached .zip ("IT panning test.compat.it"):

  1. There are three channels, with the following initial pan values: 64, 192, 64
  2. There are two instruments, the second of which uses "Set Pan"=32 and also a pan envelope. The first instrument uses neither of these pan settings.
  3. There are two patterns, the first (0) uses only instrument 1 on all three channels, and the second (1) uses only instrument 2 on all three channels.
  4. The patterns play in order 0 - 1 - 0.

Impulse Tracker plays this file as follows (audio file is included in the attached .zip):

  • Pattern 0 (first time): the instrument 1 (piano) notes are panned to the left and right according to the channels' initial pan values.
  • Pattern 1: the instrument 2 (strings) notes are panned around based on the pan settings specified by the instrument.
  • Pattern 0 (second time): the instrument 1 (piano) notes are panned to the left and right according to the channels' initial pan values.

When played in OpenMPT, however, the second instance of pattern 0 plays with centered pan on all channels. So, something about using an instrument with its own pan settings prevents later instruments from playing at the channel's initial pan value.

This test was scaled down from "Over the Clouds" by Deansdale. I have observed similar panning errors in other IT files as well, though I haven't tested yet to see if its the same cause. A couple that I'm aware of off the top of my head include "Nearness" by Bibby and "'You Did', said I" by (M)Rated. I can investigate these further when I get a free moment.

TagsNo tags attached.
Attached Files
IT panning test.zip (492,460 bytes)
Has the bug occurred in previous versions?yes
Tested code revision (in case you know it)

Relationships

related to 0001432 resolvedSaga Musix Odd panning behavior in this module 

Activities

Saga Musix

Saga Musix

2019-04-13 12:06

administrator   ~0003917

Holy crap, this stuff works fundamentally different from what both OpenMPT and Schism Tracker are doing.. thanks for noticing, this is not going to be an easy fix I fear.

mrbumpy409

mrbumpy409

2019-04-13 13:58

reporter   ~0003918

I just confirmed that the panning errors in the two other tracks that I mentioned are caused by the same issue. In "Nearness", the hi-hat that comes in at 0:24 (pattern 9, channel 4) should be centered, not panned right, and in "'You Did', said I", the drum loop that starts at 2:10 (pattern 20, channel 10) should be centered, not panned right.

Looks like the "set pan" values stored in either the instrument or the sample are to be treated locally to the instrument/sample and not actually change the channel pan.

Saga Musix

Saga Musix

2019-04-13 15:27

administrator   ~0003921

Looks like the "set pan" values stored in either the instrument or the sample are to be treated locally to the instrument/sample and not actually change the channel pan.

Yes, that seems to be the case, and I cannot quite understand how I (or anyone from SchismTracker) never noticed that. Luckily we already have a mechanism that could make this easiler to implement; but either way this is quite a big change semantically so it will have to be delayed for OpenMPT 1.29 and will most likely not be backported to OpenMPT 1.28.

Saga Musix

Saga Musix

2019-07-31 21:11

administrator   ~0003985

r11856 / OpenMPT 1.29.00.22 should fix this. It will be available from https://builds.openmpt.org/builds/ within the next few hours.

Saga Musix

Saga Musix

2019-07-31 21:12

administrator   ~0003986

Given that the fix was a bit easier than initially envisioned, there is a chance that it might be backported to 1.28, but not without some thorough testing being done first.

Issue History

Date Modified Username Field Change
2019-04-12 14:53 mrbumpy409 New Issue
2019-04-12 14:53 mrbumpy409 File Added: IT panning test.zip
2019-04-13 11:59 Saga Musix Assigned To => Saga Musix
2019-04-13 11:59 Saga Musix Status new => assigned
2019-04-13 12:06 Saga Musix Note Added: 0003917
2019-04-13 12:07 Saga Musix Target Version => OpenMPT 1.29.01.00 / libopenmpt 0.5.0 (upgrade first)
2019-04-13 13:58 mrbumpy409 Note Added: 0003918
2019-04-13 15:27 Saga Musix Note Added: 0003921
2019-07-31 21:11 Saga Musix Status assigned => feedback
2019-07-31 21:11 Saga Musix Note Added: 0003985
2019-07-31 21:12 Saga Musix Note Added: 0003986
2019-08-24 22:17 Saga Musix Status feedback => resolved
2019-08-24 22:17 Saga Musix Resolution open => fixed
2019-08-24 22:17 Saga Musix Fixed in Version => OpenMPT 1.29.01.00 / libopenmpt 0.5.0 (upgrade first)
2021-03-16 10:13 Saga Musix Relationship added related to 0001432