#46: Python in Movies and Entertainment Transcript

00:00 What did you experience the last time you watched a movie in a theater?

00:03 Were you captivated by the fast-paced action and special effects?

00:06 Deeply moved by the characters that came to life during those two hours when the outside world just melted away?

00:12 Yeah, movies are still magical.

00:14 What was likely not top of mind was all the work that went into that movie,

00:18 from the editing of the audio and video, to the special effects, the rendering, the coordination,

00:23 and maybe hundreds of creative professionals.

00:25 It turns out that Python plays a key role in coordinating all of that production work,

00:29 and that's what this episode is all about.

00:31 Join me as I talk with Rob Blau from Autodesk about Python in the movies and entertainment business.

00:37 This is Talk Python to Me, episode number 46, recorded January 28, 2016.

00:43 I'm a developer in many senses of the word, because I make these applications, but I also use these verbs to make this music.

00:54 I construct it line by line, just like when I'm coding another software design.

00:58 In both cases, it's about design patterns.

01:02 Anyone can get the job done, it's the execution that matters.

01:05 I have many interests, sometimes...

01:07 Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities.

01:13 This is your host, Michael Kennedy.

01:16 Follow me on Twitter, where I'm @mkennedy.

01:18 Keep up with the show and listen to past episodes at talkpython.fm, and follow the show on Twitter via at talkpython.

01:24 This episode is brought to you by SnapCI and OpBeat.

01:28 Thank them for supporting the show on Twitter via snap underscore CI and OpBeat.

01:33 Hey, everyone.

01:35 Two weeks ago, I told you I had a huge announcement that I was really excited to share with you,

01:39 but couldn't.

01:40 Now that everything is in place, it's time to share my big plan with you.

01:44 When I started this podcast almost a year ago, I had modest expectations and more than a little

01:50 uncertainty about how it would be received by the community.

01:52 And honestly, every day I'm blown away by how many people's lives I touch and help educate

01:57 in some part of Python that was less well known to them.

02:00 I get a huge amount of satisfaction spending time making Python more relevant to you through

02:04 this podcast.

02:05 I've been thinking about how I do more of that.

02:07 I believe the natural counterpart to this podcast, which exposes people to new ideas and inspires

02:14 them to learn more about Python, is a comprehensive set of online courses to help you go from inspired

02:19 to empowered, from new developer to highly effective developer, from specialized developer to a

02:24 well-rounded one.

02:25 So today, I'm announcing the first course and taking the first step on a journey to build

02:30 this resource for you and the whole Python community.

02:33 Over the next two years, I plan to release 20 high-quality online courses that will be between

02:39 three to ten hours each.

02:41 These no-fluff courses will strive to make you effective with some corner of the Python ecosystem,

02:46 including the Python language, web apps, databases, GUIs, parallelism, and more.

02:51 The first course will be about the Python programming language, and will take a fun and playful approach

02:56 to teaching you the language details such as classes, loops, variables, and more.

03:01 It's called Python Jumpstart by Building 10 Applications.

03:03 It'll be about six hours long, and it will be a comprehensive introduction to the Python

03:07 language.

03:08 If this project resonates with you, I need your help.

03:11 As of today, I'm launching a Kickstarter to make the first course, this first step on

03:16 my journey, a reality.

03:17 Take a moment to visit the Kickstarter to see what it's all about.

03:20 Just go to talkpython.fm/course, and you'll be redirected to the Kickstarter page.

03:26 There are many reward levels, but the main one is the $29 student reward, which gives you

03:31 lifetime access to the course at a significant discount.

03:33 If you believe in this project and want to help, please tweet about the Kickstarter, share

03:38 it with your coworkers, or even back it yourself.

03:41 I'm really excited to start down this path to build something amazing for the community,

03:45 and I can't do it without you.

03:46 So any support or word-of-mouth endorsements you can give me will be deeply appreciated.

03:50 Please let me know what you think.

03:52 Send me a message over email, contact at talkpython.fm, or on Twitter via at Talk Python.

03:58 I'm also doubling my efforts on this podcast as well, so keep listening and sending in suggestions

04:03 and feedback, and I'll do my best to bring you interesting and relevant episodes.

04:07 Now, let's hear from Rob Blau about making movies and video games with Python.

04:11 Rob, welcome to the show.

04:13 It's great to be here.

04:14 Thanks for having me.

04:15 Oh, you're welcome.

04:16 Thanks for coming.

04:17 I'm super excited to talk about Autodesk.

04:19 You guys kind of make a little bit of everything.

04:22 There's so many different pieces of software that you write.

04:25 And it sounds like Python plays some pretty cool part in that.

04:29 Yeah, definitely.

04:30 So Autodesk is a great company.

04:33 The company mission is to help people build cool things.

04:37 So pretty much software that helps people realize their creative vision.

04:43 The largest piece is kind of on the AutoCAD, like production architecture side.

04:49 And the piece of Autodesk that I work in is the media and entertainment division.

04:56 So we get to work with animation houses, visual effects houses, and help build the software

05:03 that they use to do the cool things they do to put pixels and games together.

05:08 That's really cool.

05:09 So if I jump on a train and I go over to the airport and I get on a plane, fly somewhere,

05:18 and find my way to a movie theater, how many of those different experiences are modeled or

05:26 somehow created with Autodesk things?

05:29 Chances are every single step of the way from the car that you jumped into, somewhere along

05:35 the way from the factory that it was created in and the robots that made it, they were designed

05:39 using some of the Autodesk software, the actual car itself, the models, all of the pre-visualization

05:46 that people do in order to figure out what it's going to be.

05:49 And then the actual instructions for building it.

05:51 Autodesk makes products that do that.

05:54 I mean, the city streets and the planning, it's incredible, the places that the software

06:00 is used, and then the airplane, the exact same thing.

06:02 And then you're going to the movie theater.

06:04 The movie theater itself was probably done by an architect who was using AutoCAD in some

06:07 way, shape, or form, or Revit, which is used to build bigger projects and make sure that

