randosigma / audiusplaylister Goto Github PK

I've noticed some Audius Nodes downgrade the https protocol to http protocol for some of the assets which can be caught as a FAILURE by browsers which are trying to validate secure protocol as always required (i.e. Firefox) so it would be nice to de-escalate the failure gracefully by falling back to other Audius Nodes for service or retrying.

I've got some ideas on how to accommodate this functionality. If the app is started being aware of GET arguments describing the play-list and the UTC timestamp when it was begun, it should be possible for a second browser to be started, calculate UTC difference, apply that to the playback time of the tracks in the play-list until it catches up with the initial arguments.

Of course, the sync can never be exact due to all the variances between endpoints, their access to accurate time, and all the other services between the two listeners with their individual web experiences. We can use UTC time as a common element and we DO know the play-time of each track thanks to the code.

Timing Chart:

User #1 sets a "ListenWithMe" flag on their session. When they hit the play button the app will offer them a copy-link to an URL which they can paste into any chat environment. The string they chat will include a href to others to "follow" them in playback.

User #2 sees the link in a chat session. Clicks it to launch a web-browser which pulls the arguments including UTC start time and the app will then attempt to load the play-list, check the time of each track, subtract time from the Now() until the UTC is relatively close. The release the playback to autoplay.

While the functionality for playing tracks of music and pulling the artwork for individual tracks is in the code. It may be nice to have the Playlist Name, Playlist Creator, and Playlist Artwork showing somewhere on the UI.

The autoplay functionality of the existing code works on Windows Chrome, MS Explorer, Windows Firefox, Brave, Linux Chromium, Linux Firefox, MacOS Safari, MacOS Chrome... but not iOS Safari. Seems to be related to aggressive lock-down of the iOS Safari browser and requires the user to hit the PLAY button on each track. Is there a work-around without adding any 3rd party extensions or asking the user to mess around with the Safari Security Settings regarding the Web Audio API?

It would be nice to have that option and perhaps a switch to allow the user or host to switch it either programmatically or by user input.

Investigate if it would be possible to run Audio Object through a Gain object tester and display a visualizer in the cVisualiser DIV on the full-screen interface. It's very likely that some browsers cannot handle it but the results would be phenomenal.

It may also be possible to use the Gain to auto-adjust the dB output to defeat wide ranging volume levels on a track-by-track playback.

Inspiration: Frank's Laboratory:
https://www.youtube.com/watch?v=VXWvfrmpapI&list=WL&index=1

The initial release of this software pulls a list of Audius API Node Servers but only uses the first one. Ideally, we would gather the entire list and arrange them so that we had fall-back nodes for the times with a node is unexpectedly out-of-service or the Internet throws a surprise.

If we could receive meta-data about a track's dB level we could automatically weight the volume levels on playback to try to balance the overall tracklist playback volumes. In other words, if one quiet track were followed by one very LOUD track the experience could be distracting from enjoying the music.