Now my AlphaConceptPlayer has a real equalizer, and the desktop second.
![Smiler :)](./images/smilies/ab.gif)
dgrace wrote:If by "smoothen" you mean to change the rates at which they grow/shrink, yes you can adjust them via the FFTAttack and FFTDecay settings. See the docs here: http://docs.rainmeter.net/manual-beta/plugins/audiolevel
Cheers,
dave
I haven't tried. I'd probably setup a Calc that averages the low frequencies, and then try to measure the time between peaks for that average. Don't know how accurate it would be though - depends on your update rate. There's probably a better method but it's not something I know how to do off the top of my head. Good question!MarcoPixel wrote:I only got one request, is it possible to calculate BPM with it?
MarcoPixel wrote:
This is my result. I made an calc for every fft band which gets the values of the two bands left and right and calculates the average of them. The result is stunning
I only got one request, is it possible to calculate BPM with it?
If the bars are from the FFT/Band stuff, you can try playing with the Sensitivity option. If the bars are from RMS or Peak measurements, there's are RMSGain and PeakGain parameters you can adjust. See docs here: http://docs.rainmeter.net/manual-beta/plugins/audiolevelaloudasian wrote:I've got a question about how I can adjust the height of the bars displayed in the visualizer. For approximately the same loudness, the bars are much higher when I'm playing music on my laptop than on my desktop. I'm assuming this is because the output is giving back different values between my two computers. Is there a way I can apply a scalar to the values so I can increase/decrease the height of the bars displayed in the visualizer?
dgrace wrote:I've tried - it appears to be a bug in Windows. See thread here:
http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/c7ba0a04-46ce-43ff-ad15-ce8932c00171/loopback-recording-causes-digital-stuttering?forum=windowspro-audiodevelopment
I've already implemented the workaround they discuss there but it's still glitchy in some cases.
What that means is that as long as there is some media running in the paused mode at the background, the stuttering wont occur. I tested it by pausing a song in VLC player at the background and then playing another song in Winamp. The audio didn't stutter when I closed Winamp. I tested it using a combination of many different applications and the audio didn't stutter as long as there was an audio stream running in paused mode at the background.To stop the stuttering:
1. Load an application that creates an audio stream. i.e. Virtual PC (just needs to be in system tray), Media Player Classic (paused) etc.
2. Load up WMP, queue a few tracks and start it playing
3. Start the loopback capture
4. Hit next on WMP, which shouldn't generate a stutter
So, one possible way around the stuttering (until MS fix the bug), is to create a silent audio stream whilst in loopback mode - which is hinted at above. i.e. Create a render client, before creating the capture client.
Any progress on this problem? Or it there some workaround for it?dgrace wrote: I've tried - it appears to be a bug in Windows. See thread here:
http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/c7ba0a04-46ce-43ff-ad15-ce8932c00171/loopback-recording-causes-digital-stuttering?forum=windowspro-audiodevelopment
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