On Tue, Aug 10, 2010 at 11:24 AM, Tim E. Real 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
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 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
> If we put a pre/post fader button on each digital mixer strip,
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).
> However I realised yesterday that each digital mixer strip is STEREO.
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
> If we couple this with MONO analog volume meters, and each of
If you're volunteering to do the work, go for it!! :-)
> OK, I know there's issues, I must first understand how the routing
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
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 :-)
Linux-audio-dev mailing list