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:
> On Tue, Aug 10, 2010 at 11:24 AM, Tim E. Real <termtech@email-addr-hidden> 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.
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.
> 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@email-addr-hidden> 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.
I knew those labels were there but their significance became
clearer with these discussions. It means it is possible to add meters, right?
> 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.
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 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.
And then what Geoff B. requested: Support for showing multiple cards
at once.
>
> 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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Aug 13 04:15:05 2010
This archive was generated by hypermail 2.1.8 : Fri Aug 13 2010 - 04:15:05 EEST
