13 Aug
2010
13 Aug
'10
2:10 a.m.
Humming along here, Niels I got your request done, click on a scale and
the corresponding slider gets the focus.
Much code cleanup, rewrites, removed my 2.14 dependencies.
Found some code, before we came along, which had those deps as well.
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 feel a bit better about us doing these 2.x things now.
About the slider fractional values problem:
I discovered the magic bullet I was looking for:
The GtkRange::round_digits member !
I set it to zero for all the sliders and presto ! Now the sliders output
only integer values. There's no in-between fractional stops now.
This means the sliders now 'quantize', or 'snap', to each integer value.
That's with mouse, mouse wheel, or KB.
Man, if I had only known this before...
I can't find much info on how old that member is but it seems to date back
to at least 2005. It's a 'protected' member and not well doc'd.
On August 11, 2010 03:26:19 pm you wrote:
And then
what Geoff B. requested: Support for showing multiple cards
at once.
On Tue, Aug 10, 2010 at 11:24 AM, Tim E. Real
<termtech(a)rogers.com> wrote:
Yes I saw that comment and
code in there. I was going to post
"Ah yes, manipulate the drawing, not the widget height".
That means, as you say, maybe stretching the bottom or top end
or something. It's a tough problem to solve.
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(a)rogers.com> wrote:
I knew
those labels were there but their significance became
clearer with these discussions. It means it is possible to add meters, right?
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.
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. Pan control would need decent resolution,
let's not skimp, like some crappy pan controls. 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?
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.
Turns out the routing
doesn't seem to enter into this at all.
Routing is like the very last part of the chip which just says where
each final hardware output comes from.
I guess this is one reason you are able to provide dB labels on the
ADC/DAC page without regard to routing.
And one reason why meters might be welcome on that page.
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 :-)
You're going over my head there. I'll have to think
about all that, he he...
Never really coded gtk before, and I'm mostly a c++ person.
But gtk+ is proving to be fun and easy.
----------
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.
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.
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.
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?
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.
6) Each strip has only one slider and a pan. Right on again.
7) "The peak meters indicate the incoming pre-fader levels
of the incoming audio..." Guess that's one against me...
Whew. Well, back to some more coding. Later... Tim.
-- Niels
http://nielsmayer.com