Novacut

Bug #680865
Comment #1

Comment 1 for bug 680865

Revision history for this message

Jason Gerard DeRose (jderose) wrote on 2010-11-25:

hellocatfood in the house! Thanks so much for stopping by #novacut.

Super important feature and I'm really glad you brought this up. It's something I've thought about quite a bit, although I haven't written about it yet.

I absolutely agree that animation (keyframes and both linear and non-linear interpolation) needs to be cleanly implemented once and then used to animate anything and everything that needs to be animated.

I would like to have a set of intuitive transitions similar to what MooTools uses 'sine:in', 'bounce:out' , 'quad:in:out', etc. See http://mootools.net/docs/core/Fx/Fx.Transitions

I think that would be a good place to start as far as non-linear interpolation goes. Then later we could add support for arbitrary cubic Bézier splines as well.

One of my pride points (I know, shouldn't brag) about the Novacut architecture is that we're going to have a *very* clean separation between the user interface and the backend. A big goal is to make implementing the UI so little effort that you can treat the *implementation* as throw-away... because to the end user, all they care about is the design, the implementation is worthless. If the implementation is too much work (too valuable), you tend to protect that value. So we need to make the implementation worthless... because to the user, it is. Anyway, blah blah blah...

Part 1 of worthless implementation: we're using HTML5/JavaScript for the UI. Familiar, productive web technologies that countless designers already know. When running as a native app, we'll use embedded WebKit. We also want to be able to run it through a normal browser talking to a server, where this is practical. We expect serious editing wont be very practical at all, but if people can at least browse through an edit over the web, that's still super cool (not to mention a great way to advertise Novacut).

Part 2 of worthless implementation: save edit as a collection JSON docs (dicts) in CouchDB, the UI updates these JSON docs directly and saves them to CouchDB. Instead of having some complicated API for manipulating the state of the edit, the UI just manipulates the (serialized) state of the edit directly. Couldn't be simpler. Plus web browsers make manipulating JSON super easy. I'm putting a lot of effort in into making the edit description as simple and clear as possible, very close to the metal. I think having such a simple, clear edit description can really help the design efforts too because there's no ambiguity about what needs to be communicated, what's being modeled.

Point of all this is that once the schema for describing keyframes and interpolation pretty sable, people can start going crazy on the design side and implementing these designs even if the backend doesn't yet support it.

I need to do some research into how keyframe and interpolation support is at this point in GStreamer. A bit of work might be needed on this front, but I think the foundations are already there.

hellocatfood, you should talk to JamesMR in #novacut - he's worked with a ton of different professional editing software and has spearheaded some really nice mockups. And you should talk to tonsofpcs in #novacut (@eric_adler on Twitter) - he has an extensive broadcast engineering and television background, mucho editing experience. I'd love for the three of you to come up with a "list of pain" so to speak... demanding animation features/scenarios you would like Novacut to support.

I think it's important that from the get go the keyframe and interpolation semantics be able to represent anything an artist might want to throw at it... even if our backend might take a long while to support it all. That way we don't back ourselves into a corner going forward.

This is a good big-picture of the Novacut distributed architecture: http://cdn.novacut.com/couchone-guest.html

BTW, the "storage server" in that diagram is dmedia: https://launchpad.net/dmedia

hellocatfood in the house!  Thanks so much for stopping by #novacut.

Super important feature and I'm really glad you brought this up.  It's something I've thought about quite a bit, although I haven't written about it yet.

I would like to have a set of intuitive transitions similar to what MooTools uses 'sine:in', 'bounce:out' , 'quad:in:out', etc.  See http://mootools.net/docs/core/Fx/Fx.Transitions

I think that would be a good place to start as far as non-linear interpolation goes.  Then later we could add support for arbitrary cubic Bézier splines as well.

One of my pride points (I know, shouldn't brag) about the Novacut architecture is that we're going to have a *very* clean separation between the user interface and the backend.  A big goal is to make implementing the UI so little effort that you can treat the *implementation* as throw-away... because to the end user, all they care about is the design, the implementation is worthless.  If the implementation is too much work (too valuable), you tend to protect that value.  So we need to make the implementation worthless... because to the user, it is.  Anyway, blah blah blah...

Part 1 of worthless implementation: we're using HTML5/JavaScript for the UI.  Familiar, productive web technologies that countless designers already know.  When running as a native app, we'll use embedded WebKit.  We also want to be able to run it through a normal browser talking to a server, where this is practical.  We expect serious editing wont be very practical at all, but if people can at least browse through an edit over the web, that's still super cool (not to mention a great way to advertise Novacut).

Part 2 of worthless implementation: save edit as a collection JSON docs (dicts) in CouchDB, the UI updates these JSON docs directly and saves them to CouchDB.  Instead of having some complicated API for manipulating the state of the edit, the UI just manipulates the (serialized) state of the edit directly.  Couldn't be simpler.  Plus web browsers make manipulating JSON super easy.  I'm putting a lot of effort in into making the edit description as simple and clear as possible, very close to the metal.  I think having such a simple, clear edit description can really help the design efforts too because there's no ambiguity about what needs to be communicated, what's being modeled.

I need to do some research into how keyframe and interpolation support is at this point in GStreamer.  A bit of work might be needed on this front, but I think the foundations are already there.

hellocatfood, you should talk to JamesMR in #novacut - he's worked with a ton of different professional editing software and has spearheaded some really nice mockups.  And you should talk to tonsofpcs in #novacut (@eric_adler on Twitter) - he has an extensive broadcast engineering and television background, mucho editing experience.  I'd love for the three of you to come up with a "list of pain" so to speak... demanding animation features/scenarios you would like Novacut to support.

I think it's important that from the get go the keyframe and interpolation semantics be able to represent anything an artist might want to throw at it... even if our backend might take a long while to support it all.  That way we don't back ourselves into a corner going forward.

This is a good big-picture of the Novacut distributed architecture: http://cdn.novacut.com/couchone-guest.html

BTW, the "storage server" in that diagram is dmedia: https://launchpad.net/dmedia