-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added: Make the Histogram
component display the actual audio instead of showing random bar heights
#1297
Conversation
82ba5d4
to
eca4624
Compare
Very nice, Drikus! I do wonder about @jaburgoyne's opinion though, just based on the screen capture. What do you think? Perhaps also good to add a screen capture with more up-beat music? Btw, it may be my browser settings, but for me, the current video is silent. As for the number of bars: I always thought that 8 was a good number. We should indeed first make sure what exactly the |
Looks great! I also cannot hear the music, though, and I wonder a little bit about the bars. As for 8 vs. 10, that's really an aesthetic choice; either is fine with me. I worry more about the frequency bands chosen: is it always a descending slope with more low frequencies and fewer high frequencies, or are there musical examples in our experiments with other shapes? If it's always or almost always a descending slope, then we may want to cut out the bars corresponding to the highest frequencies |
eca4624
to
4249f8c
Compare
048f4d0
to
a960ae3
Compare
I've altered the histogram strategy by now selecting 11 frequency bands and removing the first three. That seems to give better results already. What do y'all think? Do you want a new example video or should I merge this and tweak it whenever we aren't satisfied with it? |
6e3fc73
to
a9307d7
Compare
If you think it looks good, let's merge and see indeed! Thanks. |
…ndom bar heights
…actual audio frequency data
…d use correct props
…id it overcrowding the histogram
a9307d7
to
a4e7017
Compare
As described in the title: This PR makes the Histogram component display real-time audio frequency data instead of random bar heights. There's probably more to improve, like playing around with the amount of bars. For example, the fftSize on the analyzer is set to 32. This is mandatory as the value should be "(...) a power of two in the range 32 to 32768".
I don't know if setting that size to 32 means that it has data for showing 32 bars. I set the default amount of bars to 10 now as that (subjectively) seemed to represent the audio pretty well, but it may mean we are missing a huge chunk of the frequency spectrum. Maybe it's also worth investigating taking the average of every 4 bars and then show 8 bars in the end, or taking every 4th bar in the 32 bars, I don't know, I'm open to ideas.
Screen.Recording.2024-10-01.at.11.33.10.mov