06:13 all of the various components in the building, like the HVAC and the design and the wiring,

06:19 all talk to each other and will work once you actually build it.

06:23 And then you finally get the movie showing and you start seeing, nowadays, almost every

06:30 single shot has some kind of visual effect on it, whether it's just a little bit of 2D

06:35 cleanup that happens up to the full 3D.

06:40 The actual environment is completely created from scratch inside of some software.

06:46 Autodesk makes some of the most widely used pieces of software for that, like Maya 3 Studio

06:53 Max.

06:54 All of those are used to model and render what you're seeing up on screen.

06:59 That actually kind of blows my mind.

07:02 That's even more intense than my original thought.

07:04 That's awesome, though.

07:05 It's really cool.

07:06 Fun mission to have to just make it easier for people to realize their creative vision.

07:12 It's a nice one.

07:14 Yeah, I bet it is.

07:15 So let's totally dig into that.

07:17 But before we do, maybe sort of give me your background story.

07:20 Like, how do you get into this place where you're working on basically building everything

07:24 that makes up the synthetic world?

07:26 I had kind of a roundabout way there.

07:29 I went to school for computer science.

07:33 So from Boston, went to MIT and graduated around the first tech boom, did a couple of dot coms

07:42 at that point and built up kind of just a varied background.

07:47 I did a lot of scripting, a lot of database work, a lot of just systems admin kind of stuff.

07:53 Just there was a startup culture and you did whatever you had to do to get going.

07:57 And from that, I went to actually a Linux conference and saw a presentation from DreamWorks,

08:04 DreamWorks Animation, where they were presenting how they're using Linux because they were one

08:08 of the first companies to switch over to kind of big open source software as the foundation

08:14 of the technology that they're using.

08:16 Interesting.

08:17 What were they switching from?

08:18 Do you know?

08:18 Silicon Graphics?

08:20 Yeah.

08:20 Back in the day, it was kind of Silicon Graphics.

08:22 Yeah.

08:23 So they kind of had deals with Red Hat going and figuring out kind of the enterprise Linux

08:29 distro.

08:29 They were early in adopting all of that stuff.

08:32 So you intersected there when they were talking about how they were using Linux.

08:35 Okay.

08:36 Exactly.

08:36 And I got to talking with them and it turns out that they had an interesting job that was

08:44 doing, it's called pipeline work in the visual effects industry, which is the software that

08:49 helps tie together what all of the different departments do.

08:53 So you've got an artist sitting there, they've got a very specific job to do.

08:57 It's almost like in an assembly line in a factory, you've got your station where you're doing your

09:02 very specific thing, except with an artist, it's a very creative process, but they still have to

09:07 take work done by somebody else, get it working for them, do what they're supposed to do to it,

09:12 package it up for somebody else and then hand it to somebody else.

09:15 And all of those pieces other than that creative work is kind of overhead that it's

09:19 nice to artists to not have to do.

09:21 And that's where this idea of pipeline comes in.

09:24 So I was kind of fascinated by that right from this original conversation.

09:29 Plus I had about 10 Boston winters and the idea of California sounded pretty good.

09:35 So I went to work for DreamWorks where I was for five years and was a member of their pipeline

09:43 department, ended up being a supervisor in that department.

09:47 And that actually is where I first started using Python extensively.

09:53 The pipeline at DreamWorks was Pro-based because back originally when you were doing text processing

10:00 and having to glue together different software, Pro made a lot of sense.

10:06 Right.

10:07 What year was that?

10:09 That was about 2003, 2004.

10:12 Yeah.

10:12 I'm talking about right now.

10:13 Yeah.

10:14 Pearl was still in a pretty strong position back then.

10:17 Exactly.

10:17 And the pipeline that I'm talking about had been in place for like a good probably five, six,

10:26 seven years before that even.

10:27 So when it was written, like that was the choice.

10:30 But there was something that was kind of interesting that was happening with software in the 3D space.

10:38 There was already a couple of pieces of software that had Python embedded in them.

10:44 And Maya actually, as one of the biggest, again, taking it back to an Autodesk product, was introducing a version that had an embedded Python.

10:53 And at that point, if one of the biggest applications that you're using in your pipeline speaks Python natively,

11:01 there was a pretty serious indication to DreamWorks as a whole that maybe committing to Python rather than Perl would be a great idea

11:09 because all of a sudden, all of this integration work that we're doing doesn't have to end outside of the applications that we're trying to tie together.

11:19 We get the chance to run inside the application with code that you're using to tie everything together,

11:26 which is amazing because all of a sudden you can speak the same language throughout the entire pipeline

11:33 and do a much more seamless handoff for the artists, kind of, which is, again, the purpose of all of this is to make it so that they can spend their time

11:42 just doing as much creative work as possible.

11:44 Right.

11:45 Yeah, that's really cool.

11:45 rather than trying to integrate Perl and Python and have some sort of handshake or handoff, just make it Python all the way through, right?

11:54 Yep, which actually was, at the time, controversial.

11:58 It was a pretty big jump to do, and it wasn't clear that Python was going to take hold in the entertainment industry the way that it has.

12:06 But since then, nowadays, it's a no-brainer.

12:09 Almost every new piece of software that comes out has an embedded Python interpreter,

12:14 and Python studios around the world is the de facto language that's used in order to do this kind of work,

12:23 in order to tie stuff together, or even just the tools that you write for artists.

12:28 Unless it has to be compiled, you tend to gravitate towards Python to do it.

12:33 That totally makes sense to me.

12:34 What I think is interesting, and I see it happening in data science, I see it happening in education,

12:38 you're telling me it happens here as well, which makes a lot of sense, is it seems like Python is becoming more and more popular, and that popularity is almost accelerating.

12:52 The rate of popularity growth seems to actually be growing, which is really cool to be part of it as that's happening.

12:59 Why do you think that is the case in the entertainment industry?

13:03 I think I was thinking about this in advance of sitting down.

13:08 A lot of it, I think it got its start by being so easy to embed and having kind of this kitchen sink approach.

