Notices

Hi Wonko this is really quite useful.

One feature request might make it even more so -
recording wave data alongside the intensity.

Reason I mention this is that for what I had in mind
it would be useful to be able to later replay the sound data
along with the level indication as a witness for 3rd parties
to clearly demonstrate where sound levels exceed acceptability
and avoid the issue of 'anecdotal' reporting.

Not that this is where the app should go, just a suggestion.

Another thought along the same lines is being able to replay
a wav file through vumeter and see what db levels were
recorded, but not sure if this is even a remote possibility.

Anyway, it is still highly useful app even as it is already,
many thanks!

Alright,
I had the time to address some more feature requests.
Version 0.7.0 just made it to extras-devel and adds:
- an option for enabling auto rotation,
- a counter for the trigger,
- and a setting to select a monitor as source.

The auto-rotation option is quite straight forward.
Even though, I actually don't know why you'd want a smaller display.

The counter for the trigger is useful if you do not want to execute a command just when the threshold value was reached or exceeded once but you want to make sure the threshold value is reached/exceeded some 'n' times in a row.
Currently, the audio data is picked up with a frequency of 25 Hz, so if you want to trigger a command when the threshold was exceeded for one second you'd have to set the count to 25.

Last but not least, the "Monitor" source basically picks up the sound which is actually played via the speakers, so you can "measure", e.g., sound files you play.

I moved this app to my desktop! Which for me means I use it often. Great work keep it up.

The only request I would have is to be able to capture the info. This way I could just have it working in the back ground, and not monitor it every sec ... not that its a problem, just would be nice.

Also I notice the icon was a little fuzzy so I added a set to my org post with 48, 64 and 295 sizes. I wasn't sure when the program call for specific sizes, so I'd figure I just make it easy and give you a few. I tried on my 900 and it looks much better, hopefully it works better all around.

cheers

x

hi, first i want to thank you for such great app, second i have a request

would be great if in this view


blue bar was green and it could turn into yellow after a certain value and red after another higher

like

green <70
yellow <90
red >= 90

and it would be better if these values were configurables

It is a accumulated count for the whole running session lifetime?
Or in what time frame the count is accumulated?

(signal processing is very much alike as in SleepAnalyser, so you may want to check that, i.e. value and sample smoothing)

The "Trigger Count" simply sets, how many times in a row the measured value needs to exceed the threshold for finally triggering the command execution.
After the command was executed or if the measurement falls beneath the threshold the count is reset.
So, e.g.: you set trigger count to 3 and trigger value to, lets say, 100 then for the given, imaginary measured values the count would be as follows:
Values: 75, 101, 54, 89, 103, 105, 101, 102, 101, 67
Count: _0, __1, _0, _0, __1, __2, __3, __X, __1, _0

In this example 'X' represents command execution and reset of the count to zero.
Edit: Also note that the terminology might be confusing.
"Trigger Count" is the setting which determines when commands are executed and "count" (or maybe "running count" would be a better term) is the actual "counted" value at runtime that is compared to the "Trigger Count" setting for actually determining whether a command should be executed.

I hope the example is readable in all browsers.

I'd like to take the time and thank all of you who contributed here so far.
No matter, what kind of contribution: be it nice icons (thanks again xman ), feature requests, bug reports, or just other (subjective) feedback.
These are all parts which finally help in getting a nice software up an running.
In this sense, the actual coding is just a part of the whole thing as well.

Thanks all

So far, I implemented a version (0.8.0) which adds a settings option for displaying colored scales.
Though, it uses hard coded threshold values at the moment.
I use slightly different values (60 and 95) as the ones you suggested, as these resulted in a prettier look in my opinion.
As another feature the line-chart widget also makes use of the color option.
Version 0.8.0 already made it through the autobuilder.

I just uploaded version 0.9.0 to extras-devel.
This version adds the following features:
- settings for the "colored widgets" (threshold, color selection dialog),
- restore the last active widget/display on startup,
- and fix (or at least improve) the scale layout of the horizontal bar widget.

I think this is great so far. I really love how quickly you've implemented new features people (both myself and others) were requesting.

I'm using it with auto-rotate and it works fine right now. I appreciate the color selection and custom command options being so versatile, too.