in_vgm needs a GUI redesign

[ValleyBell]

The current in_vgm GUI has a few problems:

• everything is crammed together
• There are only 24 check boxes for muting channels. However we have sound chips with 28 and 32 channels, so there are channels that can not be muted currently.
• There are no individual chip options, aside from the sound core. If you want to e.g. change the settings of Nuked OPN2, you need to edit the .ini file.

The cause of this is, at least partially, that I kept the basic layout and some of the dialogues from Maxim's in_vgm 0.35 from 2007. (I'm not a GUI designer, so I went with something that already worked.) See here:

---

So having a new GUI for in_vgm would be nice. I can do all the WinAPI programming, but developing GUI layouts is not something I enjoy doing, so any contributions are welcome.

Screenshots of dialogues would work, I guess. Some Visual Studio dialogue files would be even nicer. The optimal case would be a Win32 resource files (.rc), i.e. what in_vgm already uses.

[ghost]

I was bored yesterday so I came up with these rushed out mockups.

I chose to mostly address problems 2 and 3 by simply turning the Channel Muting tab into a sorta scrollable list (Theoretically allowing for infinite number of channels) as well as also moving the Panning settings into said Muting Tab. (Looking at it now tho, I prob should had made that list be horizontally scrollable)

Because of this, "Other Options" has been now repurposed to act as "Emulation Options", effectively allowing configuring all the options in various emulation cores, with bonus points of also allowing to set Main and Sub cores separately (Like VGMPlay does), thereby sorta addressing Problem 3. Tho I suspect that this might be a little difficult to implement as some of the options will need special handling (Like the Chip Type in Nuked-OPN2, which obviously wouldn't be good idea to do with checkboxes). (And yes, I realized now that the Sub Core Options list is pretty useless for now)

[vampirefrog]

I would begin by removing the tabs from the top, and adding a list on the left, the first two items of the list would be Playback and Tags, and the next items would be all the chips, including the second chips, and for sub-cores you can have an item below each of the chips with sub-cores, starting with a "⮡". This would simplify the dialog itself as a first step.

Seeing as, currently, only the muting and panning controls are present, we can, in this first iteration, put them together like this:

The currently playing chips could have a play icon next to them:

This left list would be scrollable.

[vampirefrog]

The list could be like so:

• SN76496
• YM2413
• YM2612
• YM2151
• ...
• YMF278B
• ⮡ OPL2 FM part
• ...
• SN76496 # 2 (from here the second chips would start, or alternately, have them interleaved with the first ones)
• YM2413 # 2
• YM2612 # 2
• YM2151 # 2
• ...
• YMF278B # 2
• ⮡ OPL2 FM part
• ...

another option is to have headings in the list, similar to:

However, this might be too much

[vampirefrog]

The second iteration can be more comprehensive, and have libvgm list all the options for all the chips, and we'd be generating UI elements depending on the libvgm-provided options, and this would eliminate the need to edit the .INI file, but it would require a bit of data input into libvgm, and some structure to store enough info to render the full control. For example, if the control is a select drop-down box, the C(++) structure would have to list all the possible options. If it is a range control, it would list the minimum and maximum values, and in the UI it would be represented as a slider, and so on.

[vampirefrog]

I would also take into consideration the fact that, if the per-chip/per-core options come from libvgm, then we can use them in a cross-player and cross-platform way, for example, we could have the exact same UI, or at least very similar, for winamp, foobar2000, vlc, and other players (we can reuse the code from ASAP, as they have a large list of targets), and on linux and mac we could use the same UI for whatever linux player allows a custom UI.

On Windows, we can have a separate library, perhaps called libvgm-win32-ui or something similar, that hooks into libvgm and allows you to easily create the UI in whatever context you need, so that would be the reusable UI code in one project. The same can go for Qt, which I think is what VLC uses, we could make a Qt widget that is the vgm configuration page that just has everything on it.