13:18 Those two things combined together made it so that with just a little bit of C code,

13:24 all of a sudden, the scripting environment that you could offer people became incredibly rich.

13:32 And because of the ease of exposing your C, C++ libraries through to Python,

13:40 even if you just go natively to the Python C API, it meant that all of these programs that didn't necessarily have a great scripting language

13:53 could have one without too much investment.

13:57 Now, Maya actually did have an incredibly embedded scripting language, still does, called Mel,

14:04 but it was only for Maya.

14:06 And people were Mel experts.

14:08 There was a ton of work done in Mel, but your world ended at the boundaries that Maya provided.

14:15 And it didn't give you too much of a chance to extend outside of that.

14:19 Whereas with Python, you get the exact same kind of scriptability, but now you get to talk to the rest of the world and the rest of the universe

14:27 that's also speaking Python, which is huge.

14:30 So I think the application developers saw that, and it wasn't that huge an investment to say,

14:39 like, hey, let's just slap Python in there.

14:41 And then it paid dividends.

14:43 And then once that started happening, it almost was a no-brainer.

14:48 If you're going to be doing this work, you do it in a language that all of the big applications that you're running speak natively.

14:56 And everything just kind of came together around that.

15:00 Yeah, it just kind of snowballs from there.

15:02 Exactly.

15:04 And then once it's kind of established as the de facto, then everything else that comes in just has to speak it.

15:09 In the industry, there's been a ton of new open source projects that are going on,

15:16 like a standard way to pass 3D geometry between applications, a standard way of describing what's going on inside of a 3D scene.

15:28 And every single one of those comes with Python bindings out of the box because everybody knows that you're going to have to interact with it via Python.

15:39 Right.

15:40 So if you don't have the Python bindings, it's almost like you don't have a mature scripting story or something like that.

15:46 Yes.

15:47 And it almost like that can be the bulk of your scripting story.

15:51 And if you don't write it, then someone will write it really shortly because people need it.

15:57 If you're going to be used, you need to speak Python.

16:00 That's interesting.

16:01 You were talking about sort of, you know, you had the scripting language Mel and it was doing fine, presumably,

16:07 but it kind of, it could only do its thing.

16:11 And I think that's also why Python's becoming one of the major reasons why it's becoming so popular in like data science

16:17 is there are languages like R and so on.

16:20 But if you want to build like a full stack sort of thing, like I want to do my, you know, the data science part,

16:26 I want to do my science and my visualization and my web app and my database access all in Python.

16:32 You know, you can't do that in these other more specialized languages.

16:36 So it's interesting to see the parallels over there.

16:39 Yeah, it is.

16:41 I'd actually say the thing that I'm seeing where Python isn't in play as much

16:48 comes from applications that were kind of originally developed for either like a very specific workflow or from outside the industry

16:56 and they're coming in.

16:57 a lot of those actually start with nowadays JavaScript engines built in because I think the same story has kind of repeated itself a little bit on the JavaScript side

17:07 where it's so easy to embed at this point that for very little investment,

17:12 you can go ahead and have a JavaScript interpreter running inside your app,

17:16 just like you can have a Python interpreter inside your application.

17:20 like within the entertainment industry, those are actually some of the big areas where we're kind of have a miss

17:26 in terms of getting everything to talk to each other.

17:28 Photoshop is a good example where there's various somewhat convoluted ways

17:36 to try to get the JavaScript that Photoshop speaks to talk to Python outside of Photoshop

17:41 and various places are doing that.

17:44 But again, it's that idea of just how easy it is to create a scripting environment

17:51 inside of these applications where there's a lot of value to being able to talk to it

17:56 without writing compiled code.

17:57 You know, I think the whole V8, the thing happening with Node, but really the V8 engine itself being a separate thing that you can host

18:06 has done some pretty amazing stuff for JavaScript.

18:09 Exactly.

18:11 And I think some of the full stack, like it's Python all the way through,

18:15 like the whole Node story and V8 is like it's JavaScript all the way through.

18:19 Yeah.

18:20 And it has a lot of the similar kind of parallels where it has a little bit more

18:23 of the kitchen sink, not as much as Python does, but there's more and more JavaScript libraries popping up all the time,

18:30 just like there are Python libraries too.

18:33 So it's interesting just seeing that pattern replicate itself.

18:36 It's kind of detrimental from where I'm sitting, because I would love it if all of those things spoke Python.

18:40 It would make my job easier, but it's just kind of interesting seeing that take hold again.

18:53 continuous delivery.

18:55 Continuous delivery isn't just a buzzword.

19:03 It's a shift in productivity that will help your whole team become more efficient.

19:06 With SnapCI's continuous delivery tool, you can test, debug, and deploy your code quickly and reliably.

19:12 Get your product in the hands of your users faster and deploy from just about anywhere at any time.

19:18 Did you know that ThoughtWorks literally wrote the book on continuous integration and continuous delivery?

19:24 Connect Snap to your GitHub repo and they'll build and run your first pipeline automagically.

19:29 Thanks SnapCI for sponsoring this episode by trying them for free at snap.ci slash talkpython.

19:44 That is super interesting.

19:45 That is super interesting.

19:45 It makes a lot of sense to say either Python or JavaScript as a proposition for somebody who's not a developer but needs to automate a thing.

19:53 To say your API is C++ and you've got to have this compiler with these headers and these libs you're statically linking.

20:00 That just doesn't fly, does it?

20:03 No.

20:03 The stuff that Python is used for tends to be a lot higher level workflow.

20:09 I think you're taking workflow and translating it to code.

20:12 So it tends to be pretty dynamic.

20:14 It needs to be updated constantly.

20:16 I mean, almost each project you'll be tweaking the stuff to work how the people working on that project need to work to get their job done most efficiently.

20:24 And it doesn't need to be performant, I guess.

20:27 Yeah, because it's just orchestrating the things that are probably written in C.

20:30 Exactly.

20:31 Interesting.

20:32 You were talking about JavaScript and having the JavaScript try to interact with Python somehow.

