Git Product home page Git Product logo

vis_avs's Introduction

vis_avs - Advanced Visualization Studio

Advanced Visualization Studio (AVS), is a music visualization plugin for Winamp. It was designed by Winamp's creator, Justin Frankel, among others. AVS has a customizable design which allows users to create their own visualization effects, or "presets". AVS was made open source software in May 2005, released under a BSD-style license. — Wikipedia

Modern Toolchain Port

This fork is a MingW-w64 GCC 8+ as well as MSVC 19+ port of AVS.

The goal was to create a v2.81d-compliant vis_avs.dll version that can be built with a modern toolchain, which was largely successful. One notable exception being that APEs (AVS Plugin Effects) cannot be loaded — so many effects are integrated as builtin effects instead.

Current Status

  • 🎉 Builds with MinGW-w64 GCC into a running vis_avs.dll, loadable with Winamp.
  • 💃 Runs most presets (unless they use rare APEs).
  • ❤️ Sources of original effects integrated as builtin-APEs, thanks to donations to free software by their authors:
  • 🎂 Former plugin effects rewritten from scratch as builtin-APEs:
  • 🥵 Performance is generally the same as the official build, but can be a bit slower for some effects. A few effects have gained faster SSE3-enabled versions.
  • 🧨 APE files are crashing AVS or preventing it from starting. Rename or remove .ape files for now.

The Future

  • 🪓 Separate Windows UI code from the renderer
  • 📟 Standalone port (probably SDL2-based)
  • 🐧 Linux port
  • ✅ Automated output testing
  • 💾 JSON file format support

These are near-future goals, and most are tracked on the issues board. For further development of AVS itself there are many ideas for improvement and known bugs. Have a look at wishlist.txt for a list of issues and feature-requests, both old and new.

Building & Running on Linux

Build

First, install a 32bit MingW-w64 GCC (with C++ support) and and a cross-compiler CMake.

Choose your Linux distro, and run the respective commands to install the build dependencies and cross-compile AVS:

Archlinux / Manjaro
sudo pacman -S --needed mingw-w64-gcc mingw-w64-cmake
mkdir -p build
cd build
i686-w64-mingw32-cmake ..
make
Fedora / RedHat
sudo dnf install mingw32-gcc-c++ mingw32-gcc
mkdir -p build
cd build
mingw32-cmake ..
make
Debian / Ubuntu (& other distros)
sudo apt install gcc-mingw-w64 g++-mingw-w64 cmake
mkdir -p build
cd build

# Debian- and Ubuntu-based distros don't provide ready-made cross-compiling CMake
# packages, so you'll have to tell CMake about your toolchain.
cmake -D CMAKE_TOOLCHAIN_FILE=../CMake-MingWcross-toolchain.txt ..

make

Run With Winamp

Once you've compiled vis_avs.dll, copy it (and some stdlib DLLs that got introduced by MinGW) to the Winamp/Plugins folder and run it with Wine:

cp vis_avs.dll /my/path/to/Winamp/Plugins/

# Not all of these might exist on your system, that's okay, you can ignore errors for
# some of the files.
# You only need to copy these files once, they don't change.
cp /usr/i686-w64-mingw32/bin/lib{gcc_s_dw2-1,ssp-0,stdc++-6,winpthread-1}.dll /my/path/to/Winamp/

# Run Winamp
wine /my/path/to/Winamp/winamp.exe

Building & Running on Windows

Build

Open the folder with Visual Studio, it should automatically detect the CMake configurations.

If you don't want to do this, there are some caveats to using CMake itself directly:

  • Use -DCMAKE_GENERATOR_PLATFORM=Win32 to get a 32-bit project. Nothing builds under 64-bit with the MS compiler due to __asm blocks (yet).
  • CMake doesn't rebuild the project very well if you don't clean out the generated files first. Visual Studio handles this for you.
  • Using the CMake GUI is not recommended.

Run With Winamp

