Home

This stub-page is a list of ideas for Project M's next-generation visualizer. Every-one with a Git Hub account is able and welcome to edit it!

For now, this page will be used to collect and organize pre-liminar ideas instead of pull-requests or proof-of-concept code.

Technical discussion

While highly successful on its own merits, Project M has not seen wide-spread adoption as an embedded visualizer in music-players (even open-source ones to which anyone could contribute the integration). Clementine and Straw Berry are two players that have struggled to maintain support for Project M [1] [2]. The stand-alone Steam version is very out-dated [3]. A next-generation Project M should strive to excel where the current project has failed, as integration with popular audio players is the best way to promote the world-class work of any Project M's developers and visualization-artists.
Project M is currently written in C++. Rust is the world's most-admired language today [4] and its creator described it as a C++ alternative [5]. As such, it seems that any next-generation of an older C++ project should include a due-diligence discussion and analysis of Rust as its potential new language. Since Rust is both a high-quality and an extremely popular language, it could also help in attracting more programmers to collaborate with development.
- Further discussion https://github.com/projectM-visualizer/visualizer-ng-ideas/discussions/3
An independent audio-analyzer https://github.com/projectM-visualizer/visualizer-ng-ideas/discussions/2

Use JSON, YAML or another common text-based format for its familiarity, interoperability and support.
Bundling of preset resources, e.g. textures, meshes etc.

(Currently empty).

(Currently empty).

While directly supporting .milk and .milk2 file-formats is likely to be counter-productive in terms of the development- and maintenance-effort, a conversion utility from those formats to the next-generation Project M file-format would be greatly beneficial in porting a very-large-number of pre-existing visualizations compared to having to rebuild decades-worth of visualization-artists' effort to achieve the same. While being able to automatically convert every and any file automatically isn't necessary or realistic, identifying an ideal sub-set of features needed to convert a large number of scripts could be an attainable goal without making this utility a large project of its owe.

Interactive elements would be an interesting novel feature not seen previously in Project M or Milk Drop. With Java Script, Python and Lua being ubiquitously used as integrated scripting languages, the possibility of turning Project M as a base for creative developers to work from could be an interesting feature to consider. The possibilities range anywhere from live-interactions; mini-games; streaming; to art-exhibits...
A built-in or stand-alone visualization editor with live-rendering as you change the visualization.
- A utility that is able to generate random visualizations based on a simple template (or using a pre-existing visualization as template) and then randomizing effects and parameters could be a fun way for artists to explore unusual ideas and to get a crude base to work from without having to start from zero. This could be achieved by using effects from the existing visualization library (including potential ones converted from Milk-drop) as building blocks. This could be an external script, which an editor command could call if the system has an interpreter installed.
Support for 3D scenes

A recurring "visualization of the month" coopetition would be a fun way to keep the community vibrant; reward visualization-artists; promote their work; and to deliver new visualizations to users. For several reasons, this would be better handled by community members on side-channels (such as You Tube or Discord), rather than as part of the official project but it can still be discussed as a valuable goal.

Support for skins could be interesting, similarly to another Llama-based music player. Minimal skin support could be implemented then expanded if user-demand exists. This depends, of course on how much interface would even be shown (especially when embedded) as it might not be worth it if fairly minimal.