Forum rss-feed


Developers: VU Meter Agent

Most Recent

written by: jim

They are nearly done.

We are aiming for another release this week, and they will be in that.

You can copy the build tools either from the git checkout or from the release. I'll also update the tools in the master branch of EigenD-Contrib.

written by: jsn

Mon, 23 Jan 2012 11:39:02 +0000 GMT

I have checked the VU meter agent that Stefan Bohne (stbohne) and I created at the Eigenharp DevCon. Its in a branch of the EigenD-Contrib repository called 'vu_meter' (inspired, huh?)

I am creeping it along incrementally and am asking for some feedback: should the VU meter display all the keys in the level colour or do like a bar VU and segment the keys by colour (or make it configurable?) i.e. if there are 5 keys used and the level is clipping should they be GGYYR or RRRRR (where G,Y,R are Green, Yellow, Red)

I'm about to implement clip hold and am wondering whether a 'high hold' and 'signal hold' would also be useful? (not on norml VUmeters that I know of, but hey...)

written by: john

Mon, 23 Jan 2012 12:29:28 +0000 GMT

Hi John

That's great that you've checked it in - this is going to be a very useful Agent I think.

Colour-wise I think you could use the thresholds that you used in the one-light case - ie, take the number of lights, divide the range using the meter law chosen (which I guess will be a fixed log or something to start with) then set the lights colour according to which settable threshold has been crossed. By doing it that way you get the advantage of it degenerating nicely (and intuitively) to the single light (or 2 or 3 light) case. I think that the corner case (of two thresholds in one 'bucket') also turns into a colour change on that led, which seems a good thing when I think about it as it adds information with a restricted set of LED's n a nice way.

The way the signal level is determined is also an issue, although doing the naive 'peak detect' is a good start. There's a good article here on audio metering, if you want to get really into it. Whether or not it's genuinely worth the DSP overhead of calculating an RMS value is an interesting question, and one I suspect best answered by trying the simple approach first and seeing how well it works in use.

I've used meters with a other hold functions in the past and never found anything apart from clip hold to be useful. The filtering function used in PPM meters can be good though - a kind of 'peaky smoothing' invented by the BBC. One can live easily without it though and people tend to either love or hate PPM style metering.


written by: jsn

Tue, 24 Jan 2012 16:51:11 +0000 GMT

Have checked in next version to Contrib that implements GGGGYR style output with a logarithmic scale.

Things I discovered:
- pic::approx::pow function relies on pic::approx::exp which is a fast implementation that is limited to the range (-1,1). Hence pow(x,y) is limited to where ln(x)*y is in the range (-1,1). There's a comment on exp but not pow. (screwed up dB conversions)

- where do I place installer if other want to try it?
- what is the process for getting this approved as being "moral" ? (Or rather - what do I need to do to it to make it "moral")
- I am uncomfortable with constructing clever strings to set lights, what is the correct way of doing this?
- I note some agents in workbench have pull-down selectors. How do I specify an Atom to have this behaviour? (domain.Enum does not seem to work)
- I have found a number of Workbench annoyances and bugs. where do I report these? In the forum?
- how do I get documentation added to the Wiki for the compenent? Can we add links to the in Workbench back to the wiki for examples?

Going to implement clip-hold next.

written by: jsn

Tue, 24 Jan 2012 18:35:37 +0000 GMT

FYI - Clip Hold now implemented.

Thinking RMS next...

...but I think there's a bug in the light output. Can't seem to get one vu_meter to go onto second course of Pico using kgroup specifying 16 keys. Is this a Pico/kgroup issues or a bug in the vu_meter code?

written by: jsn

Tue, 24 Jan 2012 19:08:34 +0000 GMT

So it would seem that the status structure we are using does not get mapped by a kgroup. (see piw_statusbuffer.cpp - that's the one Jim pointed us at). The structure contains an absolute row/column value and not a linear 'key' like value.

Feels like I need to either put the map of 'segment to row/column' into the VU meter itself, or implement a Mapper of some description as another agent that takes the single column Status output and converts it to row/column Status output.

Archtitecturally, which is more correct ?

written by: alistair

Tue, 24 Jan 2012 19:49:05 +0000 GMT

Hi John,

Workbench bugs and annoyances - please feel free to email them to me ( and i'll get them into the system.


written by: geert

Wed, 25 Jan 2012 15:29:58 +0000 GMT

Hi John,

About the lights, take a look at piw_status.h. The static statusbuffer_t::make_statusbuffer method takes a map of statusdata_t to value mappings. The statusdata_t class hides all the encode/decoding parts of working with status buffers, you just give it a row and a column, and indicate whether it's a musical or a physical status.

Hope this helps,


written by: geert

Wed, 25 Jan 2012 15:39:55 +0000 GMT

John ... looking into the second Pico course weirdness you reported now ...

written by: jsn

Wed, 25 Jan 2012 15:44:49 +0000 GMT

Thanks. I actually think its a feature? i.e. kgroup maps keys not status messages.

statusdata_t takes row/column - not a linear key like number. Maybe status should go linear too? (simplify!)

written by: geert

Wed, 25 Jan 2012 16:25:16 +0000 GMT

Hi John,

It should understand both, when the row is 0, the columns are interpreted as a linear sequence. However, if you use a course that doesn't exist upstream, then the lights will not show. The Pico setups normally have only one course in the kgroup layout, so maybe that's the problem you're facing? I'll get back to you as soon as I've been able to take a closer look at it.

Take care,


written by: jsn

Thu, 26 Jan 2012 12:05:40 +0000 GMT

Checked in latest version that does RMS of input signal not just peak value. Also simplified everything into dB which reduces the computational overhead of RMS calculations.

I'd like to be able to provide a pull-down selection for the 'calculation' to use (peak/RMS/PPM?) and maybe for the display 'law' (linear/log). How do I do this?

Also - how do I get new words accepted into the lexicon? I need 'vu', 'meter' , 'clip' and 'signal' added (unless there's other terms I shold use) I can do it in my EigenD and send a patch back, but then it requires a build/release for these to become available. So I can't share the VU Meter Agent with anyone who doesn't have Workbench until that release. Seems a bit limiting.

Can't the reside on your servers somewhere so it can be updated dynamically into the EigenD when it can? That way there's no need for a release to allow the distribution of a new Agent requiring new terms...and you still have control of the lexicon.

(Note how I am not suggesting that I could release an installer that modified I am trying to be a moral person :0) )

written by: jim

Thu, 26 Jan 2012 12:48:30 +0000 GMT

Al is putting in Workbench and Belcanto support for simple enum types which should address the pull down problem. There is another protocol, but its pretty complicated and really for stuff like sample browsing, overkill for this.

Hopefully that will be in shortly.

The lexicon thing requires more thought, I agree.

written by: john

Thu, 26 Jan 2012 15:12:36 +0000 GMT

Hi John

After some discussion here Jim has decided how to support this. It's going to be a very common thing to want to do, to add words to the lexicon for new functions. The only issue is really that for consistency there needs still be the 'one true lexicon' that rules them all. So here is how it will work:

*Each Agent can have an optional 'lexicon.txt' file in it's its directory.

*This file will get added to the Agent manifest by the build system and allow EigenD to be aware of it at startup and hence for the interpreter to find the new words

*It will be overridden by the main, compiled in, system lexicon, so if a word already has a definition, or if we decide to include new word definitions at some point the local definition will get (silently) ignored from that point on. This should provide a nice mechanism for the organic evolution of the Belcanto lexicon without too much chaos. If we really hate or can't use a word for some reason (company brands, trademarks etc might be a good example) this also gives us the option of overriding or suppressing it - hopefully this will never need to happen, its a 'nuclear option'.

*The file will have the same syntax as the current file and errors in it will be silently ignored

*There will be a Belcanto region that is specifically for new, user contributed vocab. Avoiding conflicts in that area will be the developers problem, and conflicts will be treated by EigenD on a random basis (as in, only one will end up defined but I have no idea what one, it'll be pot luck). This is going to have to be an organic process and a degree of good manners and some mutual communication will probably make it all go smoother. A post in the developers forum along the lines of 'I'm defining these new words in my Agent, and using these note sequences, any objections?' might be a good practice. There's no point in a central registry of any sort as that's what the system lexicon already is, if things work out well that's where they'll migrate to. If you have strong feelings about a new word and you would like to stray out of the defined user area ('I really want it to be the opening phrase of Beethoven's 5th'), feel free to email me direct about it.

As a general principle, please try to use the existing lexicon to good effect and avoid coining new words unnecessarily, we'd really like to keep Belcanto reasonably lean but don't stretch an exisitng word to breaking point in pursuit of this. If you need a new word, you need a new word and hopefully this will make that a tractable problem.

Jim is hoping to get this change in sometime in the next couple of weeks, possibly for the next release if we can.


written by: carvingCode

Thu, 26 Jan 2012 17:05:54 +0000 GMT

John - Please don't forget my request for 'song', 'tune' or something more relevant to use in the file browser tree. Really could use a better way to organize setups. Best may actually be a traditional file picker, doing away with limited tree browser.


written by: jsn

Thu, 26 Jan 2012 17:13:14 +0000 GMT

That sounds like a good way of doing it. There would be the opportunity for words to get promoted and shared without it breaking anything later, too.

Let me know when it's available for trial adn I'll use it with the VU meter as a guinea pig

written by: john

Thu, 26 Jan 2012 19:07:43 +0000 GMT

Hi Randy

I've added around 60 musical genre words (drawn from the ID3 tag list) to the lexicon, which gives you a lot of options as they can be arbitrarily combined (so you can say 'acid folk' if that's what you're making that second). I've also added 'tune' , 'song' and 'arrangement'. There are about three million different genres out there and I've tried to include a decent subset but if I've missed one out that's really important to you please let me know. I'm afraid I drew the line at 'christian gangsta rap' (yes, astonishingly that seems to be a valid ID3 tag), so please don't ask me for the wilder fringes of music categories.

These changes will appear in the next 2.0 experimental release.


written by: carvingCode

Thu, 26 Jan 2012 20:23:29 +0000 GMT

Great! Thanks, John. No wild requests here.

written by: john

Fri, 27 Jan 2012 07:34:20 +0000 GMT


I've added 'Vu', 'Meter', 'Clip' and 'Signal' to the lexicon as well, they'll also be in the next release (in case we make one before the local lexicon stuff goes in).


written by: stbohne

Sat, 28 Jan 2012 01:54:39 +0000 GMT

The vu meter still uses some odd status codes to achieve the visual effect. I suggest adding three new status codes: BCTSTATUS_LOW, BCTSTATUS_MEDIUM and BCTSTATUS_HIGH. These can be used to show any visual representation of a level of some sort - but for now they would be associated with the three led colors.

written by: 0beron

Wed, 8 Feb 2012 11:53:38 +0000 GMT

Any word on the per-agent lexicon files? I'm still working with the build tools from the devcon, so once a new release is made I guess I will need to download and install it. Are the build tools that we use in our little sub-projects present in the new eigenD distribution, can I copy them out of the installation into my project folder?

Please log in to join the discussions