Happy Friday, Slipmat peeps! 
This weeks changes might be the most pivotal in the 10-year history of Slipmat – and they’ve been a looong time comin’. Historically our tools have been focused around live streaming and other online usage, but there’s literally no reason why things like song requests or tipping should be restricted to online events only. We’re now taking determined steps towards making all our tools --when it makes sense-- to be totally event-type agnostic. It shouldn’t matter if you take requests in a club or in an online streaming event – it should Just Work.
This opens up totally new possibilities for so many things and innovation with modern APIs and technologies. You could build things like “Queued Up / Playing Soon” displays for a club using “will play” items from the request system, Franchise Top-40 lists from combined event set lists, or fully automatic custom Web-based “search to jukebox” players literally in minutes using our existing open APIs and AI tools. Essentially for ~free 
In addition to these offline-focused changes, we’re also finally getting in some actually interesting and better enriched homepage feed content via a curated list of blogs and other sites around the world. This is the beginnings of a hopefully rich and long-evolving process of building a community-maintained ethical and open recipe for better music discovery. Current big discovery channels and algorithms are totally dominated by big labels and money. It should be much easier to find those niche artists that you’d love – and we’ve got the tools to do it. So let’s!
But, without further yapping, here’s this weeks changelog.
New Features
-
Artists can now create non-streaming events for an away from keyboard event or any event that happens off-Slipmat. Our new and upcoming tools like the new Song Request app, the Script Studio, and the still-in-development Gig Booking app are designed from ground up to work with all kinds of events, not just for online live streaming. While the online experience is still our main focus for the core product, we aim to make it easy and meaningful to use all the relevant tools in your off-Slipmat workflows as well.
The first non-streaming event type is a generic “Request Event”. To create one, go from artist dashboard to Schedule Event → select Other Events → click “Create request event”. The form is purpose-built for this use-case and the defaults are different from normal events as well. The public page for a request event is simplified version of slipmat
This change was one of the biggest refactors in the history of the current codebase. Most of the changes are still under the hood but we’ll be reaping the benefits from this one for a long time to come. Also, as this is the initial iteration of this architecture, I’m fully expecting things to evolve quite a bit in near future after some experiences from real-world usage.
-
Artists can now opt-in to enable the song requests for anonymous listeners. This is again mainly for AFK-events. Last weeks addition enables you to print a QR-code that opens up the request system directly on your phone, now it can also be used without a Slipmat account. If you play in a club or at a wedding, for example, it’s likely that most of the audience aren’t slipmnat users; they can now make requests regardless.
Anonymous access is at the moment very limited by design, and it’s highly encouraged to make that account (it’s super easy as it can be done in seconds using Apple or Google account). It’s easy to tweak these things in the future if we get some feedback.
-
Artists can now opt-in to Spotify search for the song request system. It does exactly what it says on the tin: allows listeners to search and submit tracks directly from Spotify. This feature uses our own internal Spotify search API which is part of the new Slipmat Music APIs – free to use and experiment for all Slipmat artists.
-
After some brainstorming, artists now have a supercharged QR-code – greatly improved from last week. Instead of event-based codes there’s now just one smart QR-code that always redirects to whatever makes most sense: your artist page if you aren’t live, the event live page if you are live but the requests aren’t on, directly to the request page if the requests are on. The code is unique for artist and will never change so you can print it out permanently, put it on your live streams, or wherever you like. On top of everything else, the scan redirects are counted so you can keep tabs event-by-event how much the code is being used. You can find your code from your artist dashboard → QR Code.
-
Our homepage feed features now fresh listenable music and music links extracted from the from various publications whose RSS feeds we follow. At the moment we follow 18 sites (full list TBA!) but the goal is to allow the community to add any blog or site that publishes RSS feeds to the feed. The feed is so much more interesting and useful now – and we’re only getting started! Eventually when we figure out a good way to normalize the genres we can allow you to subscribe to genres and artist for automatic music discovery. And, of course, we will allow users to post their own music links as well. The feed is a very complex and deep topic in itself but the main goal is to make Slipmat a not only good but Great and ethical source to discover and enjoy new music via the open community without unethically tuned algorithms or ads (like the old Disc Jockeys and radio shows originally were back in the day). If you have any ideas, we’d love to hear them!
Enhancements
-
The initial page load time for authenticated users has been reduced by ~63% by improving the data fetching logic and pulling less data on initial page load. The whole process is pretty complex as we want to minimize any flashing and unfinished image loading before we close the loading spinner. There’s still a lot to improve here, and the goal is to make these iterative steps every now and then to keep the site feeling at least half-decent on initial load.
The real-world wall-time for opening our homepage depends currently heavily on third-party sites as the images from the homepage feed come almost explusively from our RSS feed providers and YouTube and Spotify. Pulling this data to our own cache temporarily is most likely the next big optimization step.
-
We’ve re-enabled our automated CI-pipeline (meaning all the code changes are automatically tested and deployed into production as soon as all tests pass) using new thirdparty service called Blacksmith. Our code is hosted on GitHub but their current infrastructure is unreliable and it costs us money to keep pushing changes as often as we want to. Blacksmith has a generous free tier and their infra is faster and more reliable. We hope to be able to pay for their services in the future. If you want to support to cover our infra bill, you can donate via the live page support-button.
-
We’ve improved the website Sentry logging. The frontend code is served via CloudFlare Workers and has two layers: server-side and browser-side. Previously only browser code had Sentry telemetry but now we have full visibility to server-side also, which makes debugging much easier and faster.
UI Tweaks
-
We’re transitioning into the rewarding phase of tweaking already working UIs to be more user friendly and focused. The example image above is from the latest --still very much a work in progress!-- mobile-first optimization of the listener song requests UI. The North Star here is “how could this be simplest and easiest possible for a first-time user”.
The old UI had evolved to first have one feature, then another and then another until it just was a total mess on a mobile screen. Now the workflow is more optimized for small screens. What’s still missing is the extra features and better optimizations for larger screens and better search and things like separate artist / album / song views. There’s a lot to improve here still, but we’re on the right track now
- Homepage feed items have had minor UI tweeks.
Bugfixes
- Despite our best efforts, last weeks chat refactor wasn’t the final one quite yet. This week we fixed the ordering of the messages to always be correct and predictable. Fingers crossed there won’t need to be a fift refactor next week
- Artist Crew presence in various user lists has now been properly unified. All lists use now the same source and the logic is clear; user who hasn’t physically joined to the event is not on the event user list, no matter if they are crew or not.
- Artist fan button state on the live page is now initialized correctly. Previously you could fan the artist and the button state would change, but after refreshing it would still show the status as unfanned. Now the state is correct at all times. Thank you @Taustahemmo for the bug report!
- The artist social media links on the event end screen now work properly. Thank You @kirsi for the bug report!
Our Sentry instance keeps being clear, apart from some short-lived miscellaneous development incidents, which means that we don’t have any known unhandled bugs in the codebase
Music API Under The Hood
Building automated pipelines like our new homepage music feed items is extremely challenging to get right. It’s trivial to get one track from one provider, it’s about 10x harder to try to find the same release from another different provider. Doing this correctly w/o human intervention is at least 100x more difficult. We need to do this right if we want to enrich the data for the Slipmat Music API. We’re now getting in the infamous “the first 80% is only 20% os the work” phase where every single day some new piece of data exposes a flaw in the current system. Only thing that allows true progress is real life data from things like the artist track collection uploads and event set lists. We already have tens of thousands of very good examples of both good and bad data, the tough work is organizing it into meaningful signals.
We’re using free sources like MusicBrainz, Wikidata, and Discogs as much as possible but free resources have often serious limitations. For example, Musicbrainz is by far the most rich database for basic information but it also limits the queries to 1 per second which doesn’t sound that slow at first but if you for example upload a not-that-big playlist of 20k tracks to the request system, it will take at minimum 14 days to query every track on it. In real life as we need to do other queries as well and because the availability is not that good in practice the 20k playlist will take ~one month to fully enrich with our current architecture. It’s more than likely to be able to 10-50x this speed with some better engineering, though.
Still, I’m already pretty proud of our current Music API as it is. It already returns much better data from artists that for example Spotify does, and this has been their only fucking job for the past 18 years! I know that many companies would happily buy this data but I’d much more want to open source it as Musicbrainz and Discogs have done. And if we ever find the funding to do it (either from our own supporters or from an outside investor), that’s exactly what we’ll do 
For now we’ll just keep providing the access for free for our artists.
PS. I have one ask for all Slipmatians: if you know an artist or a music lover that would enjoy and benefit from what we do, please send them a link. Or post to your socials. All mentions are greatly appreciated! 