On Tue, Aug 17, 2010 at 9:22 PM, Tim E. Real <termtech@rogers.com> 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
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Aug 18 12:15:01 2010
This archive was generated by hypermail 2.1.8 : Wed Aug 18 2010 - 12:15:02 EEST