Sound balance options mislabelled and misunderstood?

[ToBul]

Related to #270 and #187

It seemed odd to me that the gui has 3 sound balances,
Balance, BalanceLeftRight and BalanceFrontRear.
Yet the help output says the -balance switch controls front to rear,

So I searched the source for just balance to see what it actually controlled.
In Src\Sound\SCSP.cpp it talks of master and slave scsp chips,

/*
 * Compute relative master/slave SCSP balance (note: master is often used
 * for the front speakers). Equal balance is a 1.0 scale factor for both.
 * When one SCSP is fully attenuated, the other's samples will be multiplied
 * by 2.
 */
float balance = std::max(-100.f,std::min(100.f,s_config->Get("Balance").ValueAs<float>()));
balance *= 0.01f;
float masterBalance = 1.0f + balance;
float slaveBalance = 1.0f - balance;

Does this mean -balance is actually controlling the 2 layers of scsp sounds? I guess that would explain all the complaints about sounds missing for the last few years?

Here's a Lost World save state just before the music plays, if you play with the Balance slider fully to the right you'll see what I mean.

lostwsga.zip

Also in dayto2pe depending on whether you have the Balance slider all the way left or all the way right, you can make either the "pick your car guy" or the pit boss silent, which is another common complaint.

TLDR:
The sound balance labels and descriptions are wrong/misleading.
Also it would be nice if there was an actual frontrear command line switch as I don't think there is one?

[trzy]

