Add support for Nullsoft's Advanced Visualization Studio .milk preset format

[kblaschke]

Nullsoft published another WinAmp plug-in called "Advanced Visualization Studio", short AVS. It enabled users to create presets with a simple-to-use editor and save them in the native .avs file format, but also had support for Milkdrop presets with additional syntax and features supported.

projectM currently has no support for these presets in either format. AVS .milk files generally render as a black screen as the preset parser can't make sense of the additional syntax.

AVS native presets support a huge amount of additional pre-made effects, which would need to be implemented to support the AVS native format.

This ia a long-term effort. If anyone want to implement parts of it, with supporting the additional Milkdrop syntax as a priority, you're welcome!

Full AVS source code can be found here: https://github.com/visbot/vis_avs

[ghost]

I found a github user who has ported AVS. Maybe he can be asked to become a projectm contributor?

https://github.com/grandchild/vis_avs

[kblaschke]

It's not really ported actually, it just got a CMake build system and compiles with MinGW, which is a GCC-based cross compiler toolchain that makes it possible to compile native Windows PE executables on other operating systems without using the Visual Studio build tools. It still uses Windows APIs, including DirectX. Porting it to Linux and macOS would be a major undertaking as it would require rewriting the whole rendering stack. With SPIRV-Cross, it's probably a bit easier to transpile the shaders into languages of other 3D APIs like OpenGL, Vulkan and Metal.

That said, there's probably enough to do for grandchild on AVS alone.

[grandchild]

hi there.

two things:

• the "rendering stack" would not have to be rewritten, as it's only the actual drawing to the screen that uses DirectDraw (the older cousin to DirectX). i am actually fairly confident to have a working Linux/SDL port by the beginning of 2022. the bigger task for avs will be to create a new UI, because UIs are always at least 50% of a project effort. but since i'll be creating and maintaining a "libavs" similar to libprojectm, i don't strictly have to do that. 😄
• currently i don't know much about projectm and how and if it should even support avs. avs is a whole different beast, without gpu and all that fancy stuff. so i'm not sure avs should/will be integrated into projectm

[grandchild]

and one correction: AVS has ".avs" files, not ".milk".

i wrote a converter for the AVS preset file format that will output JSON some years ago: https://github.com/grandchild/AVS-File-Decoder , you can try an online version, courtesy of @idleberg, here: https://idleberg.github.io/webvsc-ui/ my AVS port/fork will work with a JSON-based preset file format in the future. the binary format will continue to be supported.

[kblaschke]

Interesting. Did not look too deeply into the source, but you're correct, there's no fancy shader stuff or hardware acceleration anywhere. There's definitely Milkdrop preset support (parsed with ns-eel) in it, but given AVS is completely 2D-based this seems to only support Milkdrop 1 preset syntax which doesn't include support for warp/composite shaders.

projectM could possibly use a cross-platform AVS library for playing presets (as you stated, original AVS has a UI to create these), as it is quite modular in design (see PresetFactory classes). Drawing the AVS output into a texture shouldn't be hard, as projectM already does the same with Milkdrop presets.

[grandchild]

I want to port AVS to EEL2, so that should become even more compatible. But AVS has a strange plugin ("EELtrans") that extends eel with macros and other helpful shortcuts. It preprocesses that code into proper EEL code every time the NSEEL_compile function is called. The original plugin took the function pointer and drilled into the binary instructions it found there. In my re-incorporation of the plugin I extended EEL to provide a pre-compile hook so that all this code-transformation happens a bit more above-board.

tl;dr: There are quite a few AVS presets out there that don't use vanilla EEL but a custom flavor. This would have to be accounted for, when interpreting EEL from AVS presets.

[grandchild]

And yes, I hope that a libavs should be quite capable of being used in this way. My interface for the framebuffer is a plain malloc'ed memory section, in whatever pixel format AVS can support (currently only RGB0-8888).