Re: [LAD] [LAA] announcing envy24control, mudita (*) edition.

On Fri, Jul 30, 2010 at 9:17 PM, Patrick Shirkey
<pshirkey@email-addr-hidden> wrote:
>> http://nielsmayer.com/envy24control/Screenshot-Mudita24-rc0-MonInp.png
>Looks good. I did some work at the end of last year to add a glassy tube
>type effect to jackEQ's meters. It would be cool to get that combined with
>your efforts.

Thanks... yes, it's plain-er looking than the original -- on purpose.
I was trying to get away from the "make it look like actual hardware",
and instead focus on making something useful with the GUI available.
Also, the previous implementation was very inefficient -- which is a
bad thing for a "utility" -- that inefficiency gets multiplied across
up to 12 meters running simultaneously:

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11575 root 20 0 626m 218m 47m S 5.6 5.5 166:43.29 X
 4001 npm 20 0 192m 8796 6384 S 1.7 0.2 0:05.90 envy24control

Whereas this new one, despite increased functionality, uses (5.6 +
1.7) - (1.3 + 0.7) =
5.3% less CPU (on a fast machine, even more on a slower one)

.11575 root 20 0 626m 218m 47m S 1.3 5.5 166:20.32 X
 3875 npm 20 0 193m 9.8m 7024 S 0.7 0.2 0:08.89 envy24control

So I was focusing on a quick and easy rendering of information
provided by the ice1712's hardware metering -- which is not very
high-res metering. I'd rather leave CPU resources for doing real
metering (e.g. jkmeter) of the needed channels and use this app's
meters to get rapid feedback on levels one is setting via the sliders.
Also, the idea is that this app is something you could just leave
running all the time and not worry about it consuming a lot of
resources: it's just rendering hardware-provided data and doesn't
actually require data-flow from 20-simultaneous up-to 24bit 96k audio
streams, just for metering. That's why I like hardware metering and
wanted envy24control to do a better job of using the data w/o loading
the PCI bus, interface and CPU.

Regarding changes to "look" : I would imagine quite a bit could be
done by simply defining new style definitions and having the
accompanying style sheet.... or setting up a new style to work w/ the
existing names used in the app. Also putting this kind of stuff into a
"skin" could be easier to maintain; some people will want to use this
on light hardware w/ small screens, whereas others will have a serious
graphics box that could render, say, transparent or
translucency-colored meters w/o breaking a sweat. But I wouldn't want
to force the person using a netbook to control envy24control (via X
window protocol) on a headless box -- and get bad meter performance
trying to compute a "glassy reflection" or transparency off a virtual
meter.

Here's the look of the new 1.0.1 -- now the meter coloration (other
than the black background) is chosen
from the current gtk skin being used, so those with "dark" interfaces
won't end up shocked by the charteuse and cadmium yellow of the former
meters. Also, the meter uses logarithmic scale that matches the slider
labels in the "Monitor Inputs" panel: this makes the meters less
"jumpy" looking, giving a better visual of the peak-levels, IMHO:

http://nielsmayer.com/envy24control/Mudita24-101-Monitor-Inputs.png
http://nielsmayer.com/envy24control/Mudita24-101-Monitor-Outputs.png
(note change of look imparted by a different gtk skin)
http://nielsmayer.com/envy24control/Mudita24-101-Analog-Volume.png
http://nielsmayer.com/envy24control/Mudita24-101-About.png

-- 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 Mon Aug 2 04:15:01 2010