hey folks --

spent a lot of time getting this thing to work
you have to manually turn it on
you should see a select box with the label 'Analyzer FFT Size'

there was also some issue where people had to click around to get entries to play after the popout loaded -- this has hopefully been alleviated by forcing user interaction (click/touch) if the audio context isn't ready to go. this is a feature of the modern web and not how i'd prefer things to be, but i'd rather things work the way the modern web demands then have half ass user experiences sometimes. firefox specifically seems to demand a user interaction (click/touch) every time the window loads which is not fun!

please let me know if you have any issues
and say what OS and browser you are using!

thanks,
all n00bs!!!

I WJAS JUST THINKING OF ADDING GIHIS HOW DARE YOU STEAL MY ORIGINAL IDEA

working fine here on chromium-based web browsers (on ubuntu 20.04 gnu/linux)

firefox, dang... it used to be so good once you click "allow audio and video" for autoplay...

oh that's rly cool

@DefenseMechanism yes, it looks weird on Waterfox 2020.10 - and might also do on all other web-browsers based on Firefox.. - Otter doesn't even play anything... - and surprisingly works fine on Midori (the web browser, not @MiDoRi ! ;) ) - and i tried on Dillo as well! ;D (i guess Puke tried it as well? ;D ) - on Opera works fine

honestly, i deved it 100% on chrome and, like a dufus, i pushed it onto the live server w/o testing it on any other browsers

i've never even heard of waterfox or midori or dillo before xD

it doesn't work on snowferret or blizzardotter or frostmole or dewrabbit or drizzlegrizzly either ;(

note to self: playback when not logged in is borked

here's an odd thing i discovered about the visualiser: if you begin song playback at low volume then the waveform will stay at low amplitude regardless of the volume you change later (i assume this is due to your volume compensation). likewise, if you start the waveform at max volume it'll begin with max amplitude and won't change from there. i think you might want to compensate from the saved volume amount when playback first occurs (iirc it's stored as a cookie?)

well that's weird -- might be a caching issue?

the next step for the analyzer (besides bug fixing / hardening) is to log the rms/min/max data to the entry info so the player can do auto compensations (quieting or loudening severe audio level disparages which drive me nuts when i'm listening to playlists)

i still don't know what my target is -- the RMS values can sometimes seem very arbitrary, but maybe maxing out somewhere between 0.35 and 0.40, but also not clipping based on MIN/MAX

so... the html5 audio nodes right now are:
mp3 playback -> gain node -> analyzer node -> gain/volume node

the 1st gain node is meant for auto compensations
the last gain node is meant for user volume control

what i'm thinking is shouldn't the user volume node be first before the compensation? one thing that happens is if the volume is initially set to a low value and you play a track, then raise the volume back up, it's still low volume because it's multiplicative. the other way works fine (high volume to low).

Noticed issues: the player doesn't work at all on Yuzu Browser 6.0.2 (Android) - playback won't start
The same issue exists in Bromite 92.0
Old mobile Firefox (68.11.0) somehow works flawlessly except I don't see any visualisations

i have a bromite version (repackaged as /e/ browser) based on chromium 83.0.4103.93. playback works fine on my end except for the visualiser which doesn't display a waveform. caniuse says it should work but i don't really want to look into it because i still haven't figured out debugging web stuff on phones.

yuzu browser looks like it's based on android webview so i would update that if possible. also try enabling the "desktop site" option, maybe that'll help to initialise the audio context or something

Updating webview component sadly did nothing aside of making entire BotB scroll in a choppy fashion. Fun

it seems like the player for not-logged-in users only doesnt work if you access the entry page directly by loading a new tab. if you load the page in an already opened tab by clicking on the entry link on botb, the player loads fine.

example:
load this: https://battleofthebits.com/arena/Entry/brassoschmasso.it/43255/ in a new private tab, the player wont load. (chrome) then click on next entry and the player for the other entry will load. if you go back, the player for 43255 will load too

It rules I love it

Important fallback feature request: I think it would be nice to add a button that points to /blahblah/EntryPlay/[ID_HERE] as a failsafe fallback option that points to the MP3 directly. That would put an end to the incompatibility issues while being trivial to implement

i at least fixed access for the embed players which show up on sample entry pages and entry pages viewed by guests

this sucks how much change came from using the html5 audiocontext object -- like we were already using the html5 media player -- wouldn't think things would change as much as they have

not sure exactly how to present users with the failsafe link? tiny text that says something like "direct access to playback media"?

@nitrofurano UBUNTU GANG

Works for me on Ubuntu 20.04 on FIrefox, it slows down beyond 4096 but that just makes sense.