One question I can't decide - do I do individual FFTs on each channel, or are people more likely to just want a spectrum analysis of the total signal? (all channels summed) Currently it's doing it per-channel but I don't know what's going to happen to cpu for you guys running 7.1. Are people likely to want individual spectra for left/right/ctr etc?
Hmmm, System monitoring is Rainmeter, Raison d'être, id say as much info as you could output ( per channel), but i have no idea the difficulties or system usage that may result in...
Just look at all those %*#@ data points. Who knows what they mean, but that's beside the point.
FFTs should be available at the very least in stereo. One for every channel would be badass, with so many real time data points, some really interesting visualizations could be possible. Not a lot of people are running surround sound setups and those that do probably don't only play 7.1 audio on it, but if you already have it implemented and it doesn't cripple system performance, it wouldn't hurt as an extra option.
Ok I'll leave it the way it is and if your CPU gets slammed, you can always switch your audio device back to stereo or turn off the FFT I guess.
It's working pretty well right now but I want to convert the FFT data back into a log-scale spectral display which is a lot more familiar-looking. There is some lag which I can't get around - in order to get a high enough resolution on the lower frequencies, you need to use a big FFT size, but by using a big size, you're introducing that many samples of latency into the calculation. Another option would be doing it with a bank of bandpass filters instead of the FFT route, but I want to see if I can make it work this way first before I explore that. I'm also getting more frequency-spreading than I expected, i.e. when I run a sine wave through it I'm getting peaks on multiple frequency bands, so I'd like to figure that out.
I also want to put in an optimization where it'll bypass the FFT stage if the buffer is flagged as silent, which is true pretty much any time you're not playing audio on your system.
Dank420
I do not think that there will be difficulties with the system due to the addition of the peaks. I can not get them done. Something I did not properly prescribe
Dank420
I do not think that there will be difficulties with the system due to the addition of the peaks. I can not get them done. Something I did not properly prescribe
supernemo
getting the line to bounce lies in the Y
Y=((#barheight#)-([MeasureAudioRMS_L1:]*(#barheight#)))
barheight is just that height of bar, or in your case image which i think is 146
minus
audio level which ever measure you link it to (linking it to the same measure as graph will put it at top of bar) to make it higher/slower you will need to make new parent/child measure to change peaks/decays
(*) times
barheight again
and of course ever important DYNAMICVARIABLES=1 on each meter containing the equation
syntax important on equation as well as audio lvl times bar height happens before -barheight
0 x 5=0 or 146-0=146 (bar at bottom) .5 x 146=73 so 146-73=73 (bar in middle)
line 2 would be [MeasureAudioRMS_L2:] and so on down the line
i was adding into bottom.ini and made a mistake. if part of the equation is missing(audiolvl misnamed) bars dont move but rainmeter trys the equation anyway causeing larger cpu usage, so watch the spelling and labeling....
Last edited by Dank420 on July 29th, 2014, 7:22 pm, edited 1 time in total.
