2019/talks/: import yet a few more

transcript of janis's talk imported from
<https://mirror.csclub.uwaterloo.ca/emacsconf/2019/emacsconf-2019-20-automate-your-workflow-as-a-game-developer--transcript--janis.org>
with a few minor corrections (mostly formatting improvements).

1 files changed, 121 insertions, 0 deletions

diff --git a/2019/talks/20.md b/2019/talks/20.md
new file mode 100644
index 00000000..e58a29b5
--- /dev/null
+++ b/2019/talks/20.md
@@ -0,0 +1,121 @@
+[[!meta title="Automate your workflow as a game developer - Jānis Mancēvičs"]]
+[[!meta copyright="Copyright © 2019 Jānis Mancēvičs"]]
+
+[[!template  id=vid
+src="https://mirror.csclub.uwaterloo.ca/emacsconf/2019/emacsconf-2019-18-object-oriented-spreadsheets--cell-mode--dto.webm"
+type="video/webm"]]
+
+### Download
+
+- [Video](https://mirror.csclub.uwaterloo.ca/emacsconf/2019/emacsconf-2019-20-automate-your-workflow-as-a-game-developer--janis.webm) (1080p)
+
+### Transcript
+
+```org
+Welcome my dudes and dudettes to Emacs Central where you get a crazy
+guy who does many things with Emacs like video editing, image editing
+audio, editing and many other multimedia things that people wouldn't
+usually think Emacs user would do.  What I wanted to share is why do I
+love using Emacs; because it grants user a freedom to take on the
+responsibility if they choose so to make their everyday workflow
+amazing.  I don't consider Emacs being a text editor.  It is a lisp
+interpreter on C core and that to me is the greatest beauty of the
+application.  It doesn't install plug-ins.  It changes itself and does
+it on the fly which means it is very fun and efficient to develop
+workflow optimizations through wonderful tools that optimize your
+everyday work.  It's awesome that many talented Emacs users and
+developers have shared their work through incredibly nifty elisp code.
+Yet sometimes there is no need for generalized solution or it's not
+there yet.  And in those cases Emacs can become the most direct
+communication layer between your brain and central processing unit off
+your computer.  And that is something I wholeheartedly believe every
+Emacs users should look into.  That is something that will solidify
+your love for Emacs and that is something that blows any competition
+for away.  Emacs is an interpreter of ultimate high-level symbolic
+hackable language and it provides you with many fun and addicting ways
+to pimp up your editor of life-time.  It is a whole new world that
+out-compete any similar software and for me maybe the most important
+reason why I use Emacs.  I have created many solutions that make me
+happy Emacs user and efficient in doing so.  Today I wanted to share
+with you one of my thoughts realized through this hacker's approach.
+It is a simple yet powerful trick to use your system to its full
+potential.  Blender is another example of an awesome free software
+application, yet it's known for being quite slow with rendering videos
+with any encoder settings.  Though if we take a look at the use of
+system resources, we can notice a very interesting fact that Blender
+primarily uses just single core of your CPU.  So if you own a powerful
+system you can see how it can be quite an inefficient use of your
+system resources.  But as I mentioned previously Blender primarily
+uses just a single core of your system.  There must be a way to use
+more and the good news is that yes, you can use your system smarter
+and spawn multiple processes that will use your system more
+efficiently.  So, let's lay out the solution: we have to use single
+blend file; we have to split it in parts; we have to spawn Blender
+instances for each part; render that part out; and then somehow
+combine those parts together in a single-file.  Luckily there exists
+another incredible free software application called ffmpeg that if you
+have videos of the same format let you to do exactly that.  So, if we
+wrap it all up into a single idea, what we need is: a user interface
+that lets you to specify the blend file and parameters; get info from
+that file; spawn multiple blender instances; render parts; when that's
+done, take all the parts and concatenate them instantaneously using
+ffmpeg into a single final product.  Here can see visual
+representation of what the implementation does.
+
+So guys, let's get to the demo itself.  Here we are in a folder named
+"Example" containing a video file named Example.mp4.  Now, let's go
+Blender itself and let's open video editing view.  There let's add the
+previously mentioned video file and set some parameters like the
+length of the video in frames.  Now, let's get back to the default
+view and there we are going to set parameters like the name of the
+exported video.  Let's name the blend file that is going to be called
+"Untitled.blend" and let's I try to render all the video by the means
+that Blender offers itself.  Now if you are looking at the use of
+system resources, you can see that primarily only single core of the
+CPU is being used.  Dismiss a little higher system resource usage,
+because the screen is being recorded.  Let's go back to Emacs and
+let's find the "Untitled.blend" file.  Let's mark it and choose the
+functionality that I have implemented.  Let's specify the amount of
+the Blender instances to spawn.  Now we can look at the newly-created
+buffers.  We can see that there are three new buffers created.  If we
+are looking into those buffers, we can look at the current rendering
+progress.  There are also other information that is posted in messages
+buffer.  The good news is that it doesn't really affect our work in
+Emacs.  We can create a new file call it "VeryImportant.org" and just
+type of way.  Now, if we are looking at the system resource usage we
+can see that the system is fully utilized.  Initially, we rendered out
+just a single PNG file, which was incorrect.  The good news is that
+it's really easy to change blend file parameters.  So let's just do
+that.  Let's get back to the blend file and there let's change and
+call their parameters.  This time we are going to specify to render
+out video.  Let's also make the video a little bit longer, so we can
+have more time to observe the system use.  This now is a new
+opportunity to check out how the final product is being created.
+Let's go to the folder where there and the render parts are being
+created.  We can see that the file sizes are constantly changing and
+we could even preview those parts.  As we specified to create 3
+Blender instance again we have three buffers.  We can observe the
+progress there.  But, not only that, we can open a buffer and list
+processes that are currently active in Emacs.  We have three processes
+of those blender instances we spawned.  We can stop them or manage
+them in any other way.  If we look at system resource use again and
+filter for Blender, we can see three Blender instances actively
+working in the background in memory.  You can see them in a white
+color.  Let's take a look side by side at the system resource use and
+Blender processes.  Here we can see how rendering is finishing up and
+system usage is falling back down to normal.  Also, you can see how
+Blender processes have disappeared from the list in Emacs.  Now if we
+would add some additional content to our "VeryImportant.org" file, you
+could see down there below in "messages" line that there are messages
+that tell you that the rendering has finished.  We can also take a
+separate look at messages buffer and what messages were printed.  Now,
+finally, we can go to our "Example" directory and see that we have a
+final product: file called "result.avi".  Let's preview the file.  You
+can see it plays back wonderfully and we did it many times faster than
+we would do just by rendering out of Blender itself.
+
+That's it guys.  Thank you so much for watching this video.  If you
+want to know a little bit more or want to get your hands on this
+implementation, please check us out on interwebs.  I'll see you next
+time.
+```