20:40 And obviously getting out of a JavaScript engine can be pretty tricky because they try to sandbox you a lot.

20:44 But have you looked at PyPyJS or one of these embedded JavaScript foundation Python implementations?

20:55 We haven't.

20:56 I guess I should qualify.

20:57 What I'm doing at Autodesk is actually a group that is putting together one of these production pipelines that is just part of a production management product that we make.

21:10 So I'm now not working at a studio doing all this pipeline work, but working at a software company that is, again, just trying to make it so that the various workflows that we see being done in VFX and animation, just content creation in general, we make it really easy for people to get some of the grunt work out of that.

21:29 Given that setup, we're not embedding the interpreters ourselves.

21:35 So I'm working on the scripting code that's going to be able to talk to that application.

21:41 So it's like Photoshop has JavaScript.

21:44 We're not going to be able to embed Python in it, although we could do a plugin, get an embedded Python running.

21:52 But then there's a lot of threading issues and other stuff that we've tried to be as seamless as possible.

21:57 But you can only do so much with an application.

22:01 It all depends on what kind of SDK and API they offer you.

22:05 So we don't have that level of control.

22:07 But we are looking at some standard RPC kind of libraries and trying to figure out what does make for a good bridge between those worlds.

22:16 Right.

22:17 I think probably the easiest way to bridge JavaScript to another thing is some kind of network layer, right?

22:24 Network layer or even if you're not going over the network.

22:28 Yeah, exactly.

22:30 Like RPC, even if it's just talking to another process on the same machine.

22:35 Yes, exactly.

22:36 But making that a really rich communication channel.

22:39 And there's some impressive projects out there that do that.

22:42 And we're actually kicking off an effort to evaluate them and try to pick one that's going to work well for us.

22:51 One of the things you'd sent over is you talked about sort of Python and games.

22:59 And what's the story there?

23:00 Sure.

23:01 Games is kind of an interesting take on all of this because VFX and pixel production has been around longer

23:12 and has a bunch of different constraints than games have.

23:17 So far, games have really been driven by the game engine and the developers as almost separate from the creation of the models and the shaders that show up in the game.

23:34 All of those need to play well together.

23:36 But it's almost been more of an agile developer kind of style than a cascade of content flowing between different departments,

23:47 which is what you see in animation and VFX, mostly because the complexity of all of the environments and models that VFX has been playing around with has been higher than what you've seen in games.

24:01 But that's actually switching a lot nowadays, where the complexity of production in a game is a lot of times higher than what you would see in a feature film.

24:14 The need for this kind of pipeline is showing up in games more and more.

24:20 But they've got this whole coding side to the game where the artists are just a piece of what's going on and they need the developers in order to tie everything that they're creating in.

24:32 And it all comes together in the game engine.

24:34 That is what's actually going to be running all this stuff at the end of the day.

24:38 What we've seen there is there's some game engines that speak JavaScript coming out now.

24:44 The tried and true has been .NET.

24:47 Just a lot of this has been pretty Microsoft-centric.

24:51 And the .NET code can speak Python, the iron Python that's out there, which has been kind of an interesting tie-in for us.

25:01 Or Lua, actually, is another scripting language that a lot of the game engines tend to speak.

25:08 But it's yet another kind of separate world.

25:10 Even the .NET side has limitations.

25:13 It lets us do kind of basic Python integration.

25:16 But you hit brick walls pretty quickly when you want to do cross-platform networking stuff or GUIs, especially.

25:24 You have to start writing things specifically for the .NET flavor as opposed to treating it just like another Python interpreter that's out there.

25:32 Right.

25:32 Yeah, you get very, very specific, like WPF-type stuff.

25:37 You can't do PySide, PyQt type of things.

25:41 That kind of, which is much more cross-platform.

25:43 Can you give me just your feedback on what you've done and what it's like to work with IronPython?

25:48 I haven't actually...

25:49 I've played with it and looked at it, but I don't really know much about it.

25:54 So it'd be interesting to hear.

25:55 I've actually found it to be pretty good.

25:58 The boundaries that you hit are kind of what you'd expect, where Python itself starts having dependencies on third-party libraries, like SSL implementation or the GUI kind of side of the world.

26:10 But, I mean, personally, I've had fun little side projects like getting IronPython up and running in a plugin for Microsoft Office projects.

26:21 So that, you know, there's an API that's available only via Python.

26:24 You can start interacting with it from within Excel in order to kind of get deep scripting ability within something like that without having to write visual basics.

26:33 So that you can, again, reuse that Python code base that you've got.

26:37 Yeah, that's quite interesting.

26:40 It's kind of a Frankenstein kind of approach, but a lot of the integration that we end up doing has some element of that because you're really trying to establish this rich Python programming environment in all of these different spots.

26:57 And some of them are more conducive to it.

26:59 Some of them, you kind of have to jam it in.

27:03 They resist a little more, huh?

27:05 Exactly.

27:06 IronPython was a Microsoft project.

27:09 I think it was created by people inside Microsoft or maybe they created it and promptly joined Microsoft.

27:14 I can't remember the exact chronology of it.

27:16 But they, a while ago, set it free and said, we're not really doing anything more with IronPython, but it's now this sort of open source project.

27:25 The world can have it.

27:26 And I just, like, a few hours ago, although it's been out for a couple of months, learned about this thing called Pyjion.

27:33 Pyjion?

27:34 P-Y-J-I-O-N.

27:36 Have you heard of this?

27:37 I've heard the name, but I don't actually know much more than that.

27:41 It's kind of a competitor to PyPy, which is a JET compiled runtime implementation for Python.

27:49 But this is one that runs on the new open source cross-platform version of .NET.

27:54 So maybe there's something interesting there coming in the future.

27:57 I don't know.

27:57 We'll see.

27:58 But it's interesting to see them taking kind of a second shot at something like that.

28:03 Cool.

28:04 I'll just check that out.

28:05 Because something like that could potentially open up, like, the game engines that speak .NET to the deep integration with kind of the rest of the creative process that would share the pipeline from feature animation and the kinds of complex asset builds, like the models and the various assets that you see on screen, that process for games.

