Description: professional terrorist
- User Since
- Oct 24 2015, 5:59 PM (220 w, 6 d)
- Nickname on IRC
- Website URL
Dec 30 2015
...while I'd like to add, that this whole "offline" - "online" distinction seems to become more and more an obsolete style of thinking. In a similar way, as the distinction between "editing" and "compositing", or "editing" and "vfx" became more and more blurry and artificial and besides the point.
Nov 29 2015
Nov 20 2015
Nov 17 2015
Nov 10 2015
...if there is some overarching state you need for processing a frame (or even multiple frames), we could go the old and proven "Handle / PImpl" route. As you probably know, you can build very nice opaque handle types on top of shared_ptr. On the API, we'd only expose the processing-Interface for the user. Thus, in order to do anything, the client needs to get such a handle instance from the OC library. Which then, opaquely, points to the state data you need internally to keep track of some stuff. And since the handle is ref-counting, clean-up works magically and airtight.
Nov 8 2015
Nov 7 2015
Nov 6 2015
incidentally, while we're just at that topic: I have figured out quite well how DEB packaging works meanwhile. So I offer to help with that task, i.e. I can help with or care for getting either just that lib or OpenCine as a whole packed in a proper way for Debian and derivatives (Ubuntu, Mint, SteamOS :-D ), and I'll show you how to keep that stuff manageable.
Nov 5 2015
Workflow-A is a must, but is trivially suported: all it needs on the side of OpenCine is to provide some kind of "Project" or persistent "Session", i.e. something to store
- all the shots belonging together
- the settings for these shots, so they can be reproduced / tweaked later.
some notes at what IMHO would be the next steps...
Oct 27 2015
to summarise some of the previous discussion: we propose the following ideal-typical workflows as point of reference for detailed analysis and planing.