If you properly installed Winamp2 with the installer the project import should pickup the installation location for you and will copy the output vis_avs.dll into the Winamp/Plugins directory for you. You can then:

  • Start Winamp
  • Debug > Attach to process (Ctrl+Alt+P), search for "winamp"
  • Launch AVS by double-clicking the small oscilloscope/spectrum vis on the left of Winamp's main window

Conventions

If going through the code reveals areas of possible improvements, mark them with a TODO comment, possibly using a secondary flag to categorize the suggestion:

tag intent
// TODO [cleanup]: <comment> cleaner or more readable code is possible here
// TODO [bugfix]: <comment> more stable or less buggy code is possible here
// TODO [performance]: <comment> the performance of AVS could be better here
// TODO [feature]: <comment> a new capability of AVS could be implemented here

Notes

Thanks to Warrior of the Light for assembling the source from various edits and patch versions that floated around soon after the code publication.

License

BSD-3, see LICENSE.TXT.

vis_avs's People

Contributors

dependabot[bot] avatar exo-cortex avatar grandchild avatar hartwork avatar idleberg avatar semiessessi avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

vis_avs's Issues

JSON file format support

Support an alternative file format (potentially replacing the old binary format) that's plaintext, like the one from webvsc.

Customizable, environment-aware shortcuts

A future version of AVS should have more customizable global shortcuts and, more importantly, they should be documented somewhere in the UI. The following were hidden in the changelog of an alpha version of Winamp 2.0:

Hotkeys for main window:

  • Any winamp key
  • R toggles randomswitching
  • F toggles fullscreen framerate counter
  • Y and U cycle through presets in order
  • Space goes to random preset
  • Enter toggles fullscreen
  • 0,1-9, F1-F10 load presets
  • Ctrl+above save presets

Some of these defaults are not ideal since they have been chosen with QWERTY keyboards and (obviously) the Windows operating system in mind. If future versions also support other operating systems, these defaults should become environment-aware.

