On Thu, Aug 12, 2010 at 4:57 PM, Tim E. Real <[email protected]> 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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
