On Tue, Aug 17, 2010 at 9:22 PM, Tim E. Real <[email protected]> wrote: > So, a related TODO I forgot to mention, which would have been the solution > to the above sizing problem (had we used GtkScale's own label), > is this: > > We want to grab the width of a worst-case string like +88.88 (I guess simply > by asking pango) before creating all the labels (or after a theme change). > Then, add a single "size-request" handler for all the labels and make sure > they *never* alter from this worst-case width (+ a few border pixels). > That should keep everything fixed in place.
This is far more complicated than it needs to be. I setup all the numeric labels to use monospace fonts, which by definition, are the same size for all characters. And I ensured that the number of characters in the numeric label at creation time remained the same as the number of characters that it could be set-to throughout the life of the application. That means ensuring all outputs are text-formatted to produce the same number of characters width, no matter what the input. The issue here would simply be done by padding "-9.9" as either "-9.90" or "-9.9 " such that when "-10.0" gets displayed, it's the same number of characters. Monospace labels will handle the rest. I really don't think explicit string geometry calculations should ever be needed in computing dynamic labels like this -- the widget is supposed to handle that at initialization time and size itself based on the skin/fonts/etc.... It's also distracting to use proportional spaced text for such dynamic numeric labels as they'd end up wobbling around, so even if it wasn't for the sizing issue, i'd still want to use monospace fonts and labels that don't change their width, for dynamic numeric labels. The issue of max width or min width isn't important. What's important is to prevent the widget from resizing in the first place. There's also significant inefficiency if labels are resizing unnecessarily, as there ends up being potential resize requests being passed up and down the widget hierarchy. >> I will test the Terratec DMX6fire next... > Now I'm wondering what happens if the analog ALSA control names change. > Would different codecs have different control names? DMX6Fire works fine. I think the control names are just different numbers.... The Dmx6fire has hardcoded names/labels in envy24control.c for particular inputs, instead of just being 1..N. > Maybe that's why that card you mentioned before didn't have an analog page? I believe cards with no analog controls will have no "Analog Volumes" page. The not-fully-supported-by-alsa Edirol DA2496 ( http://www.soundonsound.com/sos/aug02/articles/edirolda2496.asp ) driver the person was using didn't correctly describe the codecs on his card, so it was as if there was no analog section or codecs to control. Note that some alsa-supported Envy24 cards are certainly missing analog controls -- those with only digital/ADAT ports such as the Event Electronics EZ8 ( www.event1.com/Support/Manuals/EZ8_MANUAL_V1_0.pdf ) and the Terratec EWS88D ( ftp://ftp.terratec.de/Audio/EWS/88D/Manual/EWS88D_Manual_GB.pdf ). For such cards, "Monitor Inputs" and "Monitor PCMs" would be useful with peak meters, and there'd be no "Analog Volume" panel, nor any possibility of combining the mixer and dac or adc controls onto the same page. > Was it worth my effort, to ask ALSA for the ranges to set the analog > sliders/markings instead of hard-coding them? Was my assumption that > different codec chips might have different ranges correct? We'll see... Almost all the Envy24 cards I've seen have the same controls on the ADC's and DAC's so it's possible that my hardcoding would have worked in the majority of cases. I'm not sure about the M-Audio Audiophile 2496. http://www.soundonsound.com/sos/apr01/articles/soundcard.asp indicates the Audiophile2496 doesn't have the adjustable ADC gain, just pro/consumer, whereas the similar Terratec EWX2496 does: "One useful set of controls here, not found in the Audiophile, is a pair of faders to adjust Analog In Gain from the default 0dB setting in 0.5dB increments right up to +18dB." See the soundonsound article for pictures and detailed description of the windows control software for the two cards. It would be nice if someone with an M-Audio Audiophile 2496 could test this latest version of "mudita24" and send snapshots of what the "Analog Volumes" panel look like and whether it's correct. Even the latest Envy24-based designs seem to talk about +18dB controllable gain on the ADC's, for example: http://www.musonik.com/index.php/terrasoniq-ts-88.html . Seems like one major difference is that some cards have consumer/-10 pro/+4 level setttings available for the analog section (e.g. ftp://ftp.terratec.net/Audio/EWS/88MT/Manual/EWS88MT_Manual_GB.pdf ftp://ftp.terratec.net/Audio/EWX/2496/Manual/EWX2496_Manual_GB.pdf ). > The wheel seems to move by 3dB whereas the keys move it by 1.5dB. > That GTK_SCROLL_JUMP thing stopped me in my tracks. > Hopefully there's a style property or something... Yes, I just noticed this testing on the machine w/ the Dmx6fire and the regular mouse w/ scrollwheel. It would be very nice to have the scroll increment/decrement the same as the keyboard up/down. One additional problem noted regarding the scroll wheel. You can set focus by clicking in the labels/marks area of the slider, and key up/down/pageup/pagedown events are passed on to the scale widget correctly. Unfortunately, scroll-wheel events are not passed on even though the scale widget has the focus. You have to explicitly click in the scale widget in order for the scroll wheel to work. -- Niels http://nielsmayer.com _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