28:29 Yeah, absolutely.

28:30 I mean, IronPython seemed really cool, but kind of like you were saying, its limitation is you're all in on Windows.

28:37 Like, it only runs on Windows.

28:39 You have to really program against the .NET, so at the time, Windows-specific APIs.

28:45 But with the cross-platform plus this, you know, maybe that sort of opens up again.

28:50 It's going to be really interesting.

28:52 I don't know where it is.

28:53 Is that the mono environment?

28:55 No.

28:56 No, it's the mono environment was Miguel de Caza's work on sort of re-implementing .NET, which is Herculean.

29:06 And they've gone on to do Xamarin, right, with the mobile stuff.

29:10 So this is a new effort called the Core CLR by Microsoft to do a shell or a core kernel of .NET that's totally cross-platform that you can do on OS X and Linux and sort of, but, you know, official, not like a sort of frenemy-type project in what they're doing.

29:27 So it'll be interesting to see if this can bring a really rich version of Python to that story, kind of like we have Jython for Java.

29:36 Exactly.

29:37 But, you know, that's not really updated really quickly.

29:40 So maybe, I don't know, I have high hopes, but they may get dashed.

29:43 We'll see.

29:44 I hope it comes out awesome.

29:46 We'll see.

29:46 Definitely dig into that.

29:48 Thanks.

29:48 Yeah, you bet.

29:49 This episode is brought to you by OpBeat.

30:04 OpBeat is application monitoring for developers.

30:07 It's performance monitoring, error logging, release tracking, and workflow in one simple product.

30:11 OpBeat is integrated with your code base and makes monitoring and debugging of your production apps much faster and your code better.

30:18 OpBeat is free for an unlimited number of users.

30:21 And starting today, December 1st, OpBeat is announcing that their Flask support is graduating from beta to a full commercial product.

30:28 Visit opbeat.com slash Flask to get started today.

30:32 There sounds like a lot of positive news from all the cool things you're doing and the way you're able to weave these pipelines together.

30:48 I want to kind of talk about what you see, the sticking points and so on a bit.

30:53 But before we do, maybe just to give me and everyone else a better idea, could you describe what the steps are and this pipeline that you talk about?

31:03 What are people doing?

31:05 What does the software have to do?

31:06 Just so we get a little more concrete idea there.

31:08 The kind of nature of this is that you can go down these giant rabbit holes.

31:14 Like you can go extremely deep into automating things.

31:18 And traditionally, only fairly large studios that could afford having an R&D department had the ability to go deep.

31:27 Lots of places had pipelines, but they tend to be pretty easy handoffs rather than tackling a lot of the deeper issues.

31:35 It can start as early as a script.

31:39 If you've got a script that you're thinking of making a movie of or that you need to do visual effects for, it tends to come in from some program that stores it as an XML file.

31:53 You can write a parser for that in Python and use that in order to get a listing of here's all of the different scenes in the movie and here's the characters and location, things like that.

32:03 Which, if you were doing this by hand, traditionally you would do a breakdown where you would just build up a spreadsheet of all of those things so that you can start getting your head around what you have to build.

32:12 You go ahead and you start storyboarding things so that you get an idea of what everything is going to look like.

32:19 And there's various software that's built around storyboarding.

32:22 I mean, Photoshop is kind of one of few players in that area.

32:26 Even then, you tend to just have these images that you're working on and then tracking those to say, OK, here's the current storyboards that relate to this scene.

32:37 We want to hand them off to editorial that's going to start cutting them together into a movie that we can watch to get a sense of how this plays together.

32:44 There's lots of iterations there that go back and forth.

32:47 So you have to keep track of those files and know which ones were approved, what the notes were, so that whoever's going to be doing the next iteration on that can take those into account.

32:57 And it's really trying to put some organization around a very creative, quick iteration workflow without getting in the way of that creative process.

33:06 So then you start getting this editorial content together where you're cutting together these images on a timeline and you get a sense of timing.

33:15 That tends to be a place where you need a lot of R&D to dig in because a lot of the editorial software out there, Avid being the biggest one, tends to be a little bit of a black box.

33:27 You've got Final Cut, which has an XML spec that you can start taking apart, but you don't get a chance to understand too much of what's going on inside of editorial software.

33:37 Sure.

33:38 So are you guys doing actual processing of MP4 files or raw assets in Python and looking at them, that kind of stuff?

33:47 So an example of how Python would tie in over there, not with Autodesk, but my previous job at a studio that's in Portland called Leica that does stop motion animation.

33:58 We actually, there's a C library around this file format called AAF that is what the Avid editorial software speaks.

34:08 And it's a pretty obscure format, very complicated.

34:12 The API is very complicated.

34:14 And we wrapped that with Python bindings so that we could take a export from Avid and really deconstruct it, which meant that we actually were able to know which storyboards an editor cut in where and what characters were in that storyboard.

34:33 So that when you're going ahead and putting together a shot, you would know generally the contents of that and all of the comments that came through, all of the notes that the director had for the storyboard artist, which is incredibly valuable because in the shot, you've got to go ahead and take your 3D models and bring them in.

34:55 So having the list of what's already been included from the storyboard artist gives your layout artist who's doing that work a leg up and you can get started and you can write a tool to automate the initial pass at that and then let him actually do the creative piece of that, which is where you should be spending his time rather than searching for the right models to put in.

35:15 And then when it gets to animation, it's really valuable for the animator to be able to see all of the notes that the director had for the storyboard artist because they're very applicable to the job that he has to do.

35:25 And none of that would be readily available without being able to connect the dots between all of those different handoffs.

35:32 So connecting those dots and managing those handoffs and making it so that you can deal with this explosion of data that happens throughout this process in a kind of tractable, meaningful way is what the pipeline is responsible for.

35:49 Okay.

35:49 Okay.

35:49 That gives me a really good view into it.

35:51 I think it seems like there's all these different apps that the various people have to use, editors, artists, and so on, and they don't necessarily talk to each other.

