Happy Moon Day 2017!
It’s been over a year since I first posted this video explaining what we need in a virtual studio platform:
I said then that there would be a later video talking about how to actually get there from here, and I expected to do that in a couple of months. In fact, though, the first part of the project for me was not about the virtual studio, but the real one that I work in. After the fire in 2013, there were a lot of repairs that I put off, but I finally started repair work in Summer of 2016 (naively thinking I’d be done that same Summer). In fact, that work took most of the last year. I also did consulting work that paid for computer upgrades and the new render cluster construction project.
It’s been a very busy year, but you haven’t heard much from me about it (just a few posts), because, while installing an air conditioner is extremely important in a hot climate such as ours, it doesn’t make very exciting copy! I’ve made a few attempts to get started at blogging more regularly, but well, you can see how that turned out.
However, I’m getting pretty happy with the new workspace — cleaned, repainted, and a rebuilt multimedia workstation (and yes, there is air conditioning now, although there wasn’t when this picture was taken).
I’m running Ubuntu Studio 17.04 “Zesty Zapus”, which I’m planning to use as our “standard client” platform for contributors. I’m still shaking down the system — the audio and the USB ports aren’t working right yet, but I’ll get there. I also plan to add 5.1 surround sound speakers for editing the 5.1 versions of the soundtracks (the monitor, which is actually a TV, can play the existing stereo tracks).
And now I am starting to set up a development (and “DevOps“) environment, and so I’m back to considering the software deployment and development projects we need.
The Revised Virtual Studio
Over the year, the software plan has evolved slightly. I’ve thrown out some unnecessary options, made some changes to accommodate availability, and some of the scripts in the original drawing have acquired project names now. So here’s the revised concept for 2017:
Deployment Testing
For deployment, I’ve been testing against virtual machines created in VirtualBox, using Ansible. This seems to be a very good fit for our project. I’ve looked into using Vagrant for provisioning virtual machines, which allows you to do everything from the command line, but is somewhat less intuitive. Given that I only handle a half-dozen or so machines for deployment testing, I’d rather just set them up in VirtualBox, using the GUI interface, although I can certainly see the appeal if I had to manage a lot of them.
I looked into containerization of server deployments using Docker, which might solve some problems, but it also creates others, since our software has a lot of interactions and uses both filesystem and database state. At the moment, it doesn’t seem that useful, so I’m stick with native installations on the target computer — but using Ansible so everything can be tested on a virtual system and the system can be rebuilt if anything goes wrong or gets corrupted.
I’ve divided the main Ansible tasks up into “deploy”, “backup”, and “restore” operations. The “deploy” operation puts the servers up “empty” (without any specific project state, except for skins and themes). The “backup” operation saves the state information, including backing up databases and filestores. And then, of course, “restore” puts them back on the server from the backup archives. Naturally, it’s important to make sure we can always restore from our backups, so we’ll be doing periodic restoration tests in addition to backups.
We’ll also use Ansible to create a virtual “standard client” which we’ll make available to contributors. This may provide a way to run software if they can’t get it installed on their preferred operating systems.
I was working on Ansible testing when I my old workstation went down for the last time about a month ago, so I was interrupted. But I am setting things back up again on this new workstation, and should be able to continue work on deployments soon.
What I’m Deploying
There are several distinct deployment projects I’m working on. The most obvious is setting up the public Internet server for our project, including recovering our present website, which we don’t really want to change:
Recovering the present website mostly just means WordPress. We also have a Mediawiki wiki, which we’ve had from the beginning, but haven’t used much recently. I plan to repurpose that towards maintaining technical documentation, mainly aimed at contributors. Although most of that is currently maintained by me, the ability for team members to edit it in the future is probably valuable.
The new server that is really the motivation for all this work is TACTIC, so that’s probably the most important item here. This is very nearly a complete solution for production management for us. We’re installing Mumble with the hope of replacing Skype for rehearsals and possibly team meetings, to meet our goal of doing everything with free software.
Odoo is a business management suite (it used to be called “OpenERP”), and so for now, it’s basically experimental. But we will want it in the future, so we need to start learning how to use it.
I’ve been talking about Big Blue Button for a long time as a meeting solution, but so far it hasn’t seemed like something we need. On the other hand, we aren’t producing episodes on a tight schedule yet, so maybe we will find we need to have realtime team meetings and directing. In any case, BBB is designed for online classes, and provides video conferencing as well as digital whiteboards for communications.
We are leaving Subversion behind, but we still need it installed while we migrate our assets into TACTIC. The Trac web interface for Subversion also includes a documentation wiki, and that content will be moved into the main Mediawiki wiki.
Letting go of Resource Space is hard, because I love the web interface, but the DAMS function will be taken over by TACTIC, so it’s going to become redundant. The only thing is, I’m not sure if TACTIC’s DAMS interface is going to be user-friendly enough to expose to the public for publishing our project assets. If not, we may be looking into giving Resource Space read-only access to the same assets (which I think can be done).
Standard Client
I’m also using Ansible to make my workstation environment repeatable, and that’s our plan for a “standard/reference client” to support for contributors. In fact, a lot of artists will prefer to use other operating systems, but we need to have a standard for which versions of the applications we are using. This is going to be based on Ubuntu Studio, and currently version 17.04 “Zesty Zapus”. This gives us a lot of the correct versions for creative applications:
Blender 2.78a is after an important watershed, which is the addition of improved “lost link” behavior. In earlier versions of Blender, if a file were opened without the necessary linked files present (other Blender files that the file depends on), the links would be DELETED silently, and if one did not notice, it was easy to save the file and lose a lot of work. Needless to say, this could be extremely frustrating and lead to a lot of rework. With the new behavior, there is a “lost link” object in the Blender file, and it is possible to recover this link later. Needless to say, we’re going to insist on using this version!
Synfig 1.0.2 is the same version I’ve trained on.
Ardour 5.5.0 is nearly up to date with the latest release from the developer. I don’t know much about it yet, but it should be good to learn on an up-to-date package.
Audacity 2.1.2 is the same version I’ve been using for awhile now.
Gimp 2.8.20 is a later patch level, but essentially unchanged. It works as expected.
Krita 3.1.2 is a release after some of the recent Kickstarter-funded work that we contributed to. It does not yet have all of the new features (as far as I can tell, Python-scripting is not available yet), but it’s very recent.
Inkscape 0.92.1 is a mixed bag. It’s very up-to-date, including a lot of changes made to improve standards compliance. However, there are some pretty serious performance bugs with some of the dialogs, and there are migration bugs with how text is updated from files made by older versions of Inkscape. I am learning the workarounds for this version, but I do hope for bug fixes in upcoming patches.
Kdenlive 16.12.3 is a much newer version than what I was using before. Lots of stuff has changed, and the program is quite a bit more stable. Because of these facts, I am probably going to be sticking with this application for video editing.
Aegisub 3.2.2 is the subtitle editor I’ve been using, and this version does everything we need.
Brasero 3.12.1 is an alternative to K3B for disk burning, which has pretty much the same features. I believe the big difference is that it uses a GTK GUI.
Tupi 0.2-git08 is a flash-like animation program. We haven’t used this for anything, but it’s interesting that it’s standard in Ubuntu Studio.
OBS 0.15.4 is a one-stop-shop for screencasting, which has a lot of extra features compared to Kazam and Vokoscreen which we had been using. I haven’t tested it yet, but it looks promising.
Mumble 1.2.18-1 is the teleconferencing client to go with the server we are setting up. Clients are also available for iPhone, Android, and other devices.
Extra Packages
These standard packages take care of most of our needs. However, there are still a few packages we are going to need to add:
Three of these packages are available from the Morevna Project as AppImage packages. This is not my ideal format, and I might want to consider migrating these to Debian format anyway. But for now, the low-impact solution will be just to install the AppImages.
The others are available as Debian packages from various sources.
Papagayo-NG is the newly-coined name for the pure-python fork of Papagayo, the lip-sync animation tool which is what we and Morevna Project are using and extending. It’s a lot easier to develop for, at least for me. The new version brings support for multiple audio formats include the FLAC files we prefer to use. There are also additional animated mouths and more language support.
RenderChan is Morevna Project animation build script, which manages dependencies on Synfig and Blender animation projects. We have not yet tested this, and there are some conceptual questions about how it will deal with computationally-intensive rendering tasks, but it could be very useful automation for us.
OpenToonz is the newly-open-sourced 2D animation suite based on the system Studio Ghibli has been using. There’s been a lot of excitement about this release, and so naturally we’d like to have it available for future work.
Natron is a node-based compositor, quite similar to the compositor embedded in Blender, but standalone. It’s very important in VFX work. It’s less obvious to me that we need it for animation, but again, I’d like to have the option.
Trelby is a specialized editor for writing screenplays. We’ve usually just used LibreOffice for that (which is standard in Ubuntu Studio), but this is something we’d like to try out. One feature that might be very useful is that it has features to collect information from scenes, such as which characters and sets are needed for them, which could be useful for automating our asset lists for production.
Finally, DVDStyler is a must-have for mastering DVDs. I don’t really know why this isn’t standard in Ubuntu Studio, because it’s a great deal more capable than the DVD authoring packages they include. It’s what I’ve been using for a few years now (before that I used QDVDAuthor, which was also good, although somewhat less polished).
New Development Projects
Finally, we come down to the list of scripts and programs we’re actually going to have to develop ourselves, present here in order of priority to finish:
This is probably the scariest part for me, because this represents a lot of work and is very hard to predict. The highlighted projects are ones I hope to finish this year (by which I meant “finish a release-ready version of the software”).
RenderQueue
The first and highest priority is simply the control script for the Render Cluster I’m building (or any future cluster or farm). This needs to handle accepting rendering jobs to run and dispatching to the right computers when they are ready. It should have a lightweight web interface similar to the CUPS print queue, with a RESTful interface that allows you to check the status of rendering jobs, increase or decrease their priority, and cancel them if necessary. It should also allow us to change certain quick-preview features for renders, such as which frames get rendered first and whether Freestyle is included or not. These can all be handled by passing scripts to the Blender files when they are rendered, and for the web interface I’m planning to use a microframework called “Flask“, which uses the same Jinja2 templates that Ansible does. Hopefully this is little more than a weekend project and will only take a few hundred lines of code, including templates.
KitCAT
Next is the package that will probably be our big contribution to the Blender animation world. TACTIC is a great asset-management system, but it lacks much integration with Blender or other free-software creative applications, and most of the features are normally accessed through a web application. This is fine for the manager, but it’s a flow-breaking detour for artists. Our plan is to create a TACTIC microclient targeted at artists’ needs that runs as a small Python/Qt app and is triggered directly from programs with a set of plugins tailored for each application. Not only will this make accessing the client smoother, but it will also be context sensitive, because the plugin will collect metadata on the file being edited and use that to establish context. The artist will be able to instantly find any director’s notes on the file, other people who’ve worked on it, its status in the project DAMS/VCS, and so on. We call it the “Kit for Creative Arts Teamwork” or “KitCAT” (which is also very nearly “TACTIC” spelled backwards). It’s the other side of TACTIC, and it’s job is to help “herd cats” on collaborative art projects.
I’m very excited to have found some help on this from Katrina Niolet, who is an experienced Python and Qt developer. We really got lucky there!
You’ll note that the concept has evolved a bit from when I was planning to develop it purely as a Blender plugin. The present concept is that the plugin will trigger the Qt app and preload it with context information. The advantage to this approach is that we can extend it to other applications while maintaining a consistent interface (for example, in Ardour, it will be necessary to write the plugin in Lua, but the result will be very similar).
The logo is just clipart, BTW, I want to replace it with a better cat.
Lib-Ray Player
Then of course, there’s my long-standing “old business” with the Lib-Ray player project. This is tantalizingly close to being finished, and yet not quite there. Most of the hard technical problems have been solved, and the remaining work is mostly structure and organization (building the right object model for the player, etc). We also still have to integrate the input system for remote-control commands.
After that, things get a little fuzzier and further in the future.
GraphDiff
I really want to improve the way that collaborative version control works with Blender files, but this requires solving some rather esoteric computer-science problems. Blender files are basically object databases, whose internal structure can be represented by what computer scientists call a “graph”: essentially a set of nodes and links between them. This is as opposed to flat sequential record structures or lists, which is a one way to think of text files (each line is a record, forming a long list of records).
For decades, we have had widely available algorithms for combining parallel edits of sequential data files like text files. The “diff3” algorithm compares two edits of a base file to find out what makes them different. It can then combine the two to get a result file which combines the changes from both edits. This is used all the time in merge-based version control systems, the first of which was “RCS” released in 1982. It later lead to CVS, then Subversion, Git, Bazaar, and other modern version control systems. The algorithms to “merge” files are at the heart of all of them.
But they only work on sequential data. For graph-structured data, there has been no equivalent, even though a human can usually figure out how to do the same thing (but it’s a lot of work). Creating an automated diff3 for graph-structure data has the potential to be a leap forward for artistic collaboration, since many common data types of interest on these projects are graph or object structures. It’s also a good model for the file structure of a whole project.
Fortunately, computer scientists have not been idle, and I was able to find a paper (Eder & Wiggisser 2006), that outlines what I believe is a usable algorithm for our purposes. It works on “directed acyclic graphs” (which a well-behaved Blender file should be — cycles may not be impossible with Blender, but they should be broken anyway if they occur, and there are methods for doing that). The first step in solving this problem is to implement that algorithm in Python (possibly using a graph library, like graph-tool, shown here, although we could also implement the whole thing in Python).
Sometime ago, I made an explainer video describing the problem and what needs to be done to solve it:
BlendMerge
Once such a library exists, it will be a relatively simple thing to implement a tool for merging two Blender files with parallel edits. The files will have to be analyzed as graphs, then the change sets calculated, and then the graph changes will have to be turned back into equivalent manipulations of the Blender file (which can be scripted). The program will then reassemble a finished, merged Blender file from the three input files. As with the ordinary diff, it’s possible for this to fail and require flagging a conflict, but it will often work automatically.
Odoo-TACTIC Project
Finally, there’s a lightweight script that I anticipate needing to glue TACTIC together with Odoo, since we’re probably using both. It’ll probably be implemented as an Odoo module that calls TACTIC through the client API. The idea is simple to move some project data fields from one to the other, which we’d otherwise have to do manually. I list it here mainly because it’s on the virtual studio plan, but it’s a relatively low priority for the near future.
Of course, this may not be an exhaustive list — I’m sure we’ll find other problems to solve that require some development, but I want to outline the ones I can see now, including the three high-priority items at the top that we are working on immediately.
I expect to post more about these individual projects as they progress.
Help is always welcome!
Naturally, if you are interested in helping on any of these projects, please just contact me (I’m “digitante” at gmail), and we can talk about what needs doing. Most involve some Python programming. I’d also be interested in anyone willing to work on Debianizing packages or getting the existing packages into Ubuntu Studio proper, which would be our preference.
