View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001220||OpenMPT||Playback Compatibility||public||2019-04-12 14:53||2019-11-04 08:51|
|Reporter||mrbumpy409||Assigned To||Saga Musix|
|Product Version||OpenMPT 1.28.04.00 / libopenmpt 0.4.4 (upgrade first)|
|Target Version||OpenMPT 1.29.01.00 / libopenmpt 0.5.0 (current stable)||Fixed in Version||OpenMPT 1.29.01.00 / libopenmpt 0.5.0 (current stable)|
|Summary||0001220: incorrect panning behavior in IT files related to initial channel pan|
Open the .it file in the attached .zip ("IT panning test.compat.it"):
Impulse Tracker plays this file as follows (audio file is included in the attached .zip):
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.
|Tags||No tags attached.|
|Has the bug occurred in previous versions?||yes|
|Tested code revision (in case you know it)|
IT panning test.zip (492,460 bytes)
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.
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.
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.
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.
|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 (current stable)|
|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 (current stable)|