matclayton

Our experience is the opposite, we have a pretty large flow typed code base, and can do a full check in <100ms. When we converted to TS (decided not to merged) we saw typescript was in the multiple minute mark. It’s worth checking out LTI and how the typing on boundaries, enables flow to parallelize and give very precise error messages compared to TS. The third party lib support is however basically dead, except the latest versions of flow are starting to enable ingestion of TS types, so that’s interesting.

Selling is a whole other set of issues and one we could likely solve, but not one we’ve worked through.

We’re an online platform dedicated to DJs, licensed with free and paid tiers. We mainly do ondemand streaming but added live in 2020.

We've talked to twitch on and off over the years, but nothing specific to this. Music licensing data pipelines are a massively complex topic and very hard to get right. Its one of those areas you can only appreciate having done it. It looks trivial from the outside, my guess is they will be starting that work now, and in about 6-12 months time the complex reality of it will start to set in. Ironically the hardest part isn't even figuring out the track, its figuring out which major label owns the rights for it, in the territory it was streamed, on the day it was streamed. This is even more complex on the publishing side, where you can have multiple writers.

100% its way less than 1% of their streams, the CEO said as much recently. However that doesn't mean that the music labels are ok with copyright infringement being on the platform. I guess this is the real question, they clearly had to do a deal or shut it DJ's on the service. They chose to do the deals, so will they now lean into it as its an active area for investment, or was it a necessity to avoid a lawsuit etc. Time will tell, and its great to see them addressing this problem and the playing field being levelled for everyone else we was already paying for rights.

It'll depend a lot on the deals being struck, I can only speculate on the structure. The weird rules stem from the US copyright laws, and are therefore are impossible for a company like ours to get changed. We benefit from lower rates because of this and can make a service which will survive long term, so its a tradeoff we believe is worth it. I would stipulate that by going outside of those rules, they will have to pay a larger chunk of revenue to the labels, and it'll increase the ad load and cut the revenue passed to DJ's. Ultimately we decided that wasn't the approach we wanted to take, and the trade off was a good one, we'll find out with time which way they went.

Thank you, massively appreciate it :) Any feedback just hit up [email protected] and they'll pass it all on to the right folk!

Depends on if you are on free or Pro account as the uploader, if you are on Pro we up the bitrate substantially. Beyond this, it also depends on the device the user is listening on, we'll switch over to Opus when possible, which makes a big difference. If you want to max out the quality I would recommend you get Pro and ensure you listen on Chrome (or mobile apps). We'll do up to 320k on aac and 192k on opus. On Live we do something similar and last time I checked we did substantially higher rates than twitch on audio, but lower bitrates on the video.

Have you got a reference for how they are tackling publishing rights? I've been looking for it and only found references to labels so far.

That serial number sends shivers down my spine. I also used to work on this system, and still do! At one point seagate admitted that the firmware was faulty. It would periodically stop responding under load, and cause the raid controller to think the drive had failed, causing it to remove it from the array.

I’ve never seen this posted publicly by them, but I’m fairly sure a revised firmware was offered. We deemed it too risky to upgrade the drives one at a time, so built a new cluster on Western Digital drives.

What’s frustrating about this change is that Apple keeps changing the terms on it. Until last week the T&C’s included the phrase “exclusively”. This allowed you to provide the user with your own sign in system and avoid forcing the google/facebook lock-in, however removing this crucial word means for those of us with apps in the market with social logins, we have to add yet another one.

This is going to lock more users to iOS, and doesn’t allow users on popular apps to migrate to Android and maintain their login. (Note no Android SDK is provided)

It might technically not be antitrust, but as an app developer we’re now forced to include Apple sign-in.

Give us a try, mixcloud.com