dotnet_title_bar VS FFmpeg

Well for 32-bit foobar there is .NET Component Host + Title Bar component (foo_dotnet_component_host + dotnet_title_bar, previously called foo_title). If you want to make a custom skin you'd have to write it in XML, but there are several user skins for examples.

Not that one exactly, but you could make an exact replica using Title Bar (previously foo_title) and set that to appear at the beginning and ending of tracks. I guess you could even place it in exactly the same screen location. (Though I'm not sure if it might also pop-up on pause/skip and interfere)

So your best bet is the great time sink Titlebar (foo_title) and depending how much effort you want to put in (like everything foobar), you can either use one of these pre-made skins, or edit them in a text editor to see examples of the XML structure and design your own. The great thing is with a bit of graphics / image editing software to help out, you can make it look like anything.

You can always leave the main foobar window minimized and use Titlebar component mini- skins - see screenshots. They are basically just small "now playing" pop-ups.

For example, foo_title component is written in C# and it has a C# wrapper for C++ SDK: https://github.com/TheQwertiest/foo_title/tree/master/foo_title/fooManagedWrapper

Well it could be a foo_title skin (a "now playing" pop-up), but even if not, could certainly make one that looks just like it with foo_title.

(I say "rendered within" because some components render external windows outside the main foobar window, such as foo_title or foo_flowin - they also use their own transparency settings)

Titlebar (foo_title) - there are user made skins, or make your own to look like anything with XML.

FFmpeg (https://ffmpeg.org/)

GPL2

Since FFmpeg is GPL2, doesn’t that require CompressX to disclose its source code?

IANAL, apologies if I miss understand license requirements.

https://github.com/FFmpeg/FFmpeg?tab=License-1-ov-file

This turns out to be a lot of assembly macros to help write one x86 assembly. https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/x86/x...

The sibling comment recommending compiler intrinsics is probably the best way to go for writing SIMD code. A mixture of `` style types and intrinsics to specify instructions is a solid 90% solution compared to assembly.

If you want that last 10%, I think macros are putting the emphasis in the wrong place. They're a somewhat easy way to build up a language abstraction which will work if held carefully, but I'm confident the dev experience using this abstraction when you write invalid code will be deeply confusing.

I would suggest to write a parser instead of the macros. That'll tell you clearly when the syntax is invalid (though possibly not with much precision) and it'll give you a place to put semantic analysis for where valid syntax encodes nonsense. Do the equivalent of the macro expansions on the parsed tree instead of on the text. Emit asm as the "back end".

You might have heard of FFMPEG or ImageMagick for image and video edition in a programmatic way. MoviePy is a Python module for video editing (Python wrapper for FFMPEG and ImageMagick). It provides functions for cutting, concatenations, title insertions, video compositing, video processing, and the creation of custom effects. It can read and write common video and audio formats and be run on any platform with Python 2.7 or 3+.

There are many cloud-based tools and websites that can convert your images, but the problem with these tools is that you usually have to upload the files for them to be processed, and some of their services are not free. In this article, I'd like to introduce a piece of software called FFmpeg, which allows you convert the images locally with one simple command.

To run the demo locally, be sure to have Python 3.11 and FFmpeg installed.