I need to look at this to see if we can simplify or rethink the confusing balance options as I don’t remember how they work anymore. One of them was unused I thought.I don’t see how this affects Lost World though as by default the balance is equal. Unless people are changing the balance globally, which is again why we have per-game settings in Supermodel.ini (and when you open the .ini, it’s pretty clearly shown how to create per-game settings).Sent from my iPhoneOn Sep 28, 2025, at 2:13 PM, ToBul ***@***.***> wrote:ToBul created an issue (trzy/Supermodel#272) Related to #270 and #187 It seemed odd to me that the gui has 3 sound balances, Balance, BalanceLeftRight and BalanceFrontRear. Yet the help output says the -balance switch controls front to rear, balances.jpg (view on web) So I searched the source for just balance to see what it actually controlled. In Src\Sound\SCSP.cpp it talks of master and slave scsp chips, /* * Compute relative master/slave SCSP balance (note: master is often used * for the front speakers). Equal balance is a 1.0 scale factor for both. * When one SCSP is fully attenuated, the other's samples will be multiplied * by 2. */ float balance = std::max(-100.f,std::min(100.f,s_config->Get("Balance").ValueAs<float>())); balance *= 0.01f; float masterBalance = 1.0f + balance; float slaveBalance = 1.0f - balance; Does this mean -balance is actually controlling the 2 layers of scsp sounds? I guess that would explain all the complaints about sounds missing for the last few years? Here's a Lost World save state just before the music plays, if you play with the Balance slider fully to the right you'll see what I mean. lostwsga.zip Also in dayto2pe depending on whether you have the Balance slider all the way left or all the way right, you can make either the "pick your car guy" or the pit boss silent, which is another common complaint. TLDR: The sound balance labels and descriptions are wrong/misleading. Also it would be nice if there was an actual frontrear command line switch as I don't think there is one? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[dukeeeey]

I honestly don't understand all the balance options. For Bart, if you remove these they'll disappear from the gui

Supermodel/Src/OSD/SDL/Main.cpp

Line 1511 in 4e5905f

config.Set("Balance", 0.0f, "Sound", -100.f, 100.f);

[ToBul]

I think the -balance switch was the old hacky way of producing a pseudo quad sound.
Probably should of been removed when the real quad processing was added.

About the "per game" ini settings; I don't think the new ui respects them and I imagine it will be hard to make it do so.
Supermodel will produce a structured default ini if you don't have one, then when you launch a game it says saving settings to ini.
If you look at the ini after it's saved the settings, its loses it's structure and looks like it's completely rewritten the file instead of updating it. Per game settings seem to be getting lost.

[trzy]

So much to look into… I thought it was preserving the per-game settings. At least it definitely used to! Sent from my iPhoneOn Sep 29, 2025, at 8:54 PM, ToBul ***@***.***> wrote:ToBul left a comment (trzy/Supermodel#272) I think the -balance switch was the old hacky way of producing a pseudo quad sound. Probably should of been removed when the real quad processing was added. About the "per game" ini settings; I don't think the new ui respects them and I imagine it will be hard to make it do so. Supermodel will produce a structured default ini if you don't have one, then when you launch a game it says saving settings to ini. If you look at the ini after it's saved the settings, its loses it's structure and looks like it's completely rewritten the file instead of updating it. Per game settings seem to be getting lost. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[trzy]

@ToBul I just checked and it looks to me like per-game settings are preserved in the file even when it is rewritten.

Here is what I tried:

1. Added this before the global section:

[scudau]
InputStart1="KEY_A"
Stretch=true

2. Ran supermodel -config-inputs, which showed that P1 Start was mapped to '1' as expected (the Global setting).

3. Ran supermodel roms/scud.zip -config-inputs, which displayed KEY_A for P1 Start. Changed it to S, then quit. The rewritten config file correctly updated the setting only for [scudau] (which was now placed after the Global secton) and preserved Stretch = true.

4. Ran supermodel roms/scud.zip and played the game, confirming that S was now mapped to Start.

This is the intended behavior as I remember implementing it.

I understand that the GUI does not yet respect per-game settings but I do not think it would be difficult to make it do so in the future. It's a bit of a UI challenge but I see there is a disabled "Per Game Settings" tick box already :)

[trzy]

Re: the audio mixing, I'm not sure what to do here. The old Balance option has a stronger effect and the reason is that the math is subtly different. It attenuates one SCSP and amplifies the other. So if one is at 0.5x, the other actually goes up to 1.5x. This is safe because we sum and divide by 2.

This is not quite how BalanceFrontRear works. If the number of host audio channels is 2, there are only stereo left/right buffers and it would be safe to perform the mixing the same way as I did for the SCSP chips.

However, for quad-channel systems (including this MacBook I'm typing on), it's not clear how the different channels should be scaled to achieve the same pronounced effect. We can't multiple any given channel by more than 1.0 or we risk clipping.

Nevertheless, I am leaning toward removing the old Balance option altogether.

[dukeeeey]

I understand that the GUI does not yet respect per-game settings but I do not think it would be difficult to make it do so in the future. It's a bit of a UI challenge but I see there is a disabled "Per Game Settings" tick box already :)

I've already done a bit of work to make this happen. Refactored a lot of the node class to do non const methods.
The plan was something like this
instead of writing all settings to node
write them to node[game] instead.
The only downside of this is it would write ALL settings to node[game]. To fix this I was just going to compare the keys/values with those in node[global] and remove them if they were the same.

I was also going to draw a text box list all the settings that were different from the global section. So if you changed balance it would just show balance in the text box.

My current stumbling point was how to delete keys, ie what to do with
ptr_t m_next_sibling;
ptr_t m_first_child;
ptr_t m_last_child;

That's as far as I got anyway. There are just not enough hours in the day to do all the stuff i want to do lol

[ToBul]

@trzy

I understand that the GUI does not yet respect per-game settings but I do not think it would be difficult to make it do so in the future. It's a bit of a UI challenge but I see there is a disabled "Per Game Settings" tick box already :)

Ah OK, I get it

Your explanation about the different math in the mixing makes sense as I noticed I had to use larger numbers with "frontRear" to achieve the same results as "balance". I am only using stereo though so can't fully test but if users can achieve similar results without the old code it should be OK to remove.
On the other hand, I guess "balance" is a nice extra option but it's just a hack that wouldn't be achievable on real hardware.
If it's kept I guess relabel it as a scsp sound hack so people understand what it is.

@ dukeeeey and trzy
BTW, I appreciate all the time you guys are still spending on Supermodel after all these years.
I can only imagine how many hours you guys have accumulated by now.
The UI is a big change and goes a long way to make Supermodel better and so much easier to understand

[trzy]

Ian: the GUI only shows up at the start right? Why not just read/write from the global and game specific sub trees depending on which way a setting is modified and then proceed to play the game? I forget off hand how I handled this but note that configuring inputs can be done per game or globally and everything is preserved in the output INI file. I don’t think inverting the tree so that each leaf node has a game attribute makes sense but I haven’t looked at your code. Even if the GUI could be brought up mid-game, I believe that it would still be easier to do it this way.

[dukeeeey]

The GUI code will read out all the settings and write them to a node. So if i swap in a game specific node like nodes[game] it'll still do the same. It can work like this I think, but is probably less than ideal. If you write a setting in global, you wouldn't want to make the same change in a game specific node. So if I can detect which options are the same I can simply remove identical options. Then the game specific part will only really have the settings you changed from global.

[trzy]

There shouldn’t be a need to ever modify a setting in two places. I haven’t had a chance to look at the GUI code so I don’t know how difficult this would be but here is what I was thinking… First, as you know, the structure of the configuration tree is Section/Setting (in fact arbitrary levels of nesting are allowed to support loading XML files too). Supermodel’s run time config tree is one level deeper than the section so that all the settings are just directly exposed (“Foo” instead of “Global/Foo” or “scud/Foo”). It’s not sufficient to take just the game’s configuration sub tree because each section is sparse and we only set default values at initialization in the global section. So we need to merge the configuration sections to produce what I call the “runtime config”. There are conceptually three pieces here: 1. Global config 2. Game config 3. Runtime config = global | game In my mind I was thinking the GUI could do the following: 1. Instead of a tick box for per-game, may be clearer to have a tab bar on that row with a “Global Settings” tab and e.g. “scud Settings”. But not strictly needed. 2. When viewing the game settings, *render* the run time config (merged global and game sections). 3. When viewing the global settings, *render* the global sub tree only. 4. When the user changes a game setting, write to game/foo. Then on the next frame, when rendering, feed the GUI renderer the new merged runtime config. Everything should look correct. 5. When the user changes a global setting, write to Global/Foo, and then on the next frame, when rendering, pass in just the global sub tree. So basically, you would have a non-const copy of the config tree that is mutable. The appropriate sub sections are used. Note that the API supports key paths with / so you can do something like config.SetValue(“Global/foo”, “value”). Then you would produce the run-time tree as before. Finally, you would pass two config tree references to the GUI: the mutable one that can be written, a const ref to the one to display, and maybe a section name (Global or “game” depending on which tab or whether the tick box is selected) to help construct the key path to write setting changes to.

[dukeeeey]

The GUI never deals with the runtime config. It just saves the settings to the ini file then supermodel proceeds exactly the same as before, loading the ini file itself and merging the sections. The GUI basically return a command line struct which gives the name of the selected game.

The GUI also works as like 60 or 120hz so it's reading/writing and drawing everything in a continuous loop. It's not event driven like a traditional GUI.

I might be able to pass a pointer to an optional node (game specific) that will write settings if they differ from the global settings, I think that might work. But I still need to be able to delete a whole subsection if the user no longer wants game specific overrides.

[dukeeeey]

My idea was something like this

[trzy]

The tick box would just show the modified settings and then any setting modified while it is checked would apply to the game only? I guess that makes sense. An outer tab might be easier UX to understand, though. So you just want a way to delete a key? Should be doable. I wanted to rewrite the config tree at some point. I am pretty happy with the API but when a non-existing key is looked up, it actually allocates dummy objects, and that is totally wrong. I feel like this could be solved more elegantly and I think I know how but it’s a pretty big refactor of the internals. Anyway, you just need a delete function, correct? Looking at the code now, I think my linked list is pretty dumb. I don’t think it’s needed — that is, I don’t think a given node ever needs to know about siblings. This is only used for iteration, right? The reason I have this is to preserve ordering, I believe. But there’s a better solution I can think of now: - Store a map of key -> child, as we do now. - Also store a vector of child ptrs, in the correct order. - Iterators would store a copy of the vector as well as an index. Iterating would just be a matter of incrementing the index. Dereferencing the iterator would just retrieve the node at the correct index. Then, deleting is easy. It should be as simple as removing the pointer from both the child map and child vector. No more references remain after that and the node gets freed.

[trzy]

I can make the change sometime this week. Note that there is a unit test, Test_Config.cpp. There are some non-obvious features of the config tree namely that you can actually have multiple siblings with the same key. When you look up by key, you’ll only get the last one of course, but when iterating, you’ll get them all in order. That’s required for XML parsing.