On Wed, Jul 28, 2010 at 12:57 AM, James Morris <james(a)jwm-art.net> wrote: I had to look that one up: http://www.wolframalpha.com/input/?i=cadmium+yellow+as+a+color Personally, I thought this one would leave some people wondering about monsters and dark closets for whatever lurks behind the meters when no sound is displayed. :-) is a good compromise -- I'll change the code to that unless someone has a better color choice, or the colors are found to be nauseating to those with http://en.wikipedia.org/wiki/Tetrachromacy ... or it turns out to be a factor contributing to http://en.wikipedia.org/wiki/Colony_collapse_disorder as bees hurl themselves against LCD screens due to the irresistible draw of the bright green and cadmium-yellow (sounds like that could form the basis of the next Monsanto misinformation campaign...). ................... Also, you mentioned there was a problem with CPU usage and sluggish response. I haven't heard of any other complaints along these lines, so i'm wondering if you did something to resolve the issue, or if you might be able to do some more debugging: ... What X server are you running, or rather, are you running on a particularly slow, totally unaccelerated server? Or an ATI Catalyst (closed-source) server which is known to have poor X performance. Is the CPU usage coming from the new 'envy24control' or the X server? If it's in envy24control -- could you find out where or what it's doing? Other than the distro, I too have Delta66 and AMD64 so I would hope there wouldn't be these kind of problems/differences on something like this. Anybody else seeing anything even remotely like this... it sounds like something has gone horribly wrong.... IMHO this should significantly lower CPU usage, not raise it. The CPU usage is relatively low, but the overall X resource usage (and interrupts and many I/o's to the soundcard) is unnecessarily high. But may not become noticeable until you actually load up your machine with "foreground" tasks -- this is supposed to be a utility you can leave running in the background and not worry about . See https://bugzilla.redhat.com/show_bug.cgi?id=602903#c3 for details. In addition to X resource use, the old envy24control also generated a lot of I/o and interrupts : - gtk_timeout_add(40, level_meters_timeout_callback, NULL); - gtk_timeout_add(100, master_clock_status_timeout_callback, NULL); - gtk_timeout_add(100, internal_clock_status_timeout_callback, NULL); - gtk_timeout_add(100, rate_locking_status_timeout_callback, NULL); - gtk_timeout_add(100, rate_reset_status_timeout_callback, NULL); Now it no longer tries refreshing up to 10 meters 25 times a second, along with an additional 40 interrupts per second to individually check the clock status, rate locking status, and rate reset status -- which hardly ever change anyways. Note that this is totally wrong to begin with, the new code just makes it less wrong, calling all of them 10 times a second in a single callback. Rather than all those multiple separate calls. (Then again -- maybe that's what's causing the sluggishness you're seeing? ) Why can't checking for changes at the ALSA level to "rate reset" "rate locking" "clock status" and "master clock status" happen without needing to poll for such changes. Isn't there a way of setting up a select() on file-descriptor? Niels http://nielsmayer.com

On Wed, Jul 28, 2010 at 3:40 PM, James Morris <james(a)jwm-art.net> wrote: No need.... I've reproduced and fixed this problem. It had to do with a strange "Gtk-oscillation" in UI sizing that would happen whenever label "0dBFS" would get drawn into the digital mixer meter pair (which would of course occur with louder signals :-) ). Lesser (or at least more computationally tractable) oscillations within the pane of sliders&meters might also happen, but the "earthquake" caused by the digital mixer panel on the LHS resizing had an interesting "feedback loop" that would take quite a while to "settle out" event-wise. I fixed by using the label "0.0dB" which is shorter and doesn't cause resizing. The weird thing is that oscillation would somehow manage to also do the equivalent of clicking "reset" -- allowing the jiggling to recur repeatedly every time a new peak hit. Normally, if 0dB was hit, and another 0dB peak came along, nothing would happen as nothing needed to happen UI-wise. I'm pretty sure the only time I ever saw that kind of behavior was a Gtk program that had written past some important arrays (memory corruption -- and a particularly nasty way of triggering it via Gtk). Strangely, this problem was not visible on a 4-core AMD Phenom II box with on-board ATI graphics. But on a two-core AMD Opteron 1220, with NVidia onboard graphics, it was reproducible. It's kind of an interesting looking effect. Like when you start hitting 0.0dB on the mixer, the entire UI starts shaking around like it's having an earthquake. But only when it's loud. Clearly an extension of this feature should be added to window managers: shake the window of your DAW whenever you clip inputs or outputs on your soundcard. :-) Also, after seeing your snapshots with the "dark" background graphics, I decided to let a gnome style pick a pair of contrasting colors for me. so now I'm using the following foreeground/background pair: widget->style->text_aa[GTK_STATE_ACTIVE] widget->style->text_aa[GTK_STATE_PRELIGHT] (the L/R meter pair for the digital mixer pair are the same color as all the other meters) Comments on this approach? The color choice is truly milquetoast now! But also visible, soothing & functional: http://nielsmayer.com/envy24control/Screenshot-Mudita24-rc0-MonInp.png - Niels http://nielsmayer.com

On Fri, Jul 30, 2010 at 9:17 PM, Patrick Shirkey <pshirkey(a)boosthardware.com> wrote: 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

On Sun, August 1, 2010 3:24 pm, Niels Mayer wrote: 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. -- Patrick Shirkey Boost Hardware Ltd.

On July 31, 2010 04:20:55 am James Morris wrote: The gui resizes a bit whenever a dB label changes the number of digits in the label. Maybe that's what was seen, rapidly? Tim.