Re: [LAD] [LAU] mudita24 1.02 -- improved envy24control mixer/router for ice1712-based sound-cards

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Tim E. Real <termtech@...>
Cc: <linux-audio-dev@...>
Date: Saturday, August 14, 2010 - 7:19 am

On Thu, Aug 12, 2010 at 4:57 PM, Tim E. Real wrote:

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

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,

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

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)

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.

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

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,

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

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [LAD] [LAU] mudita24 1.02 -- improved envy24control mixe..., Niels Mayer, (Sat Aug 14, 7:19 am)