On Tue, Aug 10, 2010 at 11:24 AM, Tim E. Real <termtech@rogers.com> wrote:
> On August 10, 2010 10:06:17 am you wrote:
> I will shrink the meters slightly, simply to align better with
> the slider scales.
> Uh, if you don't mind, I actually want to increase the mixer sliders to
> around -60dB, instead of -48dB which I think may be a wee bit too high.
> The meters will only be as long as the -48dB mark,
> but the sliders will be longer, if it doesn't look too bad and there's
> enough room.
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@rogers.com> wrote:
> But you ultimately turn to the analog volume tab in order to
> affect what's arriving at the meters and the faders.
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.
> If we put a pre/post fader button on each digital mixer strip,
> then in post mode the user would have to understand that
> what is shown on the meter is affected by the sum of the
> digital mixer slider level and some corresponding analog slider level.
> That is what is ultimately feeding the mixer after the fader, isn't it?
> So this information would be useful to show, wouldn't it?
> It is readily 'available', am I correct?:
> post-fader meter value = pre-fader meter dB value + slider dB value
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.
> That means for post-fader metering, we would need to split the current
> single meter into two meters - left and right.
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 we couple this with MONO analog volume meters, and each of
> THEM with pre/post buttons, AND to combat clutter we split
> the DAC/ADC tab into two (he ducks, expecting projectiles)
> or use Niels' suggestions below ...
If you're volunteering to do the work, go for it!! :-)
> OK, I know there's issues, I must first understand how the routing
> affects all of this. It's only ideas for now.
> It just seems like something is missing, like it really could use
> some kind of extra metering + options, you know?
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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Thu Aug 12 00:15:04 2010
This archive was generated by hypermail 2.1.8 : Thu Aug 12 2010 - 00:15:04 EEST
