First of all: Hi to everyone, i'm a bit of a newbie to PD, did some MAX/MSP back in the day, but still i'm no pro. Now I work as a sound technician and designer. Now I want to design an interface from which I can monitor my wireless transmitters and see the input on some VU meters.

Basically I need to make an input routing from each of the interface inputs that goes to a VU meter and ends at a solo button. After this the signal will be send to a interface stereo or mono output on the interface.

I think it's not that complex but i need a little help on the way, some tips and tricks or links to helpful topics.

I hope you can help me, it would be great!

@Albsound The sort of job easily done with abstractions. I hope it is understandable.
solo_select.zip
David.

Thnx for the patch! i'm looking in to it right now, had some questions about the patch and the Autoclear. The autoclear isn't working in my opinion. What do the Recieves and Sends for Globr do? for the further rest this is exactly what i was looking for!

@Albsound Hello again...
The "glob" send and receives allow only one solo when "connected"...... so when autoclear is selected (the X in the box) selecting a solo clears any previous selections. When there is no X in the box you can select many inputs and monitor them all at once.........
The same feature as for Yamaha, Midas...... in fact probably all mixing consoles nowadays do this for monitoring. Means you don't have to look for and cancel any previous solos.
Yamaha call it "last cue" function.
David.

Ah nice! this was the only thing I couldn't relate to! nice one thanx!

@Albsound You're welcome.... I hope it is useful!
David.

@whale-av

Curious: why did you choose to use iemlib/pvu~ instead of just vu~?

Cpu load?

Thanx

S

@svanya No....... I built it quickly in extended (force of habit), checked it in Vanilla, and forgot that I have "pvu~.dll" in my "Vanilla Abstraction" folder.

It's a folder full of replacements for useful extended objects like [l2s] built as abstractions, but contains some .dlls where I have not got around to building the abstractions.
I should move that folder temporarily when I am checking patches for compatibility with Vanilla, or I will post patches that will only work in extended or a fully Dekened Vanilla (as I did here!).

I don't have [vu~] in any of my Pd folders. Where does it come from? Google drops the tilde which is not useful.
David.

@whale-av

My bad about [vu~]. And i apologize for the confusion (just assumed [vu] would have a tilde. It's the one i meant.

p.s. would love to see yr van replacements, as i do a lot of work in Mobmuplat, which is strictly vanilla and so misses lots of stuff, ex. zexy.

-s

@svanya All credit to those that put in the work.... unless it was me ABSTR VANILLA.zip
Abstractions only. I also dump .DLL's from various libraries in there for everyday work...... but they will do you no good for Mobmuplat.
Also, many zexy replacements depend on [list tosymbol] and [list fromsymbol]. Are they implemented in Mobmuplat?
David.

Hello whale-av, svanya, and albsound,
I am trying to get pvu~ to work on pd 048. I have iemlab in my Install directory.

Any ideas why it is not working?

@raynovich By "not working", what exactly do you mean? p.s. screenshots help a lot on that front.

@raynovich Very hard to know why it is not working.
I wonder if this one could work for you....
https://github.com/critterandguitari/Organelle_UI/tree/master/customized-externals/pvu
..... if dumped in your "extra" folder..... and Pd re-started.
David.

Hello,
Thanks for the replies. I am using an Apple laptop, but it looks to me like the files at the github site are for linux and PC. Am I wrong? Also, I am using

However, there might be an easier fix now that I think about it. What I am trying to do is connect the audio output (dac~) and input (adc~) to a VU meter. In pd-external I would use pvu~ to convert the signal so that the VU meter could read it. I assume this is a standard action. Is there a standard way that you put an audio signal into the standard VU meter?

As for not working and screenshot, I think this will suffice:

@raynovich More or less....... I could be wrong about the math....... pvu_subst.pd
None of the fancy stuff that [pvu~] can do, although all that could be added.
As an abstraction..... pvu2~.pd
David

Shoot! Yeah, that is all it is?

|audio signal|
|
|env~|
|
|- 103|
|
vu meter

I thought pvu~ was a more complicated operation.

@raynovich [pvu~] is much more complex.......
It holds the peaks and drops the meter down gently like a real mechanical VU meter....... which allows you to see all the values.
You can set it's arguments to your taste.
I might try to build an equivalent....... we will see.... and someone might well beat me to it..... but that will show you the correct levels..... although too fast for you to see them.
David.

Thanks and good to know. Do you know why pvu~ is not working in pd 0.48 but in pd-extended?

Also, as another curiosity, I am surprised that the vu meter does not accept an audio signal. It would seem to me that typically vu meters would typically accept an audio signal.

What am I missing?

@raynovich Here is my best attempt so far at a reasonable replacement for [pvu~]

It's response times are ok.... faster up, the same down........ more or less.
pvu~ substitute.zip

You are not missing anything...... but the VU is just a gui that takes numbers and not an audio object. That keeps it as cpu cost free as possible for a fairly complex gui, and it will work in a patch with no audio at all....... for example to show some incoming data that could have been sent by a PVU~ in a patch on another computer over netsend/receive (if that computer had [pvu~] working......!)

The replacement worked, and when I looked "under the hood" of your fix I saw how easy it was and I actually used to create them my self but pvu~ is cleaner.

I am just surprised that there is not another comparably clean option.