Quartz Composer is a graph of filers that you can interconnect in a graphical interface. You use it to create visual filters or generators. iTunes was using Quartz composer files .qtz for some of his music visualizers.
Quartz Composer is GPU accelerated thanks to its use of the Quartz API.
It was very popular with artists because of the creative freedom it gave when composing the filters. You did not need to be a developer to create a filter, thanks to the editing application.
Quartz Composer is now deprecated and dying in slow and anonymous death.
XQuartz is a windowing system accelerated with Quartz. The X system was not invented by Apple but very popular on top of Unix.
I tried several things but what got the interest of my daughter(10) is code.org
She also uses it at school, and she regularly enjoys working with it on her own.
Because she seems to go more toward the graphical creative side, I made her work on the logo of a personal project I work on at the moment, and she did enjoy it a lot.
Sometimes I ask her to edit some c++ code I work on and see how the result is when running the code from Xcode; we have a lot of fun doing that!
A specialty of those is that they're interactive SVGs. Especially for building the ADSR graph, I found working with an approximate function that "drew itself" much easier than working with the canvas or webGL.
But I have plans to build a wave table (similar to the one in Ableton Live) in webGL.
It's not related. The "page tearing" problem is caused by the way imgui handles events.
You describe the UI by making a bunch of function calls, each of which immediately renders a piece of the UI and returns any relevant events (e.g. render a button, return whether it has been clicked). But this means that any event that should change how the UI is rendered may have missed its chance- what if the changed part of the UI has already had its function called that frame?
The "ideal" dataflow, as far as this problem is concerned, would be to fully process all the events in a frame (from raw input, to widget-level events like button presses, to application-specific stuff) before rendering anything.
They've maintained Telegram and Telegram X for Android for a couple years now too, and for almost a year on iOS until X replaced it. This is far from a new thing for them: https://telegram.org/blog/telegram-x
I use FFmpeg for many years, and I did wonder many times why isn't there a CLI that would be simpler to use but still useful for most tasks.
To my knowledge, no project succeeded in doing that. It's not difficult to code a simple reader and a basic encoder, but then you have many cases not supported correctly, as you wrote.
IMO, the main problem with ffmpeg is that the official documentation is overly intimidating to newcomers. While the command syntax isn't great, it's not terrible either. Probably one of the contributing factors is overcomplicated poorly written internet tutorials copying out-of-date technical memes, like how people complain about tar -zxcvbnwhatever despite tar -xf file covering 99.9% of decompression cases.
For me having visuals nicely synchronised to the music is adding a lot.
Now that you have a nice custom tools to produce video you should build on it and produce more of them. You have a fan here!