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

On Tue, Aug 10, 2010 at 11:24 AM, Tim E. Real <termtech(a)rogers.com> wrote: This sounds like a good change. Prior, as the meters would not resize and I'd generally use them at their default or -t1 height, the truncation of the bottom of the 0 to -144db attenuator was done to allow better control over the rather coarse 1.5 dB attenuator increments at the top end. With the stretchable meters and sliders, when this level of control is needed, the window can be resized for it -- with kwin achieved with a flick of the window-frame towards screen edge. One other idea that wouldn't require shortening of the meters: fake the -48 to -60 range as "on" whenever -48.1 would be illuminated. Actually my comment //NPM: below, fudging value 51.0 instead of 48.164799306 = 20*log10(1/256) was wr/t making the bottom end of the meters do this a little to get the fit closer to what the scale widgets were drawing. Since you have control over the label-positions, you could probably get their positions and do the meters right w/o my fudging. I couldn't figure out a way to get at their positions w/o violating all sorts of APIs and making various wild assumptions. The simpler fudging hack employed seemed like a better bet. On Tue, Aug 10, 2010 at 8:09 PM, Tim E. Real <termtech(a)rogers.com> wrote: Yes, which is why meters should be present in the analog volume tab. Perhaps using the idea of the current dbFS label becoming a button, which when set, would display the associated channel's peak-meter. Or just splitting the ADC's into one metered/slidered panel,, and a different outputs panel with metering for 8 PCMs and their associated DAC controls. While it is true that "mudita24's" meters are perpetually in PFL (prefade listen) mode -- and this can be confusing to those expecting an analog mixer, the AFL (after-fade listen) metering doesn't necessarily make sense in this mixer. In this case, it doesn't convey new information. In an analog mixer, for example, it could indicate you've applied too much gain/eq even if the PFL's were in-range. An initial problem in viewing mudita24 as a "mixer" : if the "mute" is on, it doesn't display that, nor the contribution of the faders to the resulting stereo mix. However, this app is also, or perhaps mostly, to be used as an input leveling and metering utility alongside a real mixer and real metering solution in a DAW. The mixer might be used for it's traditional purpose as a "zero-latency monitoring" solution for performers, while relegating the final mix to ardour or qtractor -- both of which implement their own mixer and metering and work in the expected ways as a mixer. However mudita24/envy24control is unique in that it can set the levels in/out of the ADC's and DAC's as well as control the zero-latency monitoring mixer. So perhaps having proper emulation of PFL/AFL in this mixer may be overkill because it may not be the final production mixer people are concentrating on. Which makes displaying levels at the ADCs/DACs more important IMHO.... However, if dreaming along PFL/AFL lines, I prefer a different idea -- see native instruments traktor http://osx.iusethis.com/screenshot/osx/traktordjstudio3.png -- a "dual" meter per side, where the wide part of the meter is the input level as we show currently in "mudita24" ; for our use, the additional narrow outer band represents either the post-fader-level that you computed above, both for current levels and peak-hold levels, or it could display the overall digital mix level. (And get rid of the digital mix display on the LHS altogether, as it can be placed where needed on any meter). The outer band peaks would "auto-decay" while the input peaks remain constant. (Which would also give you both kinds of displays simultaneously). Not if you use the idea of a single fader and a panpot. Then the meter would be displaying the post-fader level, and the panpot would be determining how that is actually mapped to the individual channels. Saves a lot of space too -- one slider and one set of labels per channel. If you're volunteering to do the work, go for it!! :-) Although some minor improvements could improve usability, for any such wild UI changes, I'm wondering whether it wouldn't be better to create a libenvy24control and call it via Vala -- basically use most of the existing code but put up an "outer skin" in vala that'll serve as a flexible testbed for mixer experiments. Seems to me like this is the kind of application that needs to write itself, in terms of interpreting it's world -- the particular soundcard -- and dynamically generating whatever desired sets of user interfaces the user chooses/customizes (e.g. positioning of separate windows or single window with multiple positionable panels). I'd actually attach these to existing profiles so that each amixer-profile gets not only different hardware settings, but also whatever customized set of UI panels/sliders/meters the user come up with.-- so each profile gets saved along w/ a "script" that creates&configures the UI, inits the hardware, & attaches the appropriate callbacks, etc. Then you don't need to worry about splitting the analog outs panel, or anything... The user would set it up their way, and there's be a general initial catch-all default setup that would make all existing options accessible.. Although I think the latter would be total overkill, does anybody at least agree initial vala-based testbed idea sounds like an interesting option, or a totally stupid idea? The inner loop of the running application would still be the same C code... This is just a random thought... hopefully it won't derail an otherwise constructive thread, and good old "working C" is better than nuthin' code :-) -- Niels http://nielsmayer.com