36:02 Right?

36:02 So you're kind of writing.

36:03 Yeah.

36:04 So you're kind of writing this glue that can turn that into like one almost distributed data source or something.

36:12 Right?

36:12 Right.

36:14 It's kind of like if you're used to using Excel on one front and you've got this text editor that you use on another front, if you were able to kind of connect those together because it knew that you're doing accounting work and it was able to actually react to the files that you're saving from the text editor, parse them, and automatically bring them into your spreadsheet so that you didn't have to manually do that.

36:39 Each time you've changed one piece of information and get the rest of it in sync with that.

36:45 It's kind of that on an extremely grand scale.

36:49 I don't know if you have the answer off the top of your head or really no, but I'm thinking about all these different processes and all these different raw editions and then produced and sliced up editions.

37:04 So these files, you know, if I go and get like a movie, it's probably a couple of gigabytes.

37:08 But what's the data, the total data size for like a modern production movie or something?

37:15 Do you have an idea?

37:16 Oh, we're in many terabytes land nowadays.

37:20 Yeah, it is terabytes and terabytes in order to do the models and the effects work and all of the simulations that need to happen in order to get the quality that we're seeing on screen.

37:33 It's incredible the amount of data that goes into just those final pixels that you see.

37:39 So like the gig, couple gig download that you get, which is a really high quality video that you could watch.

37:44 Yeah.

37:45 Each of those, you know, frames as gigabytes and gigabytes and gigabytes, like hundreds of gigs behind it alone.

37:52 So we put it all together at 24 frames a second for feature length.

37:56 It definitely adds up.

37:58 Yeah.

37:58 Wow, that's crazy.

37:59 It is the scale and especially just the amount of data and the number of people involved and the amount of handoffs that happen in order to achieve that thing that is on the screen is pretty amazing.

38:14 Yeah, I bet it is.

38:16 Everything sounds really good, but you said that there was actually some issues that you were running into.

38:22 Like one of them was that using Python 3 in this world is not something you can just necessarily jump straight into.

38:28 A lot of the issues kind of around Python use almost come from how successful Python has been and how it's embedded in so many different places.

38:38 We just have this versionitis problem where currently the code that we're writing, we actually support back to Python 2.4 because there's some versions of software that are out there and they've been updated since.

38:53 But studios are pretty notoriously slow to update if everything is still working.

38:58 It had Python 2.4 embedded in it.

39:00 There's definitely a lot of Python 2.5, 2.6 that's still out there.

39:06 The majority of modern stuff is on Python 2.7.

39:08 There's like one notable source project that's made the jump to Python 3.

39:14 But because the nature of this pipeline work is to glue stuff together, when you have a jump that's not backwards compatible, it kind of makes it hard because you have to have two different code bases.

39:29 There's one that will run for all of the environments that are Python 2.5 based and one that will run for everything that's Python 3.5 based.

39:37 And you can kind of work to minimize this.

39:40 But there's definitely this hard jump that happens because not all of these pieces of software are going to update their Python interpreters at the same time.

39:50 And there's nothing that says that you'll be able to, as a studio, be able to update to that version of that software at the same time.

39:58 It gets into a whole lot of issues from just cost, support, licensing, getting the bugs out of it, down to having the resources to update your code to run in Python 3.

40:08 Wow, that's crazy.

40:10 That's going to be an interesting cliff for the visual effects feature animation world to get to the other side of.

40:18 There's various attempts within the industry to try to control this versionitis issue because it's not just Python.

40:26 There's all sorts of common libraries that are used throughout production.

40:31 And whenever they don't match, it causes issues.

40:33 So there's a VFX reference platform that tries to standardize some things.

40:38 Python 3 isn't even on the radar of that.

40:41 I think Python 2.7.whatever is the target for the foreseeable future.

40:48 I think it's probably going to be dropping support with a combination of security issues that just force updates.

40:56 That'll be the thing that finally gets us as an industry to the other side of that.

41:01 But it is kind of unfortunate just because of the wide range of versions that you have to support and the dependent libraries and all of the complications that come up trying to develop software in that kind of an environment.

41:13 Yeah, that really, that's quite challenging, it sounds like.

41:16 I mean, when I think of people that are using Python 2 and they say we can't switch to Python 3, in my mind, I often think of a couple things.

41:26 Like one is we have a quarter million or more lines of code that was tested and is working on Python 2.

41:34 And we're just not going to change that because it's too risky and it's just, you know, it's not broken.

41:39 We don't really want to mess with it.

41:40 That kind of thing.

41:41 And then the other is we've got some key library that we depend on, some package that itself is only Python 2.

41:48 So until that gets upgraded, you can't only flip your app, right?

41:52 But this is a whole nother level, like those two things still apply.

41:57 They definitely still apply.

41:59 They're just one part, right?

42:01 Because you've got multiple compiled, distributed, shipped, non-updating, potentially pieces of software that have a host of versions packed into them.

42:10 And you've got to fit into that.

42:12 That's pretty crazy.

42:13 And then you guys are building software that works with multiple versions of those, right?

42:19 Because you're not building the pipeline to make a movie.

42:21 You're building software to give to the people that are making the movie.

42:24 So it's just, you know, a few more dimensions there.

42:28 It actually is one of the things that really excites me about the project that I'm working on where almost for the first time, rather than building one of these just for a particular studio or as kind of just an open source project, we're trying to do it with the resources of a company like Autodesk behind it.

42:47 Autodesk, which all of a sudden, like the jump to Python 3, which for the industry as a whole feels like it's a huge issue.

42:58 It gives us a place where if all of these vendors for the major applications got together and said, okay, here's the version where we need to switch to Python 3.

43:07 We could do a lot of the legwork for the industry as a whole and get stuff going and create that bridge over to Python 3, which doesn't exist if every studio had to do that themselves and manage it themselves.

43:22 Yeah, that's really interesting.

43:23 You're one of the few groups that lives, you basically are one of the few groups that live between all these pieces of software where everyone else is just consuming it, right?

43:32 Exactly.

43:32 And everyone, you know, almost every company figures out a way to get that in-between stuff written in order to automate stuff that they do.

43:43 It's just too tedious otherwise.

43:45 But we're kind of a central place where we can do that, which gives these software developers someone to work with in order to figure out some of the issues.

43:55 And we definitely wouldn't encounter all of the issues that studios out there could see with the setup.

44:02 But we at least can take it a big step further and prove that this kind of integration does work on the other side of that giant chasm.

44:11 And here's how we did it.

44:12 And here's the issues we found and help other people cross it.

44:15 So another thing that you said that was kind of challenging, kind of like this version story, is PySide and PyQt.

44:23 Can you maybe first of all tell people what that is so that everyone knows?

44:28 And then what's the story there?

44:30 Sure. Qt is a cross-platform C++ GUI toolkit.

44:37 So you can build complicated applications using Qt as the components that you're using to build all of the GUI widgets and do it in a way that's cross-platform.

44:50 So it runs on Linux and on OSX and on Windows.

44:55 Yeah. And one thing I'd like to add about that is that's one of the few cross-platform UI frameworks that I think looks modern and really good on all the different environments.

45:06 Like a lot of times you're like, whoa, that is definitely not native.

45:09 That looks like a weird app or whatever, you know.

45:11 But I think Qt or Qt, it's nice.

45:15 Yeah. I mean, it has a rich set of widgets.

45:19 They're very configurable.

45:20 It ties in nicely with the native OSs.

45:23 It's been around a while.

45:24 It's been used in a ton of places.

45:25 Some huge applications use Qt.

45:28 And it's funny that you say it looks modern.

45:30 There's actually been this divide in the Qt world between Qt4 and Qt5, similar to the kind of the jump to Python 3, where Qt5 is this big leap forward.

45:39 And that's one of the other things that the entertainment industry is trying to navigate the jump from Qt4 to Qt5.

45:47 And to go back to what is Qt and what is PySide, PySide and PyQt are two Python bindings to that Qt library so that you can build these cross-platform, good-looking, complicated UIs in complete Python.

46:00 It's pretty prevalent.

46:01 It's out there.

46:02 It's great.

46:03 But PyQt is not open source.

46:07 There's licensing restrictions around it.

46:09 It makes it hard to build a commercial product around that, even though kind of supporting it as a runtime is completely doable.

46:18 But in order to actually run a PyQt app, you need to be licensed if it's a commercial software.

46:24 PySide, it was the branch, was another implementation of that Python binding in order to kind of get around those licensing restrictions to make it so that within Python,

46:34 you could build these rich GUIs without having all those licensing constraints that come with PyQt.

46:40 The problem with PySide is that it's one of those open source projects that's kind of stalled out.

46:45 And there has not been a version that supports Qt5.

46:51 So ironically, one of the big reasons that the industry can't cleanly jump over to Qt5 is because Python is everywhere.

47:01 And people have used Python to build these really awesome production tools that are Qt4.

47:06 And there needs to be an upgrade path for all of that code.

47:10 So figuring out how to kind of breathe some life into the PySide project and get it going has been a topic of consideration.

47:20 And it's something that, with the help of that VFX reference platform that I talked about earlier, because they are trying to drive this jump to Qt5 because there's a lot of improvements there.

47:31 Qt4 is starting to show some age.

47:33 They're trying to drive some life into the PySide project in order to get this update to be possible.

47:41 It's an interesting thing where, again, this dependency and having all of these different apps coordinate this kind of an upgrade affects how we use Python and what's possible.

47:51 I tend to really think about, I guess, how that kind of paints you into a corner.

47:55 I did play around with PySide and PyQt and ran into the issue of, well, the licensing on PyQt, it seems overly restrictive.

48:05 I'm not really against commercial software, but it seems like, I don't know, it just seems harder or more restrictive than it should be.

48:12 But then again, I tried to use PySide and it was like almost working.

48:16 It was frustrating.

48:18 But I knew if I could get him to work, I'd have something really cool.

48:21 But I kind of gave up and went and did something else altogether.

48:23 Yeah.

48:24 We do a ton with PySide.

48:26 It would be amazing to have it be under more active development.

48:32 Like I said, it's almost there.

48:34 You can do a lot with it.

48:35 There's definitely kind of low-level issues with memory management and things like that at the interface between the Qt world and the Python world.

48:44 that if it was under active development, we would be seeing some upgrades happen that would clean that up and make it easier to develop rich Python GUIs that are embedded in these giant applications,

48:57 which is where we actually realize a lot of just saving artist time so that they don't have to hunt around for files or manually export things knowing the settings that they do.

49:12 And then they can just get back to doing the creative part of their job.

49:19 And all of that currently for a lot of places, unless they bought the license for PyQt, is done in PySide.

49:27 Have you considered using some of the fully native options like Py, OBJ, C, OS X, and Iron Python and WPF on Windows and just having a separate UI layer?

49:41 Definitely thought about it.

49:43 It's a lot of overhead when something like PySide is there and you can write it once and have it work everywhere.

49:52 Yeah, it makes perfect sense.

49:54 It's something I've been thinking about some native apps in Python and I'm like, well, you know, how much, I guess it depends on how much of your code and complexity is in the UI itself and how much you can push down to packages that those two distinct UIs that you'd have to write would consume, you know?

50:12 I mean, at that point, you start wondering, like, would it make sense to have the GUI level written in actually Objective-C for OS X directly and embed a Python interpreter and tie it in like that?

50:23 Like, at that point, it being in Python, you start wondering if having that layer be Python makes sense because you're having to code it specifically for the operating system itself.

50:33 And for the GUI work, you get to use Xcode in a really deep way.

50:37 Right, right.

50:37 Maybe just use Xcode and like Swift now.

50:39 So that's pretty close to Python, actually.

50:41 Something like that, right?

50:42 Exactly.

50:43 Yeah.

50:43 Yeah, but you'd lose all the packages.

50:45 Anyway.

50:45 Exactly.

50:46 And it needs to talk to the rest of the pipeline.

50:49 Again, your general knowledge of what's going on in the production and how to translate between these different applications is usually Python logic.

50:59 So you've got to figure out a way to talk to that.

51:02 Yeah, yeah.

51:03 It's a super interesting set of trade-offs to consider.

51:05 I personally would love to see PySide really come on strong.

51:09 But...

51:09 It'd be amazing.

51:10 Yeah.

51:10 All right.

51:12 I have just enough time for a few more questions for you before you go.

51:15 All right.

51:16 So if you're going to write some Python code, what editor do you open up?

51:19 That's funny.

51:21 I have switched over to Sublime.

51:24 I was kind of diehard VI Vim for a long, long time.

51:28 And Sublime was the first thing that I saw that I was like, okay.

51:30 It's fast enough to launch and fast enough to get going that it competes.

51:35 There's still definitely some stuff that I miss from them.

51:40 But I've grown addicted to multiple cursors.

51:43 Yeah.

51:45 Okay.

51:45 Very cool.

51:46 Yeah.

51:46 I like Sublime as well.

51:47 That's nice.

51:49 There's, you know, many thousands of packages out on PyPI that people can go grab.

51:55 What are some of your favorites that maybe not everyone knows about that they should check out?

51:59 Oh, man.

52:00 I mean, it's not on PyPI.

52:02 But I do think PySide and kind of being able to build a GUI in complete Python and then even package it up with like Py2XE, Py2App or that kind of flavor of that is a pretty amazing thing for people to do.

52:17 It's just kind of cool to be able to take something and actually hand it off as a self-contained thing to somebody else to run.

52:24 Yeah.

52:26 That is really cool.

52:26 And I don't think I or any of the guests have spoken about Py2App or Py2XE or CXFreeze or any of those categories of things.

52:36 Maybe you could just tell everyone out there, like those you can go pip install at least one or two of them, I think.

52:41 Yeah.

52:42 Some of them just come with the Python distributions.

52:45 So it's a way of basically compiling down and freezing the Python interpreter and your code together as a native executable.

52:55 So on OSX, the Py2App will actually create a bundle that has all of the Python embedded in it.

53:04 And the same thing with Py2XE.

53:05 You get a standalone EXE that you can run on Windows and it'll run your code.

53:10 So if you combine it with PySide, then you get this EXE that you double click on and you don't even necessarily know that you're running Python under the hood.

53:20 You got to take the code that you wrote and the speed with which you got to develop it because it's all scripted and you're able to put it together with something like PySide.

53:31 And at the end of the day, you end up with this self-contained thing that you can just email to somebody without them having to set up any infrastructure under it and they'll be able to run it.

53:39 Yeah, that's really cool.

53:40 And you can, it takes your packages and everything, right?

53:43 Yep.

53:43 It embeds it all.

53:45 Yeah, I haven't had a real good use case for that because I mostly do web stuff.

53:48 But yeah, it's really cool to think, you know, instead of zipping up a bunch of scripts and sending them, I go, oh yeah, and you need to, you know, pseudo-pip install this while you're at it.

53:57 Just go, you know, here's your .app, double click it.

54:00 Or here's your .exe, double click it.

54:02 It's great.

54:03 Nice.

54:04 Final call to action or anything people should check out?

54:08 Let's say there's calls to action.

54:12 Then people who are interested in open source development and the PySide, I would recommend that.

54:17 It would be amazing to get people interested in that again.

54:19 All right.

54:20 Awesome.

54:21 And how do they find this project that you're working on?

54:23 Is it something that's out or something you're working on still that's going to come out?

54:27 It is out in a beta form.

54:30 There's a production management software that Autodesk sells called Shotgun.

54:35 You can go to shotgunsoftware.com.

54:37 And everything that I've been talking about is the pipeline developer section of that.

54:43 So the project is Toolkit.

54:44 We're the pipeline toolkit for Shotgun software.

54:48 All right.

54:49 It sounds like a really interesting project.

54:51 And definitely got a fresh look at all the barbs that live in the different versions of all these things.

54:59 Yeah.

55:00 I would say if people are kind of interested in the stuff that I was talking about, the project that we work on is source shared.

55:06 We've got public repos on Git.

55:11 The license is you kind of have to be using Shotgun as a product in order to use the project.

55:17 But all of the Python code is there for people to look at, improve upon.

55:22 We try to do it as a very open project so that everybody that does this kind of work can join together as a community.

55:29 That's great.

55:31 It's been really fun talking to you, Rob.

55:33 Thanks for being on the show.

55:34 Thank you.

55:35 It's been a pleasure.

55:35 Yeah.

55:36 Bye-bye.

55:38 This has been another episode of Talk Python to Me.

55:40 Today's guest was Rob Blau, and this episode has been sponsored by SnapCI and OpBeat.

55:45 Thank you guys for supporting the show.

55:47 SnapCI is modern continuous integration and delivery.

55:50 Build, test, and deploy your code directly from GitHub, all in your browser with debugging, talker, and parallelism included.

55:56 Try them for free at snap.ci slash talkpython.

56:00 OpBeat is mission control for your Python web applications.

56:03 Keep an eye on errors, performance, profiling, and more in your Django and Flask web apps.

56:09 Please take a moment to check out the online course Kickstarter at talkpython.fm/course.

56:15 You get a discount for the course by signing up early and the satisfaction of helping create something amazing.

56:20 You can find the links from this show at talkpython.fm/episodes slash show slash 46.

56:27 Be sure to subscribe to the show.

56:29 Open your favorite podcatcher and search for Python.

56:31 It should be right at the top.

56:32 You can also find the iTunes and direct RSS feeds in the footer of the website.

56:37 Our theme music is Developers, Developers, Developers by Corey Smith, who goes by Smix.

56:41 You can hear the entire song on talkpython.fm.

56:43 This is your host, Michael Kennedy.

56:45 Thank you so much for listening.

56:47 Smix, take us out of here.

57:06 First, developers, developers, developers, developers, developers, developers, developers, developers, developers.

57:11 you