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

On Sun, August 1, 2010 3:24 pm, Niels Mayer wrote:
> 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:

Understood. Just as a reference the glassy tube effect can be calculated
just once and then only updated per pixel. I didn't have the time to
understand and integrate that functionality when I was working on it so
the version in jackEQ currently updates the whole meter each time.

>
> 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
>

-- 
Patrick Shirkey
Boost Hardware Ltd.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev