July 29, 2018
Code & Design
Dynamic Album Preview w/ Music Visualizer (2018 Album Showcase)
Dynamic Album Preview w/ Music Visualizer (2018 Album Showcase)
which…
The first half of 2018 introduced an unreal amount of amazing albums, from the entire G.O.O.D Music album series, to new childhood favorites Gorillaz & Panic! At the Disco, to double-sided Drake & Wiz Khalifa albums. Coincidentally, the first few of these “WebVR Experiment” sprints have led up to a really neat immersive music scene.
So it only felt right to dedicate an experiment sprint to this moment in music history:
The scene will contain six different album scenes with matching, customized environments, including a visualizer, with the selected album displayed in front of the user.
Up until this sprint, all the metadata used in our scenes (album pictures, tracks etc…) has been manually collected. It’d be spectacular if we could use a robust music API to dynamically load all data needed instead. For that reason we set out to use the official Spotify API.
~30 minutes into reading the documentation & testing examples two major obstacles became quite clear:
The first issue is unfortunate as I was counting on Spotify to provide media sources for individual tracks; since this isn’t the case, we’re going to settle on a single repeatable, track.
Playing around with a Node release of the Spotify API I did manage to get simple authentication running through an example provided. However, at this point, ~45 mins in, setting up authentication for just a sad six album image URLs seemed like overkill. Screen-shotting the albums would have to suffice for now. The A-Frame snippet below displays the static setup for the two rows of album buttons:
<a-entity layout=”type: line; margin: 1" position=”-1 1 -3">
<a-box id=”album0" depth=”.5" height=”.5" width=”.5" material=”src:#albumSkin0" cursor-listener></a-box>
<a-box id=”album1" depth=”.5" height=”.5" width=”.5" material=”src: #albumSkin1" cursor-listener link=”href: index1.html; visualAspectEnabled:false; on: click”></a-box>
<a-box id=”album2" depth=”.5" height=”.5" width=”.5" material=”src: #albumSkin2" cursor-listener link=”href: index2.html; visualAspectEnabled:false; on: click”></a-box></a-entity>
<a-entity layout=”type: line; margin: 1" position=”-1 .25 -3"><a-box id=”album3" depth=”.5" height=”.5" width=”.5" material=”src: #albumSkin3" cursor-listener link=”href: index3.html; visualAspectEnabled:false; on: click”></a-box>
<a-box id=”album4" depth=”.5" height=”.5" width=”.5" material=”src: #albumSkin4" cursor-listener link=”href: index4.html; visualAspectEnabled:false; on: click”></a-box>
<a-box id=”album5" depth=”.5" height=”.5" width=”.5" material=”src: #albumSkin5" cursor-listener link=”href: index5.html; visualAspectEnabled:false; on: click”></a-box></a-entity>
Inspecting the code above at length, one can see that we already implemented two key entity components: material, & link. Setting the “Material” component “src” property to an image in our asset management entity with the #albumSkin ID takes care of wrapping our box entities with the appropriate album skin. The “Link” component with the set “href” property links to a separate index.html pages that corresponds to the album clicked.
The GIF to the left displays the empty scene up to this point of the experiment. Nothing particularly new here relative to previous sprints — just slowly but surely becoming second nature.
There is certainly a more-programmatic way of doing this, but since the last experiment proved fruitful I deferred to the tested method of manually copy/pasting multiple sister Index.html files. Additionally, each of these sister files also had an associated Generator.js file that loaded the three-ring music visualizer described in the previous experiment.
We’re also using the exact same logic to stream, analyze, & attach our audio output data to the preloaded three-ring visualizer as the previous sprint. With everything tied up neatly & relatively fast, only one task remains we’ve never tackled before: pointing our Neocities domain to a custom-purchased URL.
We finally get to cross a big milestone in anything web-development: pointing CDN records to a custom domain. For this experiment, we’re going to first deploy our website to Neocities.org, then purchase our custom domain on Namecheap, & finally add the right CDN records on Namecheap to re-direct the URL to our Neocities app.
By this experiment, deploying on Neocities now feel natural — nothing new here. Purchasing a domain on Namecheap is also straight-forward. Now for the new part…pointing to our custom URL.
The first key take-away here is that custom domains are not supported on Neocities without upgrading to their “Supporter” user-tier. It’s $5/Mo to upgrade. Now with our upgrade paid, Neocities provides a really useful set of guidelines seen below:
Switching back & forth between the Namecheap panel & the Neocities panel, we concluded the aforementioned five steps in under ~ 15 minutes.
There we go, a custom domain now fully implemented: SummerVR.Club. On to WebVR Experiment #7!
New Public Components & Technologies Used:
