On Thu, Aug 12, 2010 at 4:57 PM, Tim E. Real <termtech@rogers.com> wrote:
> Specifically the GTKAdjustment->value property is new since 2.4
> so I changed all of lines, and mine as well.
> It means envy24control couldn't possibly have compiled with gtk 1.x could it?
I mentioned it on alsa-dev but no complaints made. Carry on....
> I feel a bit better about us doing these 2.x things now.
I wasn't that worried. In LAU, it was mentioned that it's part of
alsa-tools-gui package in Ubuntu 10.04. So perhaps some distros split
off the gui parts as a separate package, "solving" the dependency
problem that way.
> Panpot would be great, as long as users can get the identical results
> they can get now with two sliders. By that I mean some panpot
> schemes reduce both levels at mid-position but increase
> them as pan is increased.
I wasn't thinking of any fancy fader-curves or anything like that --
just a simple linear sweep from L->R and inversely from R->L for the
other channel. Such that the center position gives the same L/R
capture values as having "L/R Gang" set (which should probably
disappear, and be replaced by having middle click on the panpot set it
to center position.).
> Pan control would need decent resolution, let's not skimp, like some crappy pan controls.
Sort of decent -- we are talking 1.5 dB steps -- as long as it's the
kind where you can just use the given window as the "resolution" once
you click down to move the panpot.
> I guess even with that,
> all scenarios are accounted for by the user adjusting the level,
> so yes, pan = good. So, uh, would we go with pan knob, or slider?
Knob please. With a linear adjustment. I don't like the kind where you
need to have the mouse follow around in a circle to change the value.
And of course moving the scrollwheel while on top of the panpot will
move it as well., as will the up/down and pageup/pagedown commands
while focussed.
> OK, capping off my responses here, let me tell you I dug out my
> MAudio Delta1010LT paper manual. It has been a long time.
> There were some surprises, especially with the Windows envy mixer:
>
> 1) The meters have markings on them from 0 to -48dB,
> so you've done OK there, but the sliders beside them
> go down to -144dB, even though they are the same length
> as the meters ! A readout above the sliders shows the level.
> Here, the meter markings obviously are not to be used as a
> scale for the sliders. So mudita24 is ahead, so far, because
> at least we will attempt to align the meters with the slider scales.
> But we sure won't be able to go all the way to -144dB on the sliders.
> It would look bad with meters only 1/3 the height of the sliders.
> However if we add a user option for minimum slider value, we can
> cover all users' needs if they wish to have it that way.
The big issue with having the full 144dB range is that the "business"
end of the slider is all at the top, and it's difficult to control
accurately by mouse. With the bottom half going from inaudible to
imperceptible... it's not a very good use of screen real-estate.
However, now that the window resizes, what about having the meters
expand more slowly than the slider area, so that you can just make the
window bigger to get the full range? Using your dynamic labeling. In
other words, the bottom part of the slider expands allowing adjustment
below -48dBFS all the way to -144dBFS.
> 2) *All* meters have three zones: green(-48dB to -12dB)
> yellow(-12 to -3) and red (-3 to 0).
> They go into detail about each zone, like when recording
> it is best to stay in the yellow zone, and avoid being in the red zone
> for too long etc. Niels we really need those zones back !
> I would like to take a stab at it. Should be real easy.
I'm not sure about that, other than for eye-candy value. But if you
want to implement it, go for it. Just try to avoid doing a ridiculous
amount of drawing, e.g. drawing color gradations from the bottom line
by line on each change... (which would be computationally equivalent
to the faux-LED meter). For example, copying only the change-region
since last value-rendering, off an already rendered off-screen pixmap
of the desired color gradations across the face of the meter. And
since you're now blitting more bits, perhaps consider setting an X
Clip Region/Rectangle (see XSetClipMask(3), XSetClipRectangles(3)) of
the changed area s.t. you copy the minimum number of bits per change.
And finally, realize that if you want to get all "rainbow color
gradations" consider that someone somewhere may want to use this on a
display with eight bits per pixel -- which is why I was trying to let
Gtk pick the colors as that's its job alongside the skin. So I'd stick
with a standard palette of colors and not a "fade".
Also, I'm not sure how much of that manual verbiage about levels is
"marketing hype" given what I've read about what the ice1712's
hardware meters do -- they give peak, and not RMS levels. The advice
in the manual would make sense, with "real VU meters" on an analog
board (which the digital peak meters aren't), or in the digital
domain, they'd make sense using the K-system (
http://www.aes.org/technical/documentDownloads.cfm?docID=65 ). So
perhaps the manual's advice is for the mixed output level that you'd
expect to send to your mains or headphone mix?
Since the goal of input monitoring is to record as much signal as
possible w/o clipping, the peak-metering makes sense for the inputs,
but the suggested signal ranges don't. On an individual track, I'm
not sure I'd want to leave a 3dB "red zone" based on reading the
peak-values from the audio stream. That's a significant chunk of
resolution to be missing out on if you're working with say 16bit 48k
source tracks. With non-peak metering, perhaps that 3dB red-zone makes
sense, as there would be signal going into that zone -- basically
peaks over the RMS values suggested.
This conundrum -- peak vs RMS metering -- is the backing reason why I
initially wanted to integrate Fons' jkmeter (
http://www.linuxaudio.org/mailarchive/lad/2010/7/12/171535 ) -- until
I understood that the peak metering provided by the ice1712 hardware
couldn't provide that data. IMHO the hardware metering as done in
mudita24 is sufficient in representing peak levels captured over a
100mS time segment. To get RMS levels you need to access the audio
stream, at which point you might as well let jack and jkmeter provide
all the plumbing, and the ability to allow different apps to
separately meter and monitor/record a single audio data stream.
Alternately some hardware, like the MOTU (boo hiss!) 828mkIII, provide
DSP-based RMS levels for their hardware meters, which is much more
useful, especially in conjunction with easier-to-compute peak data.
> But I would like to stay with your nice cool 'blue' theme.
> So how about blue-yellow-red, or whatever the peak line
> colours are. Or how about blue, lighter-blue, and white ?
> I will try to make it easily disabled with a define so we can
> argue about it later.
Whatever looks good ... Just realize it's pure eye-candy. On the other
hand, I do provide color-coded peak-hold levels s.t. "green" "white"
"orange" and "red" peak-colors are held, with "red" being the last 0
to -1dB (which IMHO, is more appropriate warning for a meter returning
digital peak values).
> 3) Beside the stereo master meters, there are stereo master volume
> sliders ! And a *single* mute, and a gang button.
> No such controls in ALSA ! Seem odd? No master levels?
> Must check datasheet. Is the Windows envy mixer doing a
> trick, like secretly adjusting all the other levels at once?
Must be. Or there's an additional digital attenuation going on at the
windows level, which would be stupid, but typical.
> 4) The analog volumes are located on the HW settings page,
> tucked away, and without any readouts or markings as to
> what the heck level you're adjusting to. Mudita24 is way ahead.
>
> 5) The mixer has solo buttons. You're right on the ball there.
Maybe this kind of metering and cue-routing doesn't exist on any of
the hundreds of boards Fons has used, but it's certainly present on
all the Mackie's (and many DJ mixers) I've used, .... so it's somewhat
expected "home studio" and "small studio" functionality -- and the
ice1712's target market.
> 6) Each strip has only one slider and a pan. Right on again.
It's just a big waste of space to have a slider for something that is
typically dialed L/R/Center and shouldn't be easily "bumped". Panpots
seem standard on the mackie-level mixers.
-- 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 Sat Aug 14 12:15:02 2010
This archive was generated by hypermail 2.1.8 : Sat Aug 14 2010 - 12:15:02 EEST