Environment awareness should not only take the operating system into account but also keyboard layout (maybe other localization preferences, that I can't think of at this point).

Here are two examples:

Operating system defaults

macOS already has a shortcut to toggle an application into fullscreen, so intuitively a user would want to use that rather than an application-specific shortcut. However, this special case also bears the potential for conflict. Since shortcuts should be customizable by the user, a global shortcut should not be overridable – a custom shortcut can only be an addition to the OS default.

Another oddity is the shortcut to save presets, which I haven't even been aware of. It's beyond me why one would not use the system default (e.g. Ctrl+S?)

Keyboard layout

The shortcuts to change to the next or previous preset is somewhat problematic on non-QWERTY layouts. The defaults Y (previous) and U (next) have clearly been chosen because in a QWERTY layout, they sit next to each other. Personally, I don't find this choice very intuitive. Other shortcuts such as toggling random switching (R), and toggle FPS counter (F) are easy to remember for their mnemonics (for English speakers anyway). IMHO it would be far more intuitive to use the cursor keys to switch presets, possibly ”protected” by a modifier key.

PS: Media-keys are no option, since they are used by Winamp itself.


Lastly, such information should be documented in the interface. Ideally in a dedicated view, but also equivalent menus. For example, the context-menu has a "fullscreen" entry, but doesn't hint at the available shortcut.

PS: I'm aware, that some of these issues don't affect the future version of AVS itself, but its individual frontends outside of Winamp.

GlobalVariables APE support

  • Find source code or
  • Implement from scratch
    • Insertion of global variables into NSEEL vars section
    • File load support

ARM 64 port

It'd be lovely to run AVS on a RaspberryPi with a small monitor somewhere.

Realizing this would require translating all Intel-specific code to generic C or even getting into ARM Neon.

It's a lofty goal, but maybe?

Linux port

  • Make all DirectDraw code optional.
  • Create a compat GUI for Linux (probably GTK3, or GTK4, via Glade, because that's what I know already)

Texer APE support

  • Source code is not available
  • Implement from scratch
    • Maybe take a hint or two from TexerII (bitmap loading, etc.)

Standalone port

Currently only runs as a Winamp plugin. It depends on Winamp for audio signal input.

Winamp provides:

  • 576 samples of both waveform and spectrogram data each frame. Write a wrapper that exposes a sound input device to route arbitrary programs' output into.
  • Currently-playing song time and length (for gettime(1) and gettime(2) respectively). This will be harder to emulate flexibly.

For a standalone port all effects have to be ported by hand (and some script) to the new Editor-API.

Effect-porting progress:

  • Scatter (1)
  • Water (1)
  • Invert (1)
  • Normalise (1)
  • FyrewurX (1)
  • Fluid (???)
  • SVP (1)
  • Rotating Stars (1)
  • Comment (1)
  • Fast Brightness (1)
  • Framerate Limiter (1)
  • Triangle (1)
  • Multiplier (1)
  • Color Reduction (1)
  • AVI Player (1)
  • FadeOut (2)
  • Blur (2)
  • Color Modifier (2)
  • Channel Shift (2)
  • Video Delay (2)
  • Add Borders (2)
  • Multi Filter (2)
  • On Beat Clear (3)
  • Grain (3)
  • Clear Screen (3)
  • Dynamic Distance Modifier (3)
  • Unique Tone (3)
  • Set Render Mode (3)
  • Dynamic Shift (3)
  • Buffer Blend (3)
  • Color Clip (4)
  • Buffer Save (4)
  • AVI (4)
  • Custom BPM (4)
  • Timescope (4)
  • AVS Trans Automation (4)
  • Texer (4)
  • MIDI Trace (4)
  • Simple (5)
  • Oscilloscope Star (5)
  • Blitter Feedback (5)
  • Bass Spin (5)
  • Ring (5)
  • Dot Grid (5)
  • Mosaic (5)
  • Super Scope (5)
  • Texer II (5)
  • Global Variables (5)
  • Moving Particle (6)
  • Picture (6)
  • Convolution Filter (6)
  • Dot Plane (7)
  • Movement (7)
  • Dot Fountain (7)
  • Mirror (7)
  • Starfield (7)
  • Water Bump (7)
  • Color Map (7)
  • Picture II (7)
  • Roto Blitter (8)
  • Colorfade (8)
  • Brightness (8)
  • Interleave (8)
  • Bump (9)
  • Dynamic Movement (9)
  • Interferences (11)
  • Effect List (14)
  • Multi Delay (14)
  • Particle System (19)
  • Text (23)

(In parenthesis the number of parameters for the effect, i.e. approximate difficulty to port. Striked-through effects aren't available in AVS currently.)

Direct archive file support

Presets in archive files shouldn't have to be extracted. AVS should be able to load them directly. Possibly it should be viewed like a directory or like a "playlist".

64bit port

At least the NSEEL code execution bits need 64bit assembler porting. The rest of the asm (mostly effects and r_defs.cpp) should preferably be translated into equally fast (or faster) C++ code first.

There's probably a thousand places where releasing a 64bit GCC onto the code will break it...

How to build in MSYS2+MinGW on Windows host?

I have a media-autobuild suite installed, that is an MSYS2 (msys64) environment with both MinGW32 and MinGW64 cross-compilation subsystems available to compile ffmpeg and a variety of linked modules with GCC 12 or Clang, which keeps itself up to date automatically.

This also supports an interactive mintty shell for either MinGW32 or MinGW64. I believe I should be able to unpack a source archive of your project, or pull it from your git repository, and then use either configure/make or CMake in MinGW32 to prepare and run the compilation.

Could you please add build instructions for MSYS2 in Windows to your front page if you already support this workflow with a matching CMake generator? I guess it would look like in x265: cmake -G "MSYS Makefiles" etc.

And a fully static DLL output would be optimal, if the project structure allows it.

NaN result possible in EEL code

Unconed (Final Whack) - VJ Chmutov has artifacts around the edges, visible in the alpha value. The k value is NaN there. This doesn't happen in the original.

Investigate what values & operations make this happen. Maybe it's floating point underflow?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.