Gitframes
github.com
github.com
Look, you can’t just write this. When you say something like this, you set the bar extremely high, and open yourself up to (totally fair!) criticism if Photoshop or After Effects gurus point out entire classes of use cases you aren’t handling.
If you want people to talk about what your tool is good at, you need to stop inviting comparisons to titans like this. It will take you a long long time to build something as fully featured as them, and there is plenty of room for agent-focused tools that aren’t at that immense product scale.
It's cool that so many people are building useful tools with LLMs, but for the love of ones and zeroes, people! PLEASE write your README by hand, instead of handing it off to the LLM with no human involvement! You know how unreadable LLM prose is! Why do you make that the first thing people see when they see your repo?
Stick that in front of your wall of LLM text, and I'd at least have confidence that some day you're going to come back and make the README readable.
Someone at work recorded a demo of a new feature using Claude + https://github.com/veedstudio/open-edit
It was pretty slick and he said he only did two passes on it. Not sure what it means for Adobe, but hopefully it lights a fire under them.
I have a project like this: it setups up a scaffolding: scripts, audio tracks, hot-reloading authoring UI, TTS/STT, sfx, music, shared-styles, beats, video composing, time-control for deterministic rendering, etc. Then you can use any web-technology to render (webGPU, Lottie, shadcn, SVG, whatever).
https://github.com/JohnHeibel/PDoomVideo https://www.youtube.com/watch?v=8j-hR4fJywU
I'm basing this on my experience with vibe coding; asking an LLM to regurgitate code which compiles and does something is easy, but having it produce a meaningful project with changing/evolving requirements along the way, which follows an idea you are trying to describe carefully but evidently not well enough, is significantly harder and error prone [1].
At this point in my project I'm not sure if using Claude as the only way to implement changes was actually faster or better, vs. implementing it myself where an LLM only assists with functions and overall guidance. I feel that up to half of what Claude spends its tokens on at this point is fixing old code whenever it needs to work on the core functionality in some areas of my project.
[1] CoBirb hobby project: https://github.com/HeckerBirb/CoBirb/
Also, interesting project!
...and WoW: Forever Beta just released... :) :)
I agree the framing is too arrogant though, about replacing blender etc, except if it's delegating the computing to those, because it is very complicated.
here's my last work that need quite a lot of work to get where it is, but I know what I do also:
bsf.hmsu.org
works on mobile as old as iphone12
Wouldn't that be trivially easy to do?
If somebody thinks "this product is flawed in this specific way" is a bug report and an indicator of something to be fixed (assuming the bug report is valid, some bug reports aren't), then that person has the hacker ethos and will produce good products.
There are a couple comments that do fit the "being mean" framing, yes. But most of the comments here are along the lines of "here's a flaw in the product which would make it better if it was fixed". For example, my own comment pointing out the unreadability of the LLM-generated README: I pointed out a flaw and how to fix it. (I also made a point of mentioning that it seemed like a useful tool. I didn't spend too long on that point, because the bug report ("make your README human-readable, please") was the main point of my comment). But if someone were to take a comment like mine, pointing out a flaw and suggesting a way to fix it, as "being mean", then I would kindly suggest that that person find a different job than software engineering. Because every time the compiler says "Syntax Error", it's pointing out a flaw in your code. Any person who can't handle flaws in their work being pointed out, can't handle this job.
The year before, the committee decided demos were a no go. Peter Conn wrote Flying Logos to sneak their demo reel into the film show by turning it into a story: a client calls Flying Logos, Inc. to visualize a logo, technical vs. anticipated, imagination vs. possibility. It worked!
https://www.youtube.com/watch?v=9hIOfEiy4lc
https://news.ycombinator.com/item?id=36751574
>Coco Conn and Paul Rother wrote this up about what they did with FORTH at HOMER & Assoc, who made some really classic music videos including Atomic Dog, and hired Charles Moore himself! Here's what Coco Conn posted about it, and some discussion and links about it that I'm including with her permission: [...]
>First shown at the 1989 Siggraph Electronic Theater to a rave response, this 3 minute humourous film went on to win several top computer graphic awards that same year including Niccograph of Japan.
>Coco: This was a show favorite at the SIGGRAPH film show that year. The year before the conference committee decided that showing demos wasn't the way to go anymore. Peter wrote Flying Logos as a way to sneak our demo reel into the show by turning it into a story. It worked and we made it into the film show.
>Don: I truly believe that in some other alternate dimension, there is a Flying Logo Heaven where the souls of dead flying logos go, where they dramatically promenade and swoop and spin around each other in pomp and pageantry to bombastic theme music. It would make a great screen saver, at least! Somewhere the Sun Logo and the SGI Logo are still dancing together.
No but to be serious, I don't know how well this works but it CLEARLY targets people who want motion graphic animation / keyframe stuff, that you normally would do with AE. If you just want to cut a few clips it's not even targeting you. No reason to get all upset about it.