The brighter side of Anywhere

Today another interesting thought about Adobe Anywhere struck me. Essentially, part of the idea of Anywhere is to totally divide the UI from the renderer. The concept in itself is nothing new, and all 3D applications use it. However, as far as I know, it is the first time that it has been applied to an NLE.

The obvious implication is the possibility of network rendering, and using more than a single machine for hefty tasks. Of course, there are a lot of caveats to multi-machine rendering, and we already know that not all problems scale well, and sometimes the overhead of distributing processes is higher, than the gain in speed. But in general, the more means the better.

The less obvious implication is the possibility of running various types of background processing, like rendering or caching parts of a sequence that are not currently being worked upon, if the resources allow. This means a quicker final render time. It also allows to run multiple processes at the same time, or even multiple parts of the rendering engine at the same time, allowing for better utilization of server’s computational power.

However, the most overlooked implication is the fact, that the renderer is UI agnostic. It doesn’t care what kind of client gets connected, it only cares that the communication is correct. And this has potentially huge implications for the future of applications in Adobe’s Video Production line.

Pipeline

Anywhere Renderer most likely already consists of several separate modules – After Effects, and Premiere, possibly even Lumetri (SpeedGrade), which can be chained in any sequence. For example, the client sends a request to render a frame at half-resolution consisting of the following stack: V1 P2 clip, V2 Red One clip with Ultra Keyer on it, V3 Dynamic Linked AE clip with lower thirds, and a color correction via Lumetri on top of it all.

Adobe Anywhere makes Premiere renderer open a Premiere sequence, finds a dynamic linked clip overlaid on a source material, and asks After Effects to render it, at the same time composits the V1 and V2, and once AE is done, composits the result together. Then it sends the whole thing to Lumetri for color correction. Each stage is most likely cached, so that when the CC or the keyer is changed, the AE does not have to re-render the thing. Then the frame is rendered and sent out to the client.

Running locally

However, it’s all in the client-server architecture – you might say. How about those of us who use the programs on a single machine? Anywhere will not have any impact here… or will it?

There is nothing stopping Adobe from installing both the server, and the client software on the same machine. After all, the communication does not care about the physical location of client and server that much. It cares about the channels, and whether the messages are being heard. Perhaps the hardware might be a little bit problematic, considering the fact that both UI, and render most likely use GPU acceleration. But other than that, all Adobe needs to do is to distribute the Adobe Anywhere Render Engine as part of any local application. It would perhaps be custom-configured for local usage, to streamline some tasks, but it’s going to be the same Anywhere.

And that, dear readers, could be huge.

Implications

Separating the UI and a renderer is a brilliant move. In the long run it allows Adobe to alter the client without rewriting or even incorporating the renderer code in the application. For all Anywhere cares, the UI could be as simple as an HTML5 application which would send and receive the proper messages. Need I say anything more? Let your imagination run wild already.

The regular readers perhaps already see where I am going with it. The newcomers are encouraged to read about my vision of Adobe conforming tool, and – why not – Stu Maschwitz’s proposition of merging Premiere Pro and After Effects, or my hopes of seeing a Smoke-like ubertool from Adobe. Any such application could access Anywhere’s backend, and could be optimized to suit specific needs, giving birth to a number of tools specific to certain needs. Tools which are easily written, quick to update, perhaps even accessible via mobile devices. And in time they might also work locally, on a single powerful machine. Or on a number of them. Wherever you prefer. Anywhere.

Tagged , . Bookmark the permalink.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.