Ah, not several PNGs, ok. ^^
Hadn’t seen yet that the knobmanSlider example is hiding a VU meter inside. 
But it looks promising.
As is, it’s displaying random values.
And I have a hard time feeding it with inch + chnset …
I mean, what to exchange this part of code for(?):
kVuMeter randi 1, 5
filmStrip “vuMeterIdent”, int(abs(kVuMeter)*30)*128, 128, 128
Still have to dive more into CSound.
Do you have any hint for me? 
It’s Csound 
The incorrect spelling of Csound is becoming more and more frequenct 
But I won’t hold it against you 
So you want to change the randi for a inch:
kVuMeter inch 1
filmStrip “vuMeterIdent”, int(abs(kVuMeter)*30)*128, 128, 128
In this case you don’t have to worry about a chnset as it’s already wrapped up in the UDO.
Oh, oh … hey, that’s what I call a newbie … haha
Even the spelling of what he’s going to learn is wrong. LOL
Thank you for your hint on the inch 1 part.
Sadly, that doesn’t bring the VU meter to life for me.
As soon as I exchange the randi for the inch 1 it’s dead. 
Sorry that was my fault. Even non-noobs err! It should be:
a1 inch 1
kVuMeter rms a1
filmStrip "vuMeterIdent", int(abs(kVuMeter)*30)*128, 128, 128That’s fantastic. Rory. It works!
Thank you SO much.
Only thing strange is, that as soon as I amplify the level of a white noise test-signal above +5.5 dBFS the VU meter graphic starts flickering and fully disappears, if I exceed a gain of about +6 dBFS.
I guess, the .csd runs out of PNG image portions. ^^
A solution could be to add enough image parts at the “end” of the PNG file to match the highest RMS value to be displayed.
Or is there any way to keep the VU meter showing the last part of the PNG, no matter how high the RMS value? e.g. some possibility to “cap” the incoming RMS value for the VU meter?
P.S.:
NEVERMIND
I found out how to adjust the “translation” of the RMS value into the VU meter display.
int(abs(kVuMeter)[adjust here])[height], [width], [height]
This is really fun and works absolutely nice. ^^
I only find it hard to adjust the behaviour of the meter …
OK, I was too euphoric on this one … still at very high RMS values, the VU meter graphic disappears.
It’s definitely down to how I’m moving through the image. You’ll need to do some experimentation. This was only ever intended as a quick example. In fact, I think someone might have posted an updated version of my UDO at one point. Let me look…
Hmm, couldn’t find it. Anyhow, it’s a simple fix for this one. We just need to limit the value of the RMS signal. We can do this with a limit opcode:
filmStrip "vuMeterIdent", int(limit:k(abs(kVuMeter)*30, 0, 29))*128, 128, 128That’s it. Just like I wished for.
Thanks for all your help, so far!
My VU meter works perfect now.
In the next step I am going to adjust my graphics to a 1kHz sine tone @ -18 dBFS RMS.
I’m so curious, if it will work … ^^
Did you mean this post regarding your UDO(?):
And one more “stupid” question, hehe:
When integrating filmstrip … what exactly do the numbers in and outside of the bracket stand for?
filmStrip “vuMeterIdent”, int(limit:k(abs(kVuMeter)*30, 0, 29))*128, 128, 128
I have tried to do research and even tried to fumble around with those numbers, but still am not 100% sure about their exact meaning and result. Would you mind giving me a short description? That would be super-nice!!!
That’s the one. It might be useful.
Or course not. If I recall correctly, each frame in film strip is 128x128 pixels. The UDO simple displays a 128x128 window from the film strip PNG. As kVuMeter moves between 0 and 1, we scale it to go from 0 to 30, as there are 30 frames in the film strip. This causes the “window” to jump up or down one frame each time kVuMeter changes. Does that make things any clearer? Feel free to probe for more information. I’ll provide it if I can.
Thanks!
OK, in my case I am trying to implement my own filmstrip image.
It has 151 steps (frames), each at a size of 262x162 px.
Have tried it with this beast:
filmStrip “vuMeterIdent”, int(limit:k(abs(kVuMeter)*151, 0, 150))*162, 262, 162
Still, I’m not sure about the meaning of the values.
For the moment, let’s look at the code this way:
filmStrip “vuMeterIdent”, int(limit:k(abs(kVuMeter)* [number of steps], [lower limit of steps], [upper limit of steps?!?]))*[height], [width], [height]
Are these descriptions correct?
Especially the [lower limit of steps] and [upper limit of steps] could very well be nonsense. 
Looks good to me? Maybe you can post the csd and the filmstrip? If there are 150 frames, it might be a little large to post to the forum, Maybe you can provide a link?
Sure, I’ll happily do so, as soon as those graphics are ready. 
I am still “building” the graphics with the help of a 1kHz test tone @-18 dBFS (RMS).
To “calibrate” my filmstrip, each “frame” shall contain the dBFS (RMS) value, that is “triggering” the respective image part of the filmstrip.
As soon as this works fine, I will know how to design the scale and arrange the needle graphics of my VU meter. ^^
Sure, the meter will only work with DAWs whose audio-interfaces are set up with 0 dBFS = 0 dBVU = +4 dBu.
But I guess, this is the most common standard for home recording setups.
Another nice thing would be to define ranges/spans of RMS values that trigger specific parts of the filmstrip (e.g. an RMS from -0.25 to +0.25 could trigger image portion nr. 76 of the filmstrip, which is showing a “0 dBFS (RMS)” graphic) … but I guess that’s not possible. Isn’t it?
That way I wouldn’t have to do the try & error calibration, which I am trying at the moment.
Whoo, things are getting somewhat complex … ^^
Better to start with the assumption it IS possible, and move on from there
Haha, wise words.
So, how about defining ranges/spans for the kPos-value, which seems to be responsible for the image crop, in the sprintfk of the filmStrip opcode?
Does that make any sense?!?
Please don’t forget, I’m only tyring to use Csound since a few days …
Explain again why you can have a simple 1 to 1 mapping for rms values to frame? Why the need to complicate it?
Thought it would be the other way round: more reliable and less painstaking.
Mainly, because the spans, which are triggering different portions of the strip, do not have the same size: e.g. portion nr. 2 is triggered by an RMS span from -43.5 to -37.4 dBFS, but portion nr. 3 is triggered by an RMS span from -37.5 to -34.0 dBFS. And similar differences appear thoughout the whole controller range.
I mean, rotaing the gain knob by an increment of “1” has quite different results.
It would be nice to just grab the resulting values and work with them.
And it’s getting even more complicated, when setting up needle graphics:
Because those will have to show the means between the lower and upper end of each of these ranges/spans, when being triggered by that RMS range.
In my case, it means to check 151 RMS spans by try and error, fiddling on the gain knob.
Although Cabbage “knows” the exact values. ^^
I think rms returns values absolute amplitude values in the range of 0 to 0dbfs. You might want to pass them to dbfsamp to convert them to them decibel values. Then might might map better to your images?
Have to dive deeper in some meter design issues, but will get back soon. 