Forum

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

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)

Questions:
- 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.

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 ?

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,

Geert

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

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 lexicon.py 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 lexicon.py. I am trying to be a moral person :0) )

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.

John

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

Great! Thanks, John. No wild requests here.

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.