[topfs2]

o/

https://github.com/topfs2/blurred-spectrum

Here I mostly focused on getting the blur from the above examples, which I'm roughly 90% happy with. Might want to revisit and do it better via shaders instead of double assets but this is easier to achieve on non-glsl hardware.

I can see if I can find the initial patch I did in c++ but there I mostly tried to get the fft data out, and this is probably something your way better at me at so would love help It seems to me that the fft data a visualizer can ask for is very wrong, and the spectrum analysers we have actually do a conversion on their own from the PCM instead. The FFT you can ask for is PCM chunksize wide, which seems wrong according to nyquist.

Anywho, another thing which was discussed during devcon was the ability for skinners to tell the visualizer stuff. E.g. accent colors, bar sizing and such things. Also on this topic it would be awesome to be able to use WindowXML to aid the visualisation, as in my github example I write out title and artist and it would be awesome to not having to port GUIFontTTF and friends to each visualizer Not sure if you have any ideas on this?

So not sure how helpful the github repo is to you but if you have ideas on the other stuff that would be awesome, then I can hopefully find some time after Helix to work on this again (unless I'm stuck in the logging changes)

[ironic_monkey]

in principle visualizers can already do gui through the same bindings as pvr. not sure how flexible they are though. but it's certainly xml based.

[topfs2]

Interesting. Did not know that PVR could. You have an example of an add-on which does it?

[ironic_monkey]

vdr, hts, wmc.

[pike]

more VIZES for the masses!

[ironic_monkey]

well, it's certainly borked topfs2. for starters;

https://github.com/notspiff/kodi-cmake/c...29cde623e9

as for nyquist; sure, some of the freqs are aliased, not much you can do about that. however, that not all that relevant here as such.
it's a windowed fft - only certain freqs are let through (iirc it's a standard hann squared cosine). which basically is a means to get very little energy in the aliased modes (very simply put!)

[popcornmix]

well, it's certainly borked topfs2. for starters;

https://github.com/notspiff/kodi-cmake/c...29cde623e9

Nice find. That definitely was broken. Even with this in, it looks broken to me. Try a frequency sweep. E.g.
http://www.audiocheck.net/download.php?f...20klin.wav

and watch with the spectrum visualisation. Doesn't look at all right.

[ironic_monkey]

yeah, i'm aware. hence the 'for starters'.

[da-anda]

guys, i noticed that the waveform viz on all GLES devices is way off (like 200% amplitudes) - might this be related to the issue mentioned in here? On Windows the amplitudes are way lower and max out within visible screen, while on GLES they go out of screen. Noticed on my PI but it's also on Android.

[popcornmix]

guys, i noticed that the waveform viz on all GLES devices is way off (like 200% amplitudes) - might this be related to the issue mentioned in here? On Windows the amplitudes are way lower and max out within visible screen, while on GLES they go out of screen. Noticed on my PI but it's also on Android.

Looks like the scale factors for "bar_height" parameter is different between directx and opengl versions of spectrum.

Bit that's a minor issue. The frequency sweep sample I linked should produce a single peak in the FFT that moves from left to right.
You can't see that at all in the spectrum visualisation. Feels like the output of the fft is mostly garbage.

[ironic_monkey]

the spectrum viz doesn't use fft data... there are no vizes in mainline using the fft data. it's still borked, but that is NOT a way to test it.

[popcornmix]

the spectrum viz doesn't use fft data... there are no vizes in mainline using the fft data. it's still borked, but that is NOT a way to test it.

Wow. No wonder it looks nothing like a spectrum analyser display...
I really think it should be using the fft data (well assuming the fft data is fixed).

So it just uses a random subset of audio samples. That would explain why it looks like random noise.

[ironic_monkey]

well, it's amplitude bins for each data set. so not entirely random but surely not a proper spectrum.

[Memphiz]

Your sweep test results in the whole bar cube getting filled with heigh bars as the samples play until its almost a complete cube (last 3 rows continue to jutter around 10% maybe). Finally i also understand why this viz doesn't look like i would expect it

As a side-note on atv2 (gles too) it doesn't go out of the screen like da-anda described. Do you have the bar height set to maximum maybe? (i suppose a difference in our viz settings).

[da-anda]

Memphiz - how did you test - with the sample form popcornmix or regular music? I was playing music