I'm seeing a bug in Linux under WINE, and I understand that this may be a low priority to address, if at all. Perhaps it's something I can fix on my end by installing another library that other Linux users have encountered.

The problem is in the color selection dialog: the input boxes for the HSL and RGB values only permit two digits. They'll display the full initial value, but changing anything stops at two.

Quote from: Sue Dunham on 2024-04-20 15:15:29

I'm seeing a bug in Linux under WINE, and I understand that this may be a low priority to address, if at all. Perhaps it's something I can fix on my end by installing another library that other Linux users have encountered.

The problem is in the color selection dialog: the input boxes for the HSL and RGB values only permit two digits. They'll display the full initial value, but changing anything stops at two.

I have absolutely no way to replicate or test this. But I do know the implementation. The standard dialog has been extended with the alpha value and slider but anything else is standard Windows. The code that implements that dialog is Microsoft's and has not changed.

So I'd first look into similar bug reports on Wine, preferably those where the application extends the dialog.

I'm using the peak meter, and I had trouble getting the bars to fill the space: there was a blank area to the left, and they only filled half of the space vertically (with a horizontal layout). I have since fixed it, but the fix seemed weird. The relevant settings were on the graphs page, unticking all of the "Top", "Bottom", "Left", and "Right" boxes. These were all grayed out since I had the Mode set to None for both axes, so I had to set the modes to something else to get at them first. Should they still affect things when so idled?

- Vertical scrolling spectogram, aligned with the bars of the spectrum analysis on top.

- Left/Right and Mid/Side level meters with configurable channel pair.

Based on how your plugin behaves/displays I guess you are calculating barwidth (vertical peakmeter) by first determining the total gauge gap by first multiplying the (unscaled) configuration value gauge gap times the number of channels (bars) to be displayed minus 1. Then I guess you scale this total gauge gap, subtract that value from the panelwidth and divide the result by the number of channels to find barwidth per bar. By scaling a calculated unscaled total gauge gap this value will be to high (except winth 200% and 300%), and subsequently your barwidth/barheight will be lower than I intended.
When you display bars, you apply single gauge gaps between channels leading to pixels that are left over and are distributed to the left of leftmost bar and to the right of rightmost bar.

Please investigate ...

Quote from: Defender on 2024-04-19 14:11:34

Based on how your plugin behaves/displays I guess you are calculating barwidth (vertical peakmeter) by first determining the total gauge gap by first multiplying the (unscaled) configuration value gauge gap times the number of channels (bars) to be displayed minus 1. Then I guess you scale this total gauge gap, subtract that value from the panelwidth and divide the result by the number of channels to find barwidth per bar. By scaling a calculated unscaled total gauge gap this value will be to high (except winth 200% and 300%), and subsequently your barwidth/barheight will be lower than I intended.
When you display bars, you apply single gauge gaps between channels leading to pixels that are left over and are distributed to the left of leftmost bar and to the right of rightmost bar.

You don't have to guess. The code is out in the open... ;-) That's almost exactly how the metrics are determined.

Quote from: Defender on 2024-04-19 14:11:34

Please investigate ...

Will do.

    const FLOAT n = (FLOAT) _Analysis->_GaugeValues.size();
    const FLOAT TotalBarGap = _State->_GaugeGap * (n - 1);
    const FLOAT TickSize = 2.f;
    const FLOAT TotalTickSize = (_GraphSettings->_YAxisLeft ? TickSize : 0.f) + (_GraphSettings->_YAxisRight ? TickSize : 0.f);

        const FLOAT BarHeight = ::floor((_ClientSize.height - TotalBarGap - TotalTickSize) / n);

Anyway, I'm happy you are investigating. It's quite easy to spot when you put your scaling to 125% and display a 6ch peakmeter.

Quote from: Defender on 2024-05-02 16:40:13

Anyway, I'm happy you are investigating. It's quite easy to spot when you put your scaling to 125% and display a 6ch peakmeter.

I removed the rounding code. All math is done in DIP not pixels. If you think about it: rounding the values before giving them to Direct2D prevents it from choosing the correct pixel when it's time to create the final picture.

225 DPI with 7 bars and gauge gap of 1 DIP renders correctly now AFAICT.