Does anybody know of an accurate mono or stereo VU meter?
Abstraction or external.
Using env~ with the Pd internal level meter works but I don't seem to have any reference of the real peak or RMS level.
The only thing I could do is sending some test signals from the SPDIF out to my RME sound card and tweak the level to match 0dB.
But there should be an accurate level calculation directly within Pd .
I'm on Pd 0.49 on Debian.
Thank you!
Ingo
- Ingo ingo@miamiwave.com [2020-04-21 09:03]:
Does anybody know of an accurate mono or stereo VU meter?
Abstraction or external.
Using env~ with the Pd internal level meter works but I don't seem to have any reference of the real peak or RMS level.
The only thing I could do is sending some test signals from the SPDIF out to my RME sound card and tweak the level to match 0dB.
But there should be an accurate level calculation directly within Pd .
Have a look at the internal object [slope~] help patch. There is a subpatch for peak-meter there. But...
I'm on Pd 0.49 on Debian.
... it is only available starting with Pd 0.50 which is available in Debian testing. Check for available versions of Pd on your computer with the shell command $ aptitude versions puredata
- Peter P. peterparker@fastmail.com [2020-04-21 10:23]:
- Ingo ingo@miamiwave.com [2020-04-21 09:03]:
Does anybody know of an accurate mono or stereo VU meter?
Abstraction or external.
Using env~ with the Pd internal level meter works but I don't seem to have any reference of the real peak or RMS level.
The only thing I could do is sending some test signals from the SPDIF out to my RME sound card and tweak the level to match 0dB.
But there should be an accurate level calculation directly within Pd .
Have a look at the internal object [slope~] help patch. There is a subpatch for peak-meter there. But...
Oh, I mistyped the object name, it should be [slop~]!
I'm on Pd 0.49 on Debian.
... it is only available starting with Pd 0.50 which is available in Debian testing. Check for available versions of Pd on your computer with the shell command $ aptitude versions puredata
Once you can create the [slop~] object look at https://plessas.mur.at/devel/devel.html for an abstraction called [rpdb~] which uses [slop~] to output rms and peak as a list formatted for use with Pd's VU meter object.
Thanks, Peter!
At the moment I cannot change to 0.50 but I'll keep it in mind for the near future when I will have to update my system.
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Peter P. Sent: Tuesday, April 21, 2020 10:52 AM To: pd-list@lists.iem.at Subject: Re: [PD] VU / Peak Meter ? - external or abstraction
- Peter P. peterparker@fastmail.com [2020-04-21 10:23]:
- Ingo ingo@miamiwave.com [2020-04-21 09:03]:
Does anybody know of an accurate mono or stereo VU meter?
Abstraction or external.
Using env~ with the Pd internal level meter works but I don't seem to have any reference of the real peak or RMS level.
The only thing I could do is sending some test signals from the SPDIF out to my RME sound card and tweak the level to match 0dB.
But there should be an accurate level calculation directly within Pd .
Have a look at the internal object [slope~] help patch. There is a subpatch for peak-meter there. But...
Oh, I mistyped the object name, it should be [slop~]!
I'm on Pd 0.49 on Debian.
... it is only available starting with Pd 0.50 which is available in Debian testing. Check for available versions of Pd on your computer with the shell command $ aptitude versions puredata
Once you can create the [slop~] object look at https://plessas.mur.at/devel/devel.html for an abstraction called [rpdb~] which uses [slop~] to output rms and peak as a list formatted for use with Pd's VU meter object.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
- Ingo ingo@miamiwave.com [2020-04-21 13:10]:
Thanks, Peter!
At the moment I cannot change to 0.50 but I'll keep it in mind for the near future when I will have to update my system.
Note that you could add entries for Debian testing in your /etc/apt/sources list but have your system default to stable by creating a file /etc/apt/preferences that reads something like this
Package: * Pin: release a=stable Pin-Priority: 910
Package: * Pin: release a=testing Pin-Priority: 900
Since the entry for stable will have a higher priority, your system will prefer packages from stable, but you can alternatively install package versions from testing, by first querying $ aptitude versions gem and with that info explicitely asking for the testing version $ aptitude install gem=1:0.94-1+b1
Read https://wiki.debian.org/AptConfiguration as above instructions are without warranty.
Hi,
On 21/04/2020 12:20, Peter P. wrote:
- Ingo ingo@miamiwave.com [2020-04-21 13:10]:
Thanks, Peter!
At the moment I cannot change to 0.50 but I'll keep it in mind for the near future when I will have to update my system.
Note that you could add entries for Debian testing in your /etc/apt/sources list but have your system default to stable by creating a file /etc/apt/preferences that reads something like this
Much better than to risk mixing stable+testing is to use the backports repository, which does have pd-0.50:
deb http://deb.debian.org/debian buster-backports main deb-src http://deb.debian.org/debian buster-backports main
apt install -t buster-backports puredata
Documentation:
https://backports.debian.org/Instructions/
Claude
- Claude Heiland-Allen claude@mathr.co.uk [2020-04-21 16:27]:
Hi,
On 21/04/2020 12:20, Peter P. wrote:
- Ingo ingo@miamiwave.com [2020-04-21 13:10]:
Thanks, Peter!
At the moment I cannot change to 0.50 but I'll keep it in mind for the near future when I will have to update my system.
Note that you could add entries for Debian testing in your /etc/apt/sources list but have your system default to stable by creating a file /etc/apt/preferences that reads something like this
Much better than to risk mixing stable+testing is to use the backports repository, which does have pd-0.50:
deb http://deb.debian.org/debian buster-backports main deb-src http://deb.debian.org/debian buster-backports main
apt install -t buster-backports puredata
Documentation:
Yep, indeed. Much better! Thanks Claude!
Em ter., 21 de abr. de 2020 às 05:33, Peter P. peterparker@fastmail.com escreveu:
Have a look at the internal object [slope~] help patch. There is a subpatch for peak-meter there.
I now realize it's using the RMS display in [vu] instead of peak for that, but it does look better.
I'm actually working on an update of iemgui's documentation, and it'd be good if the help file of [vu] had such an example as well.
Now, the thing is that the peak level will have a visual decay, but not the RMS, and I don't know how to easily deal with that.
That is to say I've always missed a more proper object in Pd vanilla to offer rms and peak level feed for [vu].
In the ELSE library I developed a variant of [env~] to report peak detection and I have a meter~ abstraction where I do a decay for both the RMS and Peak levels
cheers
On Mon, 2020-05-04 at 13:58 -0300, Alexandre Torres Porres wrote:
Em ter., 21 de abr. de 2020 às 05:33, Peter P. < peterparker@fastmail.com> escreveu:
Have a look at the internal object [slope~] help patch. There is a subpatch for peak-meter there.
Now, the thing is that the peak level will have a visual decay, but not the RMS, and I don't know how to easily deal with that.
That's exactly how the big analog consoles do it. Or maybe there is a decay, but a much quicker one, whereas for the peak there is a even a short hold time.
That is to say I've always missed a more proper object in Pd vanilla to offer rms and peak level feed for [vu].
In the ELSE library I developed a variant of [env~] to report peak detection
You can't have proper peak detection using [env~]. It will always calculate an rms value.
Roman
Em seg., 4 de mai. de 2020 às 15:20, Roman Haefeli reduzent@gmail.com escreveu:
That's exactly how the big analog consoles do it.
well, that changes things :)
Or maybe there is a decay, but a much quicker one, whereas for the peak there is a even a short hold time.
sorry, "a even a short hold time"?
You can't have proper peak detection using [env~]. It will always
calculate an rms value.
Sure, hence it's a variation, which takes into account the peak, not RMS.
My idea was in fact to propose this as a second output for [env~]
but anyway, seems [slop~] is doing the trick now and that what I thought was bad was actually how things work, so all I can say is that we could make a better/proper example on how to feed both RMS and peak into [vu]
-
Alexandre Torres Porres -
Claude Heiland-Allen -
Ingo -
Peter P. -
Roman Haefeli