It can be useful when creating or debugging a skin that uses the AudioLevel plugin to know what the default Windows Output or Input device is, and have a list of available devices with the ID number you need to set in the skin if you are monitoring a device other than the default.
This skin will give you all the information, and allow you to copy the values to the Windows Clipboard, so you can copy and paste those rather long ID numbers into your skin if needed.
Requires the latest Rainmeter beta 3.2 r2326 or later from http://rainmeter.net. Also requires Windows Vista or later.
{2d89ffff-c125-43eb-baa6-e6c484865e74} Realtek Digital Output(Optical) (Realtek High Definition Audio)
{2f760934-76a8-4ff7-9562-e7d5293e3eb7} 4 - Digital Display Audio (AMD High Definition Audio Device)
{36c86755-6d3d-499b-9aee-5eb1155a17c6} 2 - Digital Display Audio (AMD High Definition Audio Device)
{5c106e65-26b4-4d05-a9bf-b207a71e9eaa} Speakers (Realtek High Definition Au
{f9613a2a-495d-431f-92d3-4cb658f469e4} 6 -
You do not have the required permissions to view the files attached to this post.
Since I haven't gotten a response to my post earlier:
thekey wrote:Does anyone else experience this bug and possibly know of a fix for this plugin "stalling" when using a PLAY bang? When playing music or other audio it works perfectly as intended, but if I have a skin utilize the play bang to produce a sound the visualization stalls out above the "zero" value. It happens with both my custom skin utilizing this plugin and the example one.
I noticed that it does not provide this problem when Windows Media Center is open, and the problem goes away momentarily when Windows produces a sound such as a dialog box opening.
Maybe if i add a gif recording it will make more sense toward getting a response.
Also for the record, the only thing I had done to the skin was change the bar colors and location, where left channel is on top, right channel is its "reflection" on the bottom (which i did since in all likelihood all my music/sounds will be similar on both channels). This happens with the default skin as well. Is there a workaround?
You do not have the required permissions to view the files attached to this post.
When switching audio outputs (i.e. speakers to headphones), I have to manually refresh the skin in order for the visualizer to work with the new output. Is there a workaround for this?
berrypicker wrote:When switching audio outputs (i.e. speakers to headphones), I have to manually refresh the skin in order for the visualizer to work with the new output. Is there a workaround for this?
If you're physically disconnecting the cable from one or the other, the DeviceStatus should change. You can then key on this in a measure and do a [!Refresh] - the example skin does this. If both outputs are always valid and you're changing the destination output inside some other app, I'm not sure how the plugin would know to take any action - you'll need to do it manually.
drakulaboy wrote:.raptor nice, show some action, and can you share the lua script?
Well, this is very very alpha at the moment. Currently only works with the current setup, and with Spotify. The spectrum works fine without spotify aswell, but no progress then. Also, if you edit size or anything, please remember that things might get weird...
(The sexy clock is Elegance2)
EDIT: would also love to know why the bottom part of the spectrum kinda clings together. if i play a tone at a certain frequency i can get the bars in the top end to stand out as singles, but at the bottom end its minimum 5
(probably doesn't show the issue very well, but here is a gif anyhow)
You do not have the required permissions to view the files attached to this post.
.raptor wrote:EDIT: would also love to know why the bottom part of the spectrum kinda clings together. if i play a tone at a certain frequency i can get the bars in the top end to stand out as singles, but at the bottom end its minimum 5
It's because of the way the FFT works. When you transform the signal to the frequency domain, the FFT splits up the frequencies linearly, i.e. if you sampling freq is 48khz and you did a 48-point FFT, you'd get frequency values for 0hz, 1000hz, 2000hz, 3000hz, etc. But our ears don't hear that way, we hear in log scale down to about 20hz. So what we'd like is bars for 20hz, 25hz, 33hz, 42hz, 60hz, etc. To get that kind of resolution at the bottom end, you need to use a LOT more points in the FFT. The more points you use, the more the CPU goes up, and the longer delay between what you're hearing and what you see in the meter. So it's a tradeoff. You can try ignoring the really low frequencies by setting your FreqMin value higher, or try increasing the FFTSize.
The other way to implement it would be a bank of bandpass filters on the signal, rather than an FFT. I doubt I'll get around to it though, honestly.
dgrace wrote:
It's because of the way the FFT works. When you transform the signal to the frequency domain, the FFT splits up the frequencies linearly, i.e. if you sampling freq is 48khz and you did a 48-point FFT, you'd get frequency values for 0hz, 1000hz, 2000hz, 3000hz, etc. But our ears don't hear that way, we hear in log scale down to about 20hz. So what we'd like is bars for 20hz, 25hz, 33hz, 42hz, 60hz, etc. To get that kind of resolution at the bottom end, you need to use a LOT more points in the FFT. The more points you use, the more the CPU goes up, and the longer delay between what you're hearing and what you see in the meter. So it's a tradeoff. You can try ignoring the really low frequencies by setting your FreqMin value higher, or try increasing the FFTSize.
The other way to implement it would be a bank of bandpass filters on the signal, rather than an FFT. I doubt I'll get around to it though, honestly.
dave
Ah, had a feeling it had something to do with that. Silly ears, not tuned to my pretty desktop
Either way, thank you so much for this plugin, I'm having a blast!
I've already implemented the workaround they discuss there but it's still glitchy in some cases. Unfortunately from my side all the data looks exactly the same - there's no way to know when it's happening; it all looks like valid data. Sorry, wish I had better news on that one.
dave
Sorry for hanging on to this, but I'm getting the same bug. Since it seems not solveable on a plugin level, can we talk about workarounds for skins?
One thing that works for me is constantly looping silence in the background when loading any skin that uses your plugin, like: