Why Nannou?

nannou is a collection of code aimed at making it easy for artists to express themselves with simple, fast, reliable, portable code. Whether working on a 12-month installation or a 5 minute sketch, this framework aims to give artists easy access to the tools they need.

The project was started out of a desire for a creative coding framework inspired by Processing, OpenFrameworks and Cinder, but for Rust. Named after this.

Goals

Nannou aims to provide easy, cross-platform access to the things that artists need:

  • Windowing & Events via winit.
  • Audio via CPAL. Input and output streams. Duplex are not yet supported.
  • Video input, playback and processing (would love suggestions and ideas).
  • GUI via egui. May switch to a custom nannou solution in the future.
  • Geometry with functions and iterators for producing vertices and indices:
    • 1D - Scalar, Range.
    • 2D - Path, Polyline, Polygon, Rect, Line, Ellipse, Quad, Tri.
    • 3D - Cuboid.
    • 3D TODO - Ellipsoid, Cube, Prisms, Pyramids, *Hedrons, Camera, etc.
    • Vertex & index iterators.
    • Graph for composing geometry.
  • Graphics via WGPU (via wgpu-rs):
  • Protocols:
    • OSC - Open Sound Control.
    • ISF - Interactive Shader Format.
    • CITP - Controller Interface Transport Protocol (network implementation is in progress).
    • Ether-Dream Laser DAC protocol and network implementation.
    • DMX via sACN - commonly used for lighting and effects.
    • Serial - commonly used for interfacing with LEDs and other hardware.
    • MIDI - No friendly nannou API is provided yet, but cross-platform MIDI I/O is possible via midir.
    • UDP via std.
    • TCP streams and listeners via std.
  • Device & I/O stream APIs:
    • Windowing.
    • Application events.
    • Audio.
    • Video.
    • Lasers.
    • Lights. For now, we recommend DMX via the sacn crate.
    • LEDs. For now, we recommend DMX via the sacn crate.
  • Graphical Node Graph via gantz.
  • GUI Editor.

Nannou aims to use only pure-rust libraries. As a new user you should require nothing more than cargo build to get going. Falling back to C-bindings will be considered as a temporary solution in the case that there are no Rust alternatives yet in development. We prefer to drive forward development of less mature rust-alternatives than depend on bindings to C code. This should make it easier for nannou users to become nannou contributors as they do not have to learn a second language in order to contribute upstream.

Nannou will not contain unsafe code with the exception of bindings to operating systems or hardware APIs if necessary.

Nannou wishes to remove the need to decide between lots of different backends that provide access to the same hardware. Instead, we want to focus on a specific set of backends and make sure that they work well.

Why Rust?

Rust is a language that is both highly expressive and blazingly fast. Here are some of the reasons why we choose to use it:

  • Super fast, as in C and C++ fast.
  • A standard package manager that makes it very easy to handle dependencies and share your own projects in seconds.
  • Highly portable. Easily build for MacOS, Linux, Windows, Android, iOS and so many others.
  • No header files and no weird linking errors.
  • Sum Types and Pattern Matching and no NULL.
  • Local type inference. Only write types where it matters, no need to repeat yourself.
  • A more modern, ƒunctional and expressive style.
  • Memory safe and data-race-free! Get your ideas down without the fear of creating pointer spaghetti or segfault time-sinks.
  • Immutability by default. Easily distinguish between variables that can change and those that can't at a glance.
  • Module system resulting in very clean and concise name spaces.
  • One of the kindest internet communities we've come across. Please visit mozilla's #rust or /r/rust if you're starting out and need any pointers.

Why the Apache/MIT dual licensing?

For the most part, nannou is trying to maintain as much flexibility and compatibility with the licensing of Rust itself, which is also dual licensed.

The Apache 2.0 and MIT license are very similar, but have a few key differences. Using the Apache 2.0 license for contributions triggers the Apache 2.0 patent grant. This grant is designed to protect against leveraging the patent law system to bypass (some) terms of the license. If the contribution is under the Apache 2.0 license, the contributor assures that they will not claim a violation of (their own) patents. If someone makes a work based on Apache 2.0 licensed code, they in turn also vow to not sue their users (for patent infringement). The MIT license provides compatibility with a lot of other FLOSS licenses.

Further reading: