.45 Channel Volume changes after reordering channels

LPChip · December 21, 2006, 15:40:51

When you use the channel manager to reorder channels, you virtually move those channels around in the song.

If you have different channel volumes per channel, and you reorder those, the current state of those channels is being kept, untill you play the song from start.

Lets say:

before you order the channels:

Channel 1 has 64 volume
Channel 2 has 64 volume
Channel 3 has 10 volume
Channel 4 has 30 volume

You play the song and at this moment it sounds correct.

Now you reorder Channel 4 to be before channel 2.

So:

Channel 1 was 64, now is 64.
Channel 2 was 64, now is 30.
Channel 3 was 10, now is 64.
Channel 4 was 30, now is 10.

This behavor is expected, but, until you replay the song from start, what is supposed to be 30 volume is played at 64 which is way too loud. What is supposed to be playing at 64 is being played at 10 which is almost silent, etc...

A fix would be to trigger a volume initialise during the channel reordering process.

EDIT: even worse... Untill the song is restarted, changing the volume for the old channel will result in changing the sound on the new

So If i change the volume of channel 3 (10), the content of channel 4 changes of sound.

rewbs · May 13, 2007, 13:51:34

Please confirm this is fixed.

LPChip · May 13, 2007, 14:58:30

If you place a volume command on a channel so it becomes softer, and then remove the volume command, everything is set to reproduce this bug.

If I then open the channel manager, switch 2 channels, and hit apply, the channels are swapped, but the volumes are unaffected, meaning that the one that was soft, is soft, and the other is hard. Now If I put one channel volume in it, it misteriously is being corrected.

I therefor say that the big hasn't been fixed, and putting it back to open.

I would like to see it so that when you hit apply, it changes in the song, but not in the audio.

Relabsoluness · May 13, 2007, 16:11:27

Quote from: "LPChip"If I then open the channel manager, switch 2 channels, and hit apply, the channels are swapped, but the volumes are unaffected, meaning that the one that was soft, is soft, and the other is hard.

So if you have e.g.
Channel 1: vol 64 (meaning both channel setting(in general tab) and the actual channel volume)
Channel 2: vol 10
and then swap 1<->2, the channel swap is intended to work so that after the swap
Channel 1: vol 10
Channel 2: vol 64
What I tested, it seemed to work like this - did you have different behavior?

Quote from: "LPChip"I would like to see it so that when you hit apply, it changes in the song, but not in the audio.

I don't get the "changes in the song, but not in the audio" part.

LPChip · May 13, 2007, 20:42:37

No, I did it as follows:

General tab:

Channel 1 = 64
Channel 2 = 64

In a pattern, I put a m10 in channel 1 and play it. Then I remove the m10 and keep playing.

Now, I open the Channel manager, and switch the two, and tada, the volume of both changed.

Even stopping and starting the pattern doesn't fix that. Its quite annoying actually, as you don't want to search through the song to find that m10 row again to initiate the right volume setting.

Relabsoluness · May 13, 2007, 23:12:00

Quote from: "LPChip"Now, I open the Channel manager, and switch the two, and tada, the volume of both changed.

The volume of both pattern channels (with indeces i and j) should change, because the 'channel swap' should, with current implementation, do a one-to-one copy of a channel, so that after the swap effectively the only thing that should have changed is that now the 'under-the-hood'channel that had index i, now has index j and vice versa. Is this what you see and find buggy or am I still missing the point?

Quote from: "LPChip"Even stopping and starting the pattern doesn't fix that. Its quite annoying actually, as you don't want to search through the song to find that m10 row again to initiate the right volume setting.

This is actually quite related to (S=O) .46 bug in channel volume - the issue that when channel parameters such as volume are 'resetted'. For example in .46 restarting pattern resetted channel volume to that chosen in general tab, but it was way too dirty hack so it got changed back. As you said in that thread, it indeed might be nice to have somekind of optionality in this matter, but I think I won't touch that matter for while

LPChip · May 14, 2007, 12:21:29

Quote from: "Relabsoluness"
Quote from: "LPChip"Now, I open the Channel manager, and switch the two, and tada, the volume of both changed.
The volume of both pattern channels (with indeces i and j) should change, because the 'channel swap' should, with current implementation, do a one-to-one copy of a channel, so that after the swap effectively the only thing that should have changed is that now the 'under-the-hood'channel that had index i, now has index j and vice versa. Is this what you see and find buggy or am I still missing the point?

Yeah, thats what I mean. The memory values aren't being swapped.

Relabsoluness · May 14, 2007, 23:57:37

Oh I misread one of your posts. So the problem is that when you swap the channels while playing(*), both volumes are 'resetted' while you wouldn't like them to do so, right? If this is the case, it doesn't seems like an actual bug, but instead an unwanted behavior in the way the channel manager restarts play after applying the new channel configuration.

(*) Have you tested doing the swap while not playing?

LPChip · May 15, 2007, 07:40:07

Quote from: "Relabsoluness"Oh I misread one of your posts. So the problem is that when you swap the channels while playing(*), both volumes are 'resetted' while you wouldn't like them to do so, right? If this is the case, it doesn't seems like an actual bug, but instead an unwanted behavior in the way the channel manager restarts play after applying the new channel configuration.

(*) Have you tested doing the swap while not playing?

Well, its not that they are being reset, its that the volumes are not being swapped, so channel 1 which had 64 volume, becomes 10, and channel 2 which had volume 10, becomes 64. (atleast the channel volumes stay the same but the content is swapped, and the volumes are not.

I haven't tested this when the sound is stopped, but after the swap, I stopped and played that pattern, and it was still the same.

I will have to do some testing on stopping, changing and starting.

Relabsoluness · May 15, 2007, 21:47:07

Quote from: "LPChip"Well, its not that they are being reset, its that the volumes are not being swapped, so channel 1 which had 64 volume, becomes 10, and channel 2 which had volume 10, becomes 64.

This sounds contradictory - first it says that "volumes are not being swapped" and then it it says that the volumes are changed on both channels(swapped). So which is it? If the latter is true then its working just the way it's intended to work.

LPChip · May 15, 2007, 22:08:07

Quote from: "Relabsoluness"
Quote from: "LPChip"Well, its not that they are being reset, its that the volumes are not being swapped, so channel 1 which had 64 volume, becomes 10, and channel 2 which had volume 10, becomes 64.
This sounds contradictory - first it says that "volumes are not being swapped" and then it it says that the volumes are changed on both channels(swapped). So which is it? If the latter is true then its working just the way it's intended to work.

The volumes are not being swapped, but you hear as if they were, because the channel data swapped. I didn't know how to properly explain this.

Relabsoluness · May 15, 2007, 22:37:58

Quote from: "LPChip"The volumes are not being swapped, but you hear as if they were, because the channel data swapped. I didn't know how to properly explain this.

:lol: I'm totally lost now. But since the original bug seems fixed, I'm closing this bug - maybe this new one deserves a new report.

LPChip · May 16, 2007, 07:20:04

Quote from: "Relabsoluness"
Quote from: "LPChip"The volumes are not being swapped, but you hear as if they were, because the channel data swapped. I didn't know how to properly explain this.
:lol: I'm totally lost now. But since the original bug seems fixed, I'm closing this bug - maybe this new one deserves a new report.

Huh!? No, the original bug wasn't fixed...

What gave you that idea? The original bug is exactly this.

Maybe you've found another way to get to this, and fixed that, but that wasn't what I wanted to report.

I still have to test the case if the pattern isn't being played, but I doubt that it will if its not played, as stopping and then replaying that pattern doesn't seem to change the thing that happened.

I'm going to reopen this. If you really don't want to dig further into this (which I would find really really bad) then you can close it. Otherwise please look into it.

Relabsoluness · May 16, 2007, 19:31:01

Quote from: "LPChip"Huh!? No, the original bug wasn't fixed...

What gave you that idea? The original bug is exactly this.

The bug descriped in the first post I could reproduce in .45, but not in .46 where it's supposed to be fixed.

Quote from: "LPChip"I'm going to reopen this. If you really don't want to dig further into this (which I would find really really bad) then you can close it. Otherwise please look into it.

Yes I've looked into the original bug and to me it seems fixed, but I really don't get what is the bug so its hard to take a look at it.

rewbs · May 16, 2007, 20:16:02

LP, I suggest you supply a link to a minimal testcase (e.g. if you can, recreate the bug with 1 pattern, 2 channels and 1 note in each channel - resist the urge to show off your nifty melodies) and a minimal sequence of instructions to reproduce the bug on 1.17.02.47.

The reason the testcase is essential is that when you say "Channel 1 has 64 volume" in your original post, I have no idea whether the volume you're talking about is Mxx, the initial channel volume set in the general tab, volume set in the volume column etc...