Some of the best songs are cover songs of popular music from earlier eras.
If you're a musician who wants to create a cover song and actually sell it,
you'll be diving deep into the complex agreements and legal arrangements with record labels.
Sounds like no fun to me.
But this is where Python comes to the rescue.
The people over at Louder are using Python to run a service for creating, selling, and distributing cover songs.
This week you will meet one of the co-founders, Josh Welchel.
He's here to tell us all the cool ways Python makes this possible, including a touch of machine learning.
This is Talk Python to Me, episode 70, recorded July 29, 2016.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm.
And follow the show on Twitter via at Talk Python.
This episode has been brought to you by Rollbar and SnapCI.
Hey, everyone.
Quick follow-up from last week's episode about writing a programming blog with a.
Jesse Jiru-Davis.
Several people went to the show page and commented saying that this episode tipped them into deciding to finally create a programming blog and start contributing more to the community.
I thought that was really awesome.
So good luck to everyone who created a blog as a result of that episode.
And I appreciate you adding your comments there.
And thank you to Jesse for inspiring everyone.
If you want to add a comment to any of the episodes, just go to the episode page.
The one for the blog was talkpython.fm/episode slash show slash 69.
Now let's do a quick update on the Kickstarter.
The Python for Entrepreneurs Kickstarter is into its second week.
You're probably not surprised that it's already funded and everyone seems pretty excited about it.
In fact, I want to say thank you to everyone who backed it or who is still considering backing it.
The campaign was fully funded in just an hour and 15 minutes.
That's pretty awesome.
And it's a good sign that I think Matt McKay and I are on to doing something cool for the community.
I really, truly appreciate all of you who are contributing to it and helping me bring this course to life.
So I want to say thank you so much.
You can learn more about the Kickstarter campaign in the course at talkpython.fm/launch.
Now let's talk about the intersection of music and Python with Josh.
Josh, welcome to the show.
Hi, thanks for having me.
Oh, yeah.
It's going to be really cool to talk about music.
We've talked about all sorts of different things in the show.
A lot of programming.
We've talked about particle gliders.
We've talked about font design, but we've never talked about music.
So I'm really excited to have you here.
It's going to be fun.
Really excited to get into this conversation.
There are very few opportunities to talk about music and programming together in the same interest group.
So this is going to be fun.
Yeah, it's going to be awesome.
But before we get to the story of Louder and what you guys are up to at the company, let's just talk about you.
How you got into programming?
How do you get into Python?
Like, what's your story?
Sure thing.
So I was one of these kids who was – I grew up on Doom, right?
Basically on video games.
And I think the first big memorable experience I have getting into programming was as a kid.
I had come across on the internet, the very early internet for that, a little program that let you make random levels for Doom.
And I have been doing that anyway.
I think I actually learned most.
So you were making your own Doom wads.
Is that right?
Yeah, Doom wads for sure.
There you go.
I think that's how I learned math.
I was actually tweeting at Graham Devine and Louder had a conversation where I went to like class in the fifth grade and I knew the word vertices and I corrected the teacher when she said vertexes.
And that was my first moment when I knew I was doomed to be a nerd for the rest of my life.
That's right.
But yeah, so there was a random level generator written in C. It was called Slige.
I might have been actually Lige or something with the D at the time.
But yeah, so I just wanted to learn what the ins and outs of that was.
And so I got into programming pretty quick.
Programming the Doom wads, I never actually did it.
I just sort of consumed it.
I think my favorite was like a Simpsons one or something silly like this.
Oh, yeah.
But those were not actual.
They weren't done in Python, were they?
No, no.
And I think that might have been before Python's popularity too.
But yeah, I think you're right.
I think it was just barely came out at the time, right?
Okay.
Yeah, absolutely.
Yeah, it was very early.
So Python for me really started, you know, as I got older, I'll say older, but I was still
very young.
As I got older, I did some contract work for a company called Click Team, who was making
a product called Multimedia Fusion.
And the idea, if anybody really remembers, it'd be called Click and Play in its earliest
days.
It was a sort of a grid-based, conditional event, action-based system for programming interactive
experiences.
And most of the time, those would be games.
That's cool.
A little like Flash type stuff?
Kind of like Flash, but it would actually make binary executables, right?
So these are standalone, you know, deliverables, which is really awesome.
Like Blender, maybe?
Is that closer or a better guess is Blender?
Sorry, Blender?
Yeah.
No, Blender is definitely more focused.
It has a bit of scripting.
Click Team didn't really get into scripting too much, which is what opened the window of
opportunity for me, actually.
They had an extension system where you could basically program an extension that would get
packaged with the game as a dynamic library.
So that was really cool.
I learned a lot about programming fundamentals and the low-level stuff from that experience.
But I basically built the library that you would use if you wanted to play a module or
like an impulse tracker file.
So that's like very Amiga, very DOS kind of music.
You know what I mean?
Right.
Of course.
That's awesome.
So you basically made it possible to plug in like soundtracks into the games.
Yeah.
And the neat thing about these soundtracks is, you know, you had MIDI and MIDI was already
built in.
And, you know, MIDI is different on everyone's operating system, basically, especially at the
time because the sound fonts would be different.
And there was a real desire to have sample-based music.
If there are any big video game nerds, I think the one moment in video game music history
where you could tell the difference between a sample and MIDI was in Final Fantasy VII at the
end, there's a choir that comes in and it's mixing MIDI data with waveform audio.
So modules very much can achieve that because it's all sample-based.
Basically, you would have like, let's say I wanted to have a violin that's plucking a string,
a pizzicato.
You would just record like a C4 on that.
And then the programming would basically stretch the frequency by using just sample playback rates
and manipulation around that kind of idea to create music.
And, you know, that's basically how most sample-based synthesizers worked.
And still work today.
So it was really cool to get into the low level of that, too.
That's cool.
And it sounds like the timing when you got into this was really good.
Like, there's a real magical, the whole, you know, everything is open and can be invented at this time, right?
Oh, my gosh.
Yeah.
I mean, it was such a magical time.
There was just so much fruit.
I remember one of the things that I learned during that time, I was also really interested in how, you know,
different video game consoles were doing music as well.
And it came to my attention that there was a format called PSF that was taking PlayStation soundtracks and squishing them.
And I came to realize that the library code and the sample code for some of the most iconic soundtracks I listened to growing up fit into like a two megabyte window of data.
And I was like, oh, my gosh, how does this work?
I still don't know how some of that works.
And I actually got to do an interview with the Final Fantasy Tactics composers where I pointed that out.
And they were like, how did you know that?
Nobody knows that.
That was a lot of fun.
That was something we did with Louder in the very early days.
Oh, wow.
That's really cool.
Yeah, I feel like people who programmed back then, I don't know, I wouldn't necessarily say they had a different skill, but they certainly focused on different things.
And it just, it was so different than today, isn't it?
So.
Absolutely.
I mean, the demo scene basically is kind of the icon of that ideal, right?
Like there were people that just wanted to make things because they could make things.
And something that is really ripe in creativity, too, is working within limitations.
And because we had so many limitations back, you know, in DOS and Windows, early Windows, it was just really fun.
You had to figure out like, okay, well, we can't just pump bandwidth, right?
We can't have people download 500 megabytes just for the music.
So how do you make really good music fit into a much smaller space?
Well, there's lots of creative ways to do it.
And that's what I was exploring at the time.
Okay, that's awesome.
So let's jump up to today.
Let's talk about Louder.
So L-O-U-D-R.
Louder.
Yeah, Louder without the E.
And without the E.
If you want to check it out, it's at louder.fm.
So I think this is a pretty cool idea.
But why don't you tell everyone what Louder is for a start?
Sure thing.
So Louder is, well, primarily in the public side, I guess, Louder is a distribution platform where artists can come on.
And similar to like DistroKid and CD Baby and that sort of thing, this is a tool you'd use if you wanted to get your music on iTunes or Spotify, that sort of place.
The thing with Louder, though, that's distinctly different is that we do cover song licensing.
So as an artist, when you want to do a cover song, you have to get a license.
You have to deliver something in the mail.
And then even worse, you have to do monthly tracking of your sales and send checks to publishers whom you use their rights with.
Right.
So Louder takes all this whole process and built a platform around it.
This was something that the team was doing prior to, quote unquote, Louder as acapella records or Joypad records.
We did it specifically for acapella artists on iTunes when nobody else was.
And we did it specifically for the video game music cover crowd, which is very niche at the time, but it's definitely grown into a very big thing now.
And we took that model and said, you know what, we need to make this an open platform where people can come on and just put cover songs online.
And so if I were to cover a song right now, I would do it on Louder.
I don't have to pay anything up front.
And all the royalties for the publishers and the rights holders actually come out when the sales come in.
So I'm not actually paying out of pocket to do any of this process, which was really neat.
And when we launched Louder, that was that was not a thing that existed at the time.
Yeah.
So prior to this, was it pretty hard if you wanted to cover a song like one of the songs I really like that is a cover song is the the Boys of Summer, the Don Henley song, but covered by Taurus.
So it's got like this punk rock theme.
Oh, yeah.
To it.
That's a cool song.
Those guys, you know, they don't own Boys of Summer.
Right.
Don Henley does.
Correct.
So that's hard.
Right.
That's not so easy for people to do.
Right.
No, it's not trivial.
And it's not trivial because there's a legal aspect.
There's the actual execution, which, you know, has details and they're not fun details.
And then there's, you know, you've got to be on top of this process every month, which is a chore.
Right.
So, you know, it's something that people would do.
And you would typically see cover songs when done legally.
That is, of course, you typically see cover songs be coming out by people who are represented by labels who knew how to execute licenses very well.
And it would be really common to see labels, you know, do covers within their own catalogs.
Right.
There's a bit of a misnomer in that statement in that the labels who do the sound recordings and the publishers who actually write the songs and represent the lyrics and the musical notes, if you will, are actually different entities.
That's a conversation for another time, I think, because you get really down the rabbit hole there.
But that just, I think, demonstrates pretty succinctly how difficult this problem can be.
Yeah, I can imagine.
So, I don't have any musical skills.
So, this is not a problem that I suffer from.
But if I wanted to cover some song, I come and I create an account with you.
And what do I do?
I just, like, flat out record it?
Or do I have to, like, get you guys to work with the original artists?
Or, you know, maybe it's not even the artists, right?
Maybe it's the label that actually...
Yeah, you're close.
Which makes it way worse, I'm sure.
Yeah, it's the publisher, right?
So, you basically come on, you would have already probably recorded your album or your single, right?
So, you're coming to us to execute the distribution aspect as well as the licensing for a product you hopefully already created before you sign up.
But it doesn't really matter.
And you can do originals, too.
That's also not a big deal.
But the way you would do it on Louder is you just sign up with your free account.
You would submit your album once you've gotten cleared.
Because it's a free platform, we have, like, some upfront tax stuff we've got to figure out just because it's receiving a lot of money.
And the overhead of doing this for free was a thing that we had to deal with.
And that was our solution.
Once you've done that, you just upload your album.
You send us the metadata.
You let us know what songs you've covered.
And we take care of the rest.
Fortunately, it's not a very long process because in most cases, there's not really a negotiation aspect anymore like there used to be.
There is a lovely little section of copyright law that allows us to send what's called a compulsory license.
Meaning that as long as the song you're covering has been released in the United States on either, like, a specific digital phono record or a physical one.
Meaning, specifically, it has to not be something that's in the background of a video.
It had to actually come out as its own product, right?
Then we can cover it.
Oh, wow.
I had no idea.
That's pretty interesting.
Okay.
So that definitely takes it, the legal part, the human involved part out of it.
That's cool.
Absolutely.
The rest of it sounds like it involves a lot of software.
And let's dig into the Python stuff.
But before we do, you told me right before we hit record on this episode that Lauter has its team sort of scattered about some origins in San Francisco.
But that recently you guys transitioned to being a fully distributed team, whereas that was not the case before.
Can you give me a little bit?
What's the story like that?
How's that working out for you?
It's actually worked out really well.
So in the office, you know, we were a bunch of young guys and some talented, just talented everybody on the team, really.
The things that we're suffering from in a small space, looking at just when we have focused conversations, do we have a conference room for that or can we do that on the floor?
And what's the consequence if the operations team is getting into a big conversation while the engineers are focusing?
These are all problems that are great, but it seemed that we were losing the ability to really hone in on specific problems, you know, just because of all the things happening at once.
And I think this is something that happens with a lot of startups specifically.
But for a startup tackling such an immense problem like the one I just described to you, and again, I've really only scratched the tip of this, right?
You know, it wasn't becoming of us to constantly interrupt one another to try to figure out, you know, how are we going to solve this next problem, which is immediate?
And, you know, this also has to do with solving legal problems, right?
You know, every legal problem is an immediate problem.
It's not necessarily something you can defer.
And if you can't defer your problems, how can you take the time you need to solve them?
Well, all that said, we wanted to keep the small space.
We love it.
The operations team and the business team is still in San Francisco, and they are thriving, doing so much great work there now.
And the engineers are really benefiting.
The funny thing about it, and, you know, since I think Slack came out particularly, a lot of the stuff that engineers typically do today is already really remote compatible, right?
Like, so I'm not going to get on the whiteboard and copy paste my code onto a physical medium, right?
I'm going to send it over Slack, or I'm going to get in a code collaboration tool of some sort to actually get in there and collaborate, you know, on a computer screen over the Internet, right?
So if I'm already doing that big part of it, the next big step was to figure out, okay, well, how do we manage our tasks?
How do we stay in sync?
And how do we ideate?
Well, we were already doing that online, too.
We use Asana for task management.
We were doing that when we were in the office, sort of like Trello as well, you know.
Whiteboarding stuff we were already doing and a few tools that were available online, you know, kind of switching around.
But my node was really succeeding for us.
I have crappy handwriting, so I love to do things when I can just type it out and really get things out fast.
And then I think with tools like Screen Hero, where we can share a screen and actually do cooperative coding, we were already the remote team just in the same rooms.
So it worked out really nicely.
It was a super smooth transition.
The time zone thing, I think, is the biggest challenge.
So what happened is we were all in San Francisco, and then due to some family things with a few of our employees that kind of happened at the same time a bit synchronistically, we just said, you know what, this is an opportunity.
Give this a try and see if it works.
We did a trial period.
We found that we were super productive as a result of going remote, and we've stuck with it.
That's a great story.
And I'll definitely have to get links to those tools that you're talking about because…
Oh, absolutely.
Yeah, especially the collaborative, the Screen Hero one.
That sounds cool.
I've done a lot of Skype and various other ones, but I haven't tried that one.
Oh, yeah.
We love Screen Hero.
I think Slack actually bought Screen Hero, so it should be integrated any day now, to be honest, because they bought them a while ago.
If you're in Slack, if you've used it before, the call function was actually built by the…
It was either Screen Hero or Speak.
Actually, I could totally be making facts up.
I should double-check.
We used a tool called Speak as well before, and we didn't need to use it anymore.
Okay.
Yeah, that sounds really cool.
And I totally agree with you.
For some reason, I guess it makes a lot of sense, but we do seem to, as developers, already use tools that are extremely compatible with being distributed or asynchronous work.
You know, GitHub pull requests, for example.
Absolutely.
All these things.
So, I think it makes a lot of sense.
I've spent the last 10 years, let me do a quick math, yeah, 10 years, working either remotely undistributed teams or, you know, this last year I've been doing my own solo thing.
But I've lived that life, and it is really nice.
I definitely feel more productive.
The time zones are painful.
Like, I'm spending this year in Germany, so I end up…
Yeah, it's great.
But the problem is, like, I've got a lot of meetings in California.
So, it's like, hey, Michael, can you meet at 11?
PM on a Friday night?
It's like, you know, I didn't want to see my wife anyway, right?
Right.
So, you know, it depends how far it goes.
But within the U.S., within a few hours, it's pretty nice.
The time zones almost work for you, right?
You get, like, that dead zone where you can actually get stuff done.
Absolutely.
And it's funny you say that you're in Germany.
We've actually got contractors in Berlin right now.
And I think that's kind of nice about me being in the East Coast is that I'm right there smack in the middle of the West Coast.
And then our contractors who are in Germany and then the team that we have in the West Coast, it's really easy for me.
To kind of get the sink from them at the end of their day.
And at the beginning of the West Coast day, just kind of give them a brain dump on what's going on.
And that's worked pretty nicely.
You know, the other thing, too, you mentioned you've been happier.
I think that's something we've definitely felt.
You know, when you're able to live where you need to live, you know, there's definite advantages.
And speaking as somebody who's just recently moved away from the Bay Area, I'll tell you the amount of money that we're saving just on the cost of living is it was like getting a huge raise.
Right.
But no actual money needed to be spent by the team to achieve that outside of the I think we've had some frustration just setting up Ohio taxes and stuff.
But that kind of that kind of HR stuff's got to happen, you know.
Yeah, sure.
Yeah, that's really cool.
This portion of Talk Python to Me has been brought to you by Rollbar.
One of the frustrating things about being a developer is dealing with errors.
Ah, relying on users to report errors, digging through log files, trying to debug issues, or a million alerts just flooding your inbox and ruining your day.
With Rollbar's full stack error monitoring, you'll get the context, insights, and control that you need to find and fix bugs faster.
It's easy to install.
You can start tracking production errors and deployments in eight minutes or even less.
Rollbar works with all the major languages and frameworks, including the Python one, such as Django, Flask, Pyramid, as well as Ruby, JavaScript, Node, iOS, and Android.
You could integrate Rollbar into your existing workflow, send error alerts to Slack or HipChat, or even automatically create issues in Jira,
Pivotal Tracker, and a whole bunch more.
Rollbar has put together a special offer for Talk Python to Me listeners.
Visit rollbar.com slash Talk Python to Me, sign up, and get the bootstrap plan free for 90 days.
That's 300,000 errors tracked all for free.
But hey, just between you and me, I really hope you don't encounter that many errors.
Love to buy developers at awesome companies like Heroku, Twilio, Kayak, Instacart, Zendesk, Twitch, and more.
Give Rollbar a try today.
Go to rollbar.com slash Talk Python to Me.
Let's talk about Python.
Right?
So Python, you said, is pretty central to what you guys are doing.
How's it involved?
Yeah.
Sort of describe your architecture.
What pieces, what moving parts are in there and how does Python fit into it?
Oh, absolutely.
Okay.
So just I think to set the scene, right?
So Louder is built on Google App Engine, which is on Google's cloud platform.
And we've been on App Engine pretty much in one way or another since its inception.
I started out, actually, the way I met the Louder team before I was working for them or with them, rather, to make Louder, was on a product called the Game Music Bundle, where I needed to build a store really quickly.
And the way to do that, I found, was to build it on this new thing called App Engine.
And it was a total, you know, it wasn't really a risk because I don't think that failure would have been that big of a deal for something that was new like this and just something I built in my free time with some friends.
But to have it succeed in the way it did was really a proof that, like, okay, you can develop fast, you can iterate quickly, you can deploy quickly, and you can scale massively.
And that was like, holy crap, this is really cool.
So I became immensely fond with App Engine at that time.
And I brought that into the Louder experience.
What year was that?
I want to say 2012, maybe even 2011.
Okay, yeah.
So that's pretty fresh.
Like, App Engine probably still had that new cloud smell, right?
Oh, yeah.
It had the new cloud smell.
It had the undocumented appeal.
The whole thing was there, right?
Exactly.
Yeah, definitely.
No, it was diving deep.
It's cool.
And Python was one of the two first available languages, or was it the first available language?
I wouldn't know App Engine's history well enough to know.
I know that as far as what's on their managed platform, your look, or managed runtimes, I guess you'd call these, you've got Python, Java, and Go.
Go wasn't even around at the time, for sure.
Right, and Java came later, so I think it was Python.
Okay.
I'd say it's probably Python, because Java, I don't recall being an option.
I knew Java, and I probably would have started with Java, to be honest.
Very glad I didn't.
Yeah, for sure.
So App Engine is really good at getting you started.
I haven't done much work on it.
I did check it out for a few projects.
It seems like you can run real legitimate stuff there, at least back in the time frame that you're talking about, for almost free, whereas the other hosting options in that time frame were way more expensive, right?
Yeah.
The nice thing, too, about Google is that they've been really aggressive on keeping up with pricing.
And I think a few years ago, I was at the conference that they had.
And they were cutting their data storage costs.
I don't know what happened at one point, but they completely undercut Amazon in a big way, and Amazon responded to it.
So it was really nice to kind of be on the front edge of those pricing changes.
And data was really cheap.
And the nice thing, and just kind of bring it back to Python here, when you're using App Engine, is you can just open up – this is not a good Python practice, by the way – but you could just open up one file, right?
Stick your basic handlers in there, put your data schema in there in the form of a Python class, and integrate it with one of their API frameworks, which is just really beautifully written.
I think Guido actually is the guy who wrote the NDB API in Python for them.
So whenever I work with it, I've always got this tingle of magic, because it's basically doing future management with generators.
And sorry, I could go on a complete tangent about this.
That's really cool, yeah.
Yeah, so I really love it.
And there's definitely some grace to how it was designed.
And then all the APIs that they have available, like you've got a built-in data store.
You've got, obviously, the actual platform itself.
They've gotten to the point with Cloud Platform now where you've got a container engine via Kubernetes and Docker, right?
You've got managed VMs, which is the auto-scaling, just computer instance sort of thing.
So, man, there's a lot of stuff in Google.
And I think people come and they look at Amazon, and they think that's the de facto.
But in reality, you've got a really aggressively smart platform with Google.
And then also when you consider the things that Google's doing with, like, data flow and machine learning.
And we all know where Google is with machine learning, right?
So, like, to have them expose those tools as really smart frameworks and APIs is really exciting as well.
And it's always been really fun to work with that kind of technology.
Yeah, I'm sure it was.
So, back then, that sounds like you were probably working with a platform as a service, not infrastructure as a service.
But...
Yes.
Yeah, because that came along later.
Good buzzwords.
Yeah, of course.
So, one of the things that I think is really cool, and you talked about how cool it was, is that there's all these APIs you can use.
But it also feels like if you write your code for the Google App Engine, it's kind of like it's there, right?
Because you can't extract it and, like, say, move it to AWS or to a VM, right?
Sure.
Yeah.
And that's one of those things when you're looking at it and you're thinking, okay, well, we need some data liberation.
How are we going to deal if Google one day is like, this is not a priority.
This is a waste of our assets.
We need to just cut App Engine, right?
Fortunately, and this is really awesome.
I don't remember when this came about, but there was a complete initiative of a team of people who was dedicated to making sure that all of the core APIs and frameworks for App Engine were available on an open source stack.
And so I don't actually have the name of it, but I'll definitely try to find it and send it your way.
But there is a way that I could take the whole code base and pull it off App Engine proper and actually run it on something like AWS if I wanted to.
Oh, wow.
Now, I think there's certain APIs that we'd be challenged with changing.
Fortunately, kind of internally at Loudr, we do – when it doesn't make sense to use one of their crazy cool frameworks, we are, for example, using Elasticsearch.
We could use BigQuery or something as well.
But there has been an emphasis on making sure that if the day comes that Google's like, screw you guys, we're going home, that we're not going to be left in the dirt.
Yeah, we're taking a ball and we're going home.
Yeah, I don't see that happening.
I mean, this whole cloud computing thing is really – it seems to have some actual legs.
Like I just read, I think it was today, that Amazon's profits – not revenue – profits jumped 800%.
Oh, I'm sure.
And the majority of that was from AWS, right?
Oh, yeah, absolutely.
It wasn't doing better with books or, you know, things like this.
So very cool.
I think Google App Engine will definitely stick around.
So maybe tell us about some of like – what does your architecture look like?
What are the pieces?
What kinds of things do you guys need to do in there?
Sure.
So we very much have that microservice mentality, right?
We're building very segmented APIs to solve specific problems.
I think one of the cornerstones of the Louder framework is built on this concept of a task queue.
It's literally called Task Queue in Google, but that would be like Cassandra.
But, you know, you can implement task queues in several ways, of course.
But Google's got this nice task queue concept.
And so we're building a lot of things, you know.
So I guess our problem space we like to divide into three ideas or three core problems.
And those problems are matching, fulfillment, and administration.
I kind of talked to you about how you could come to Louder and you could say,
okay, I'm going to cover Boys of Summer, right?
It's our job to match your sound recording and the information you provide to us
with the actual composition and know who the publishers are attached to that.
So we're getting lots of ingestion from rights holders.
Lots of data feeds are involved.
So, you know, there's queues there, right?
There's indexing problems so that we can search and find things quickly.
That's good for elastic search, right?
There's a lot of machine learning involved because we have to do this at scale.
It's not just, you know, one or two people coming to get licenses.
We have an enterprise service where we're doing this for big businesses like DistroKid, for example,
which requires us to be able to, you know, we can't just have humans churn at everything.
So there's that aspect of it as well.
And I, you know, and I think the way we look at it, we kind of take those core problems and we segment our code into microservices that represent them.
Then, of course, you've got the shared microservices for things like the user management.
And, you know, we can go into complete tangents about this as well.
But I think it gives you an idea of how we work and what we think about.
We also have a big emphasis on, you know, not reinventing the wheel.
So we like to utilize and contribute back to open source projects.
Google's worked on something called a pipeline library for App Engine, specifically in Python,
that we've given a lot of contributions to just because we so heavily rely on it.
We've also been working with one of our really talented contractors helped us build an open source framework for an API in Python called Pail.
And I really, really like the work that we've done there simply because it's the most Pythonic way to do a RESTful API that I've seen yet.
The built-in documentation built into, like, the way you manage arguments on the API level is just something that's really fluent.
And I'll share a link to that with you at the end of this call just so you can kind of get that out.
Yeah, awesome.
Yeah, I'll definitely put that in the show notes.
It sounds really cool.
So if I'm writing a web app on Google App Engine, do they have their own framework or is it like Flask or what's the web actual API?
Yeah, so you've got a few choices.
Web App 2 is what we use.
So you're using that framework and they're kind of just built on top of it.
You've also got Flask available.
And then, you know, when you're on App Engine, you do have the choice between the managed platform, the managed runtimes, I think they're formally called.
And what's called a managed VM, which is just a computer.
It's just basically like an EC2 instance, a virtual instance, right?
And you could do whatever you want on a virtual instance.
On the App Engine runtime that's managed that we use for a lot of our code, you've got a really tight integration with the data store, super low latency.
You've got access to all those.
I think I mentioned the NDB API where you could use generators to manage futures.
That kind of writing is really Pythonic and it's helping us write really efficient code really quickly.
You know, I think the problem of dealing with lots of data, too, and all the complicated sort of business stuff we have to do,
it is really behooving to have a situation and a platform already built for us where we can say, OK, go fetch this entity.
And while you're doing that communication, get this work done.
And then this work is done.
OK, now maybe that response is ready and we'll block when we need to.
And to write in tasklets where you're just yielding futures, the way that the runtime and the loop works in there, it feels a little bit like black magic.
But you can actually just go look at it.
I'm fairly confident that I know this is true because I look at it all the time.
The NDB framework itself is also just out in the open.
You can go look at the code for it.
So it's just nice to be in that kind of space, right, where you've got the Google level engineers who have built a platform, you know, that is highly technical.
And like I mentioned, Guido being involved, like it's just out of this world.
Obviously, he's a Dropbox now and another really fun thing to do.
But I think I think you get the gist here.
Like it's it's great for as far as I'm concerned, like being on a platform as a service allows me to not worry, especially as a CTO on like the sort of operations problems like, oh, is this instance screwed up for this reason?
Oh, do I need to hop in a shell to fix this trivial problem?
Now, that's most of that stuff's already done for us.
So it's really allowed us to focus on the problems that we need to solve and be really efficient and making sure that we're not spending our time doing work that really probably shouldn't be doing.
Right.
Yeah, yeah, that's awesome.
Yeah.
I mean, would you ever consider having like a data center in your own at your own company again?
I don't know.
Maybe it's pretty hard.
It's pretty far fetched, though.
I don't know.
Well, I think usually what I would say that ever makes an engineer frown is business reasons.
There would be reasons to have data centers like fortunately, you know, we've got Google's level encryption.
So we've got confidence that they can't read certain things that we've got on there.
And, you know, whenever we have anything super sensitive, we're using public key encryption on the server so that that private key is only in the hands of developers.
Like people even get access to the data couldn't possibly read what's in there for a lot of the really sensitive stuff.
So with those kind of technologies really blossoming, especially lately in encryption, like I don't feel that there's too many cons on the cloud.
Right.
Like I should put a caveat on there saying technical reason.
Oh, right.
Yeah.
No, you probably should have.
No, I can't see much technical reason.
Cost might be one.
But like you've got the pro and the con.
You've got to balance.
Right.
Like what happens if your business blows up overnight and you haven't, you know, taken the time to build up your data center, put the resources in, have those guys build that sort of thing.
You know, it's like, what's the point?
I think that nowadays if you're going to start a new project, what you should do, you shouldn't do anything.
But what might work for you is to build it on the cloud first and then figure out if you have a need to go to a data center unless you've got a very specific reason going and why you don't want to be on the cloud.
Right.
And then, you know, thinking about what if Facebook was built today, right?
Like Facebook is, I've recently seen a lot of advertisement targeted at me because I'm a developer, I guess, about how they've got this awesome data center and the brightest minds are working on the Facebook product at that level.
And, you know, that's really exciting and really cool.
But honestly, would they have done that in this environment today?
I'm not entirely so sure.
Yeah, I agree.
Although it is interesting, you mentioned Guido and Dropbox.
I doubt Guido has anything to do with this, but they're moving out of AWS into their own data center.
But fascinating.
It's interesting, right?
But it's like that's a pretty long ways to grow before you grow in the cloud.
So, yeah, yeah.
Very cool.
Absolutely.
And, you know, on the flip side, you've got a company like Spotify who just went on to Google Cloud.
Right.
So they're moving off their data centers and go in the opposite direction.
Yeah.
It's an exciting time to watch all these things happen.
So you mentioned machine learning.
What's the story there?
Is that like scikit-learn and what problems are you actually solving?
Yeah, totally.
So like I mentioned, a big aspect of what we do is matching content to content, right?
So we've got metadata.
This is kind of one of the funny problems in the music industry that I'll quickly set up the scene for you.
I did mention earlier how publishers, the entities who represent the rights holders of the music itself, the notes and the lyrics, the guys who are, you know, actually doing the notation, that sort of thing, are separate from the labels who represent the artists, the songwriter.
Or not the songwriter, but the sound recordings, right?
The band, the killers might be this group of guys.
And then the actual people who wrote their songs are represented by a publishing team that have a different set of tasks.
If you ever go to Hallmark and you buy a card that has like the Beatles lyrics on it, you bet your bum that Hallmark has to pay the publisher that owns the represents the Beatles.
Right.
And I'm not sure that that's Apple Records because Apple Records is the label side.
So when you've got this segregation between the publishing data and the label data, one of the fun things that happens is the publishers don't always know who is using their music.
And when they send out the song information to their partners, they're not always including like, OK, here's the song.
Happy birthday.
It was written by these people.
Right.
They know who it was written by, but they don't know who necessarily recorded it.
And you can imagine, especially in that example, a lot of people have recorded happy birthday to you.
Right.
And then, you know, the labels on the other side will send content distributors and they won't include the publishing data because they don't necessarily know it either.
It's not it's not a connected chain.
So when you're looking at two sets of metadata and you need to start drawing lines between them, you start thinking, OK, I can either throw rocks at this or I can have a statistical method for solving that problem.
And I think as everyone who's listening knows, Python really excels at these machine learning problems.
There's lots of frameworks and lots of libraries and lots of tools that come to mind very quickly when thinking about machine learning in Python.
What's nice is, you know, we've internally built this really abstract framework for doing machine learning based problems in terms of how it integrates with the ES level and with the platform level.
Right.
So we're able to quickly look at two different models of information and do some really cool things on the learning side, you know, with exporting training data, with setting a model, with changing features, that sort of thing.
So I think Python really paid off there.
Awesome.
And that's like it learn or is it different?
It's your thing.
It's it's a bit of an internal thing.
And then honestly, I'm not the guy who does the low level machine learning stuff to know what tools he's really using.
But I do I do oversee the integration on the platform side.
And that's where it's been really fun.
So machine learning has been a very big learning process for me going into this.
And right now, I think you're going to ask me about hiring later.
But we've been looking for people who are really talented in that space.
And we've actually brought on really recently some great engineers in that space.
And it's like, oh, my gosh, the things you can do.
It's really quite fascinating.
Yeah.
This episode is brought to you by SnapCI, the only hosted cloud based continuous integration and delivery solution that offers multi stage pipelines as a built in feature.
SnapCI is built to follow best practices like automated builds, testing before integration and provides high visibility into who's doing what.
Just connect Snap to your GitHub repo and it automatically builds the first pipeline for you.
It's simple enough for those who are new to continuous integration, yet powerful enough to run dozens of parallel pipelines.
More reliable and frequent releases.
That's Snap.
For a free, no obligation, 30 day trial, just go to snap.ci slash talk python.
I don't know a ton about machine learning.
I know a little bit about sort of neural networks and those kinds of things.
But do you think that we're going to get to a future where we have software that does things and we don't know why?
We cannot know why?
Oh, boy.
Yeah.
Let's go down the rabbit hole.
So that is a great question.
And you think about neural networks and you think about, you know, throwing rocks.
I think that we've got the limiting factor with Moore's law a little bit on that.
However, as we get into quantum computing, right, that's when things get pretty interesting.
And I think machine learning is just kind of inept into that.
Like, if you're combining machine learning and quantum computing, I think you can start to scratch the surface on questions that are as far fetched as, you know, what is consciousness?
Can we really even quantify that anymore when you've got a machine making decisions?
And it might identify the need to change some of its internal programming.
You know, like if a machine learned quantum computer can train itself to iterate upon itself, what happens next, right?
Yeah, it gets pretty crazy.
I mean, even before it like, you know, it goes that far.
Like, if you're trying to just debug something or you're trying to manage like complex machine learning in like production, right?
Like, it might start making decisions and you're like, I don't really know why it's doing that, right?
But maybe it should or maybe it shouldn't.
Yeah, so I mean, like, we have that.
We already have that today, right?
Like, so we have a trained model, right?
And we might see that it's doing something a little fishy on certain results.
And we might want to dive into it.
Well, it's not necessarily just like look at it and go, oh, well, because the code path is this and if this than that, it's really easy to see that.
Well, actually, it's not anymore because you've got a statistical model you're basing it on.
You've got to look how different features impact one another.
You have to look how combinations of features, you know, work together.
If this feature is scored highly and this other feature starts to go down, does the confidence go up or does it go down?
Like, none of it is necessarily intuitive anymore and it's all numbers.
So the next step from that is exactly what you're saying where you're going, well, what about when the machine starts to do things that we can't even debug?
And I think that's where you're looking at, you know, internal code patching where a program can look and understand its own code base enough that it can change it in such a way that it starts to only work in a statistical way, right?
So it trains itself based on a conditional pattern and then you feed it correct and incorrect results and it starts to learn, you know, this model makes more sense than that model.
And then at some point it gets so confident and so well trained and you've defined the features so precisely that it no longer has a conditional code path because everything that it does can be decided on a statistical model, right?
And that's just talking like the two-dimensional equivalent of machine learning, I think.
When you get into neural networks and you get into the sort of conditional-based machine learning, that's when it's going to – it's when it goes next level, right?
Yeah, and then you get like the forest, which are groups of – I mean, it just gets really interesting.
You know, the part you started to touch on, if people are interested and they want to see a really great movie that like sort of explores that in a science fiction way, Ex Machina is a really good movie that –
I recently watched that and it really freaked me out.
Yeah, that's one of those things.
I think – I mean, just for the people who haven't, I think it's worth talking about a little bit.
You've got a situation where this machine has learned, you know, basically what it needs to survive and it's learned how to – spoiler alert, I guess.
It starts to learn how to interpret human emotion based on the output of the human response, right?
So like if it can look at a face and determine that this emotion is that and then it's got, let's say, the entire history of all the data in Google to train upon.
Let's just use that as a real-world example.
If you can actually build a physical medium for this thing to exist in, yeah, it's going to start to do some really interesting things.
And like you touched on, I think there's this point when it stops being conditional.
It stops being functionally programmed, right?
It's getting to the point where it's saying, is this working for me or is this not?
If not, try something new.
And I think that's – you've got some really talented people right now who have spoken out against AI.
And I just – this feels like the natural progression.
So just throw a rock at me if you want for going down this path.
But like when you've got the guys coming and saying AI is a bit scary, it's because in my opinion, if a computer is going to do that trial and error and trial can be somewhat random, who knows what that means and who knows how it quantifies success?
Because the motivations of a machine that doesn't necessarily have features, if you will, that are targeting emotional or human factors and responses, you're definitely getting a situation where that can be kind of scary.
And that movie is why that's scary.
That movie is the perfect quantification of the worst-case scenario for an artificial intelligence.
Yeah, it was – it's definitely worth checking out.
I recommend it.
But super interesting.
You know, of the people who spoke out about AI, a lot of them I was kind of like, well, you know, how much really do they know about software?
It's kind of like an amorphous concept.
But Elon Musk, like that's a guy who is actually creating the future.
So I definitely give his statements more credit.
Stephen Hawking too.
I mean you've got a lot of smart guys saying stuff like this.
I have to find this for you too.
But I found this talk by the guys who were working on the first quantum computers.
And for my sci-fi nerds, it's really fascinating.
They're big black boxes.
And he refers to them as black monoliths.
And I just eat that up, right?
Nice.
But he's talking and he literally talks about the way qubits work.
And he gets into this idea that, you know, it is kind of like you're pulling from – and this is going to go totally fringe.
But it's like pulling from two different universes, right, that are parallel.
But you've got a point where they converge and that point is the qubit.
And everything that comes beyond the qubit is sort of like the shadow of what happens.
And the way that these things work, he goes and talks about how, you know, the biggest challenge is how you keep all the chips at near absolute zero temperatures, which is a scientific feat in and of itself.
And the stuff that he says in this talk is just like the predictions he's making and his colleagues are making are that in 15 years, computers are going to be able to do anything humans are going to be able to do and much better because they can train and iterate themselves.
And, you know, we like to talk about it and joke that it's science fiction.
But science fiction is becoming reality.
It always has followed that trend.
We've completely diverged from music.
But, like, absolutely, it's one of these topics that is really fascinating.
I think quantum computing is something to keep your eye on, especially in the next five to ten years.
Yeah, I totally agree.
To me, honestly, quantum computing is scarier than AI.
Well, it is in its sense kind of like AI.
If you put them together, then you're...
Yeah.
You put them together, you get all sorts of trouble.
But even basic things like encryption, right?
Like, what happened if tomorrow we found out that all encryption was useless?
You know, what would that do to the economy, to jobs, to businesses?
Like yours that need privacy?
I think it would be really an immediate problem, I think.
It would be...
I think it would be an upheaval of current paradigms that we have in society.
But, you know, one thing that humans are really good at is adapting, right?
So, you know, let's say encryption goes out the window.
I think humans will very quickly become aware that, okay, there is a real need for transparency in the world, you know?
And we'll find a way to adapt.
And you want to look at an example where that's happened.
Bitcoin was the perfect prototype of, for example, a currency that was trying to solve so many problems by being transparent.
And I can tie this back to music because one of the things that's really trending in this industry that I'm in right now is the idea of having a blockchain for music royalties.
So whenever a usage is generating royalties, what they want to do is use a Bitcoin-like technology to attribute the stream or whatever is generating the money and transparently show who it's getting paid to.
That would attempt to solve this huge, huge problem of why aren't artists actually getting paid for their content?
Why aren't songwriters getting paid for their content?
Right now, though, and to go back to transparency, the problem is that a blockchain doesn't work unless the data it's attached to is transparent.
And right now, rights holders and other interested parties are not always privy to just saying, oh, this is all the music we own.
And this is how much to pay us because there is value in that data.
And they're able to make intelligent business investments and make some money by putting value to that information.
Yeah, that's a really cool idea, but I can definitely see the real-world challenges.
All right, so let's bring it back to Python just for a little bit.
So you talked about the machine learning.
You also talked about some other cool things.
You said this RESTful API that you guys open source called Pale was really cool.
Tell us a bit more about that.
Yeah, so Pale is nice.
And the reason I like Pale so much is we're writing things in such a way that let's just start from the beginning.
If I'm going to build a new API, and actually I'm doing this by making a website for my own music where you can come.
And I just wanted to have like Bandcamp music integrated into it so I could link everything to Spotify.
So the way that I did this was I just pulled down Pale, right?
And Pale you can implement with Flask or Web App 2.
And you just get off the ground writing a RESTful API in a very Pythonic way.
So you manage information that comes in responses in the form of resources.
And you define those very succinctly.
And they can nest really nicely.
So I can have a user resource that mentions a password resource if that was structured in a smart way.
And then you've got the concept of arguments that is going to handle casting.
So you've got a string argument.
You've got a Boolean argument.
And the way that – why this is so good is because you kind of remove serialization from how information is handled.
So you can have a JSON input, which is ideal in my mind.
But you could also have an XML input.
And what you're doing is you're doing a really nice kind of object-oriented solution of keeping the problem where it belongs.
So, like, I'm not going to try to struggle with a string argument problem outside of the string argument class, right?
And this is a trivial example of strings.
But when you get into structures, you know, like currency types or other structured types of information where you might have a need to do all sorts of fun stuff, like permissions is a great one.
So on Louder, for example, on our API, we have, let's just say, like an album resource.
And it represents an album on the store.
The thing is, when you are the owner of the album versus the public user looking at this album, you're not going to necessarily need to see the same fields.
And one of the challenges when building any new framework is how do I actually manage those permissions in an intelligent way where my code and my permissions logic isn't all over the place?
Pale provides a solution to that in that we've got this ongoing context.
And the context is passed every time any field or resource is going to be rendered.
And the context is going to carry all the things about the request, the HTTP request, all the arguments that come in that have already been deserialized to Python dictionaries.
And it allows you just to look from, let's say I'm coding the album resource and I need to say these are the fields I want to expose.
And I've already defined the fields at the class level.
So the album has like a track, number of tracks, which is an integer argument.
It's got the name, the string, all that stuff.
And all I have to necessarily do is say context.
Tell me who's accessing this.
Let me determine what the permissions model is.
And that itself can be abstracted, you know, however you want to when you implement.
And then it's the resource's responsibility to decide how it's going to render arguments.
So this makes things like expanding nested relationships really a lot more easy to tackle because you don't have to go into some really nasty conditions if you're thinking about just like how would you do this from scratch?
What would you do?
I think there's other cool API frameworks out there, but this is the first time that I've used one where I felt and I don't know if it's maybe my App Engine or Web App 2 kind of background to coming in where this context idea is so fruitful.
But having that context and having all your permissions and all these challenges, whatever you want to do, be passed at that level where the request is kind of contained like that, it just makes programming this whole problem really nice.
So, you know, I'm going back to my open source like website thing that I'm working on.
It's really easy for me to quickly build something.
I think in a day when I was using Pale, I was able to scrape Bandcamp, put all my albums into the API, have a situation where I could write a React front end and actually show the albums, have search for the albums, have album specific pages, have those streams play off Bandcamp and off Spotify literally within a day.
And that feels ridiculous to me for some reason because I guess when I got started doing this in 2012, 2011, whatever it was, it was not that fast.
Like, especially to do it.
It was like a three month project or something, right?
Right.
And to do it in a restful way to like that, especially I guess it was just at that time and there wasn't necessarily as large of a push for it.
But, you know, when Pales got this real big emphasis on being restful, which is the most intelligent way to do an HTTP API at this point, like it's just beautiful.
Like you get to specify endpoints as classes and you can determine, you know, this endpoint and this endpoint might share the same URL, but they have different methods.
And it's very, I mean, it's just straightforward.
That's really cool.
In addition to that.
Very nice.
You get to use, like to go back to this argument concept, I can have a URL argument and take advantage of web app twos like URI4, for example, and just dynamically determine what the URL should be for a canonical resource.
And that's Pale, like a lot about Pale in a small amount of time.
But yeah, I mean, that's why I'm excited about it.
Okay, cool.
Yeah, I hadn't heard of it.
So I'm definitely going to check it out.
That sounds awesome.
I like it.
Yeah.
There's one example app that's like included in the code base.
And I would like to solve that by having more examples.
I think I'm talking about this thing that I'm building.
It's not quite open source just because, you know, like when you start your project, you want to make sure it looks nice before you put it out and that it's usable for others.
But that'll actually be a good example of an App Engine Pale integration that people can throw up on their website very quickly.
I think it'll be, if all goes well, I think that the more technically inclined musicians that are trying to do some really interesting things with their websites might transition to.
That's the goal.
Yeah, that sounds very cool.
So one of the sort of hot topics right now, given that we're coming up on the end of life for Python 2 in 2020, is whether people are using Python 2 or are they using Python 3.
How about you guys?
Yeah, it's 2.7.
So these are things that we have to face.
App Engine's got Python 3 support as of relatively recently, I think.
Fortunately, in terms of how we've written code so far, I've done some early assessments of it.
I don't think it's going to be too problematic to port over.
It's just one of those things whenever you're doing like a big version change that it's like, oh my gosh, how are we going to gracefully transition?
Are we going to be able to do it in time?
Oh my gosh, what's the this and that?
And, you know, I think, you know, while Python says that they're going to stop 2020 is going to be the end of the lifespan,
I don't think that we're going to functionally see Python 2 die in the same way that Josh Welch will still play Doom on his computer and it's not the new Doom.
I think Python 2 is going to die like Windows XP is dying, which is to say that I go to plenty of places and they take my credit card and it interacts with a thing that has Windows XP on it.
It makes me nervous.
But they do it or, you know, I think the U.S. military, at least for a time, was paying Microsoft extra for support even when it became unsupportable.
You know, things like this.
Yeah, absolutely.
I don't know.
Am I going to do like...
I think that's how Python 2 is going to go.
I think I'm going to like pip install requests and then pip is going to be like, installing Python 3.
Suck it.
No, Kenneth, what are you doing?
Yeah, exactly.
How awesome.
All right.
So you talked a little bit about having a lot of cool opportunities for people and bringing on some new folks that were able to really like make the machine learning zing and how awesome that was.
Are you, you know, some of my most popular episodes are when I talk about people getting jobs or sort of what you can do with Python and so on.
And from sort of getting started.
Do you guys have open positions you're looking for Python people?
Yeah, so we actually just put out a call for a senior back-end engineer.
And if you've got machine learning experience, that's going to be absolutely a big plus.
The same goes for like natural language processing, that sort of thing.
My expectation is that we're going to see a blossoming of opportunities at Louder in the next, probably after a window of three to six months, somewhere in there.
Just simply looking at the growth in terms of the clients that are integrating with us at this point and our need to scale to the amount of clients that we'd like to.
There's definitely going to be some ripe opportunities, especially in machine learning.
Right now, we have some really talented Python contractors doing some really dedicated machine learning work.
And actually, if you've got the experience of machine learning and you are a contractor, particularly, and you want to get your hands wet or dirty or whatever,
in a practical example where Python and machine learning actually come into a business practice, then you should definitely give me a – don't call me.
Email me for sure.
That's awesome.
Yeah, so I'll put some – you can give me some link that we can use for them to –
Absolutely.
To get to test you in a proper way that is not waking you in the middle of the night.
Yeah, right.
Nice.
That's going to happen anyway, but –
Yeah, of course.
All right, so we're kind of getting near the end of the show.
And let me ask you a couple of questions I always ask my guests at the end.
We talked a little bit about some of the PyPI packages that you are using.
But, you know, there's 80,000 of them.
And there's always – you know, every – I know it blows my mind.
It might be quite a bit higher.
I need to look probably.
But there's so many that are amazing, like this Pale one that you told me about that people don't necessarily know about.
So – but you have a lot of exposure.
So is there one that you really like?
Is that Pale or is that another one?
I can't be – I can't say Pale because that would just be biased.
But –
Well, I'll nominate Pale for you and you can pick another one.
Yeah.
There's just so many Python packages.
It's like hard to choose.
Like I think you've probably gotten the answer requests probably a lot, I would think.
Yeah, yeah.
I don't want to be lame.
I'll make it music related.
There's one called Mutagen, which is great for handling metadata inside of an MP3 or WAV file.
That saved us a lot of time in terms of just being able to look at what's inside of files.
The trick that came with it, of course, is – and I think this might be why it's my favorite – is it required me to solve a problem.
It required me to iterate on it a little.
And I like that kind of interaction with anything I'm working with.
If I actually have to get my hands dirty to solve a problem it has, I'm going to have a better experience with it.
And I know that might sound strange considering a lot of people will just say, oh, yeah, put it in and it works.
But I find that when you get to actually modify and you're going to learn and understand what you're working with a lot better.
And Mutagen was one of those.
So one of the things that we had to solve was how to get Mutagen to look at the metadata or the ID3 tags, if you will, inside of a file object rather than inside of something that was just a file name or on the file system.
And it initially hadn't been written – it was actually written in a way where most of the architecture was working with an open file resource.
But for whatever reason, the API itself and the opening and all that stuff wasn't right there at the time.
And that's probably changed.
It hasn't been a few years since I had to do this.
But I really do enjoy using Mutagen because it's just like any time you can bring music into Python and solve some problem like that so that I don't have to call a command line or I don't have to get into the bytecode or do any frame decompression, yada, yada.
I'm going to really appreciate it.
And I think Mutagen is that for me.
Yeah, that's awesome.
Nice recommendation.
And then the other question is when you're writing Python code, what editor do you open up?
I am a Sublime guy.
I've been using a little bit more of Vim these days.
But for some reason, I still really like Sublime.
I like the Python packages.
And I haven't gotten into Atom really.
It's just Sublime all the way.
All right.
Yeah, that's definitely a popular one.
That's cool.
All right, Josh, any final call to action?
What should people do if they've got this music problem?
How do they get started working with you?
Yeah, I mean, so this would be fun.
I mean, if you want to build a website sort of a la SoundCloud or something, you know, and you want to do it and make sure you don't get your butt sued when you do it, you would want to talk to louder.
So if you're ever like streaming music on the Internet or you're ever distributing content or let's say that you're a small label.
Actually, I kind of like this example because we work with a few distributors and labels.
So like if you are looking to solve this problem that you have where you have artists or you are an artist yourself and you need to distribute cover songs or you need to secure mechanical license, you should definitely get a hold of us because we're solving ways that are solving this problem in a way that's very technical and scalable.
Which means that, you know, by the maturity of the business level of integration, you're going to have access to some really cool APIs to look at your data.
The stuff we're working on now is really exciting.
And I think it's going to bring the level of technical understanding in the music industry to the next degree.
I think the joke about the music industry and technology is it's about 10 years behind.
And that's because I think technology has typically screwed the music industry in some form or another.
You can have whatever opinion you want on it.
But I think I think there is some truth to that statement.
So I would say if you're if you're getting into being a label or especially if you're doing some cool integrations and you're, you know, maybe automating your distribution or something like that.
Are you like working with software like talk to us a louder like we'll help you solve this problem in a really cool fun way for you because it can be done in code.
And who doesn't like to solve all their problems in code?
I don't know.
Yeah.
Well, I think the people listening generally like to solve their problems in code.
So it definitely will be well received.
All right.
I hope so.
Yeah.
Josh, thanks for sharing your story.
This is really interesting what you guys are up to.
Absolutely.
Thanks so much.
I hope that we didn't go on too many crazy tensions.
It was a lot of fun.
Yeah, it was definitely fun.
Talk to you later.
Yeah.
Bye.
This has been another episode of Talk Python to Me.
Today's guest was Josh Welchel.
And this episode has been sponsored by Rollbar and SnapCI.
Thank you both for supporting the show.
Rollbar takes the pain out of errors.
They give you the context and insight you need to quickly locate and fix errors that might have gone unnoticed until your users complain, of course.
As Talk Python to Me listeners, track a ridiculous number of errors for free at rollbar.com slash Talk Python to Me.
SnapCI is modern.com slash Talk Python.com slash Talk Python.com slash Talk Python.com slash launch.
I'm so excited to be able to unveil my Python for entrepreneurs course that I told you about at the top of the show.
If you want to learn Python web development and launch.
Talk Python.com slash Talk Python.com slash Talk Python.com slash Talk Python.com slash launch.
I hope we can build something amazing together.
You can find the links from this episode at Talk Python.com slash Talk Python.com slash episodes slash show slash 70.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes.
Google Play feed at /play.
And direct RSS feed at /rss on Talk Python.com.
Our theme music is Developers, Developers, Developers by Corey Smith, who goes by Smix.
Corey just recently started selling his tracks on iTunes, so I recommend you check it out at talkpython.fm/music.
You can browse his tracks he has for sale on iTunes and listen to the full-length version of the theme song.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Smix, let's get out of here.
Stating with my voice.
There's no norm that I can feel within.
Haven't been sleeping.
I've been using lots of rest.
I'll pass the mic back to who rocked it best.
First, developers, developers, developers, developers, developers.
First, developers, developers, developers, developers, developers, developers, developers.
developers, developers, developers, developers.
.