Nannou – A Creative Coding Framework for Rust(nannou.cc)
nannou.cc
Nannou – A Creative Coding Framework for Rust
https://nannou.cc/
25 comments
This could be a cool way to get into Rust.
I remember what processing did for my overall understanding of writing code, so this might make me familiar with Rust in the same way.
If you're looking for projects that you find interesting, as a mean to learn Rust, you may also find interesting The Ray Tracer Challenge and Mazes for Programmers.
There are also application-based books (rather than "concept-based"), like Rust Programming by Example, and the upcoming Hands-on Rust. Also, a notable app-based tutorial is "Build your own JIRA with Rust" (I didn't try it, though).
There are also application-based books (rather than "concept-based"), like Rust Programming by Example, and the upcoming Hands-on Rust. Also, a notable app-based tutorial is "Build your own JIRA with Rust" (I didn't try it, though).
Nannou is great! I tried it and found that:
1. The initial setup and build time is perhaps a little long or complex for use in classrooms/workshops but it's fine for personal/professional use.
2. Rust's build time might not feel like a natural fit for creative coding. Even though initial build times are long (~3 minutes on an 8-core 2019 MBP), rebuilds are fast enough to create a short feedback loop. It's not as fluid as dynamic languages like Clojure/JavaScript, but it's good enough.
3. It's a nice way to learn Rust.
4. MacTuiTui is worth following for their Nannou sketches: https://www.instagram.com/mactuitui/
1. The initial setup and build time is perhaps a little long or complex for use in classrooms/workshops but it's fine for personal/professional use.
2. Rust's build time might not feel like a natural fit for creative coding. Even though initial build times are long (~3 minutes on an 8-core 2019 MBP), rebuilds are fast enough to create a short feedback loop. It's not as fluid as dynamic languages like Clojure/JavaScript, but it's good enough.
3. It's a nice way to learn Rust.
4. MacTuiTui is worth following for their Nannou sketches: https://www.instagram.com/mactuitui/
So I noticed that video input is notably unchecked on the current list of features[0]. Looking back at all the hassle that it has always been in Processing and OpenFrameworks (p5.js is lucky to have a browser do the heavy lifting here) this doesn't surprise me, so kudos to Nannou for taking the time to try and figure this out properly.
Still, do you have any idea on what the progress is in that department?
Does the Rust ecosystem provide specific alternatives for individual set-ups? For example, in my case I only care about video capture for Linux. I see that there is a v4l crate out there, as well as something for ffmpeg[1][2]. Is that easy to combine with Nannou? I have zero experience with Rust but if this is not too much hassle I might give it a shot.
[0] https://guide.nannou.cc/why_nannou.html#goals
[1] https://crates.io/crates/v4l
[2] https://crates.io/crates/ffmpeg-next
Still, do you have any idea on what the progress is in that department?
Does the Rust ecosystem provide specific alternatives for individual set-ups? For example, in my case I only care about video capture for Linux. I see that there is a v4l crate out there, as well as something for ffmpeg[1][2]. Is that easy to combine with Nannou? I have zero experience with Rust but if this is not too much hassle I might give it a shot.
[0] https://guide.nannou.cc/why_nannou.html#goals
[1] https://crates.io/crates/v4l
[2] https://crates.io/crates/ffmpeg-next
I haven’t dabbled with video input, but you could try asking the community in their Matrix chatrooms: https://matrix.to/#/+nannou:matrix.org
I was wondering why the sudden spike in followers...
I'm also on https://twitter.com/MacTuitui if you prefer.
As for the direct points (note that I am _not_ part of nannou's team, just one _heavy_ user):
1. That's sadly true, it's been a long time issue (not only nannou's problem to be fair, it's shared by all rust projects at the moment): https://github.com/nannou-org/nannou/issues/178
2. If you were following my talk at GitHub universe yesterday where I was livecoding (archive will be up "soon"), the rebuilds are fast enough I don't really care (simple stuff are <3s for me, even my latest dailies where I have heaps of extra stuff are averaging <6s rebuild time). The compiler (via lsp) catches most bugs beforehand, so I would say it is not very much an issue at this point. Using a cargo cache will make things far easier as well.
3. Exactly why I started using nannou (coming from using processing via scala)!
As for the "why nannou?", and sorry for being nerdy, but nannou is the only framework I know of that does color right: you are working "naturally" in LinSrgb with float16 precision per channel (if that does not speak to you, just look for gamma correction and go down the rabbit hole). The blending of color is exceptional if you're into that sort of things (I am: see for example in HQ https://superrare.co/artwork-v2/road-to-nowhere-12621 )
Nannou is also focused towards the future: there's been a couple of major backend rewrites from opengl to vulkan then webgpu (without any issues for the end-user if you were using the core nannou api functions): you get to play with the latest toys and finally you get access to your whole GPU. No need to stay in a OpenGL-centric state based workflow (that does not make any sense since years)! I've been able to run crazy compute shaders passes while making my own render pipelines _on top of what nannou does_. It's crazy powerful. Also I have to say the team behind nannou has been wonderful in dealing with my requests over the last two years, and they always provided help when I needed (to be honest, I chose nannou because the team was in Australia, and as I am in Japan, it made communication easy). Huge thanks to them. Have a look at the github issues to see how nice the team is.
And with cargo, I'm confident (not very confident, mind you, but optimistically confident) that I'll be able to get the thing building again in a few years.
So if your interest peaked a bit, please try it, if you have any questions, join the matrix chat and ask away!
As for the direct points (note that I am _not_ part of nannou's team, just one _heavy_ user):
1. That's sadly true, it's been a long time issue (not only nannou's problem to be fair, it's shared by all rust projects at the moment): https://github.com/nannou-org/nannou/issues/178
2. If you were following my talk at GitHub universe yesterday where I was livecoding (archive will be up "soon"), the rebuilds are fast enough I don't really care (simple stuff are <3s for me, even my latest dailies where I have heaps of extra stuff are averaging <6s rebuild time). The compiler (via lsp) catches most bugs beforehand, so I would say it is not very much an issue at this point. Using a cargo cache will make things far easier as well.
3. Exactly why I started using nannou (coming from using processing via scala)!
As for the "why nannou?", and sorry for being nerdy, but nannou is the only framework I know of that does color right: you are working "naturally" in LinSrgb with float16 precision per channel (if that does not speak to you, just look for gamma correction and go down the rabbit hole). The blending of color is exceptional if you're into that sort of things (I am: see for example in HQ https://superrare.co/artwork-v2/road-to-nowhere-12621 )
Nannou is also focused towards the future: there's been a couple of major backend rewrites from opengl to vulkan then webgpu (without any issues for the end-user if you were using the core nannou api functions): you get to play with the latest toys and finally you get access to your whole GPU. No need to stay in a OpenGL-centric state based workflow (that does not make any sense since years)! I've been able to run crazy compute shaders passes while making my own render pipelines _on top of what nannou does_. It's crazy powerful. Also I have to say the team behind nannou has been wonderful in dealing with my requests over the last two years, and they always provided help when I needed (to be honest, I chose nannou because the team was in Australia, and as I am in Japan, it made communication easy). Huge thanks to them. Have a look at the github issues to see how nice the team is.
And with cargo, I'm confident (not very confident, mind you, but optimistically confident) that I'll be able to get the thing building again in a few years.
So if your interest peaked a bit, please try it, if you have any questions, join the matrix chat and ask away!
Thank you for the extra insights!
I can live with the short rebuild times for the performance of Rust. Does Rust have a watch command to auto-rebuild sketches when files are changed? Last time I used Nannou it did not.
I look forward to checking out your GitHub Universe talk when the video’s live. (Guessing it’s this one? https://githubuniverse.com/Nannou-creative-coding-with-Rust/ )
I can live with the short rebuild times for the performance of Rust. Does Rust have a watch command to auto-rebuild sketches when files are changed? Last time I used Nannou it did not.
I look forward to checking out your GitHub Universe talk when the video’s live. (Guessing it’s this one? https://githubuniverse.com/Nannou-creative-coding-with-Rust/ )
$ cargo install cargo-watch
$ cargo watch
The build times are definitely an issue when comparing against something like Cinder in Visual C++.
I'd love to use this to learn Rust, and the API looks awesome (loved the Rect::below), but indeed the iteration loop is key for me when doing creative coding. I even built a couple of things [1][2] to get it as fast as possible in P5.
[1] https://marketplace.visualstudio.com/items?itemName=filipesa...
[2] https://github.com/filipesabella/ProcessingP5
[1] https://marketplace.visualstudio.com/items?itemName=filipesa...
[2] https://github.com/filipesabella/ProcessingP5
I agree that fast feedback loops are important.
There are some experiments with hot-reloading workflows in Rust:
https://fasterthanli.me/articles/so-you-want-to-live-reload-...
https://github.com/irh/rust-hot-reloading
https://github.com/porglezomp-misc/live-reloading-rs
It would be interesting to get this working with Nannou.
There are some experiments with hot-reloading workflows in Rust:
https://fasterthanli.me/articles/so-you-want-to-live-reload-...
https://github.com/irh/rust-hot-reloading
https://github.com/porglezomp-misc/live-reloading-rs
It would be interesting to get this working with Nannou.
Appart for #3, what's the draw here? Is there any tangible benefit to this versus using Processing or OpenFrameworks?
Edit: Read through their doc, it seems the benefits over Processing is performance, and Nannou targets realtime audio/video which is where Processing performance can start to be too sluggish. And OpenFrameworks being C++ means less reliable to live performance piece, where you wouldn't want a segfault or memory race to show up, as well as just Rust can be said to be a nicer language, if you prefer its style.
Edit: Read through their doc, it seems the benefits over Processing is performance, and Nannou targets realtime audio/video which is where Processing performance can start to be too sluggish. And OpenFrameworks being C++ means less reliable to live performance piece, where you wouldn't want a segfault or memory race to show up, as well as just Rust can be said to be a nicer language, if you prefer its style.
The show can still be brought to an halt due to bugs in libraries using unsafe code, or array bounds access error.
I found it funny you mention Clojure since leiningen takes 20 seconds to get to a REPL prompt on a full spec MBP 16 from last year. For all the hype about interactive development, I think Clojure people are deluding themselves if they think that’s reasonable for a dynamic language.
I agree with the sentiment and I don’t use Clojure as much as I did, partly for that reason.
I do recall Clojure/Quil being faster than Rust/Nannou in terms of the feedback loop, because once you’re running a REPL and you start to change and tweak things you can re-evaluate them live in the context of the running sketch.
Neither offers as fast a feedback loop as JS/P5.js, though, and for me Quokka gives much of the benefit of Clojure’s REPL but with less setup, faster boot, and consistency between editors.
I do recall Clojure/Quil being faster than Rust/Nannou in terms of the feedback loop, because once you’re running a REPL and you start to change and tweak things you can re-evaluate them live in the context of the running sketch.
Neither offers as fast a feedback loop as JS/P5.js, though, and for me Quokka gives much of the benefit of Clojure’s REPL but with less setup, faster boot, and consistency between editors.
It takes a couple seconds on my 2013 MacBook Air. You must have been downloading libraries if you had to wait 20 seconds on a beefy MPB. Once the JVM has started up, reloading code is very very fast. No need to completely restart the REPL unless you need to add a dependency. Also clojure has its own built in CLI now that is fully capable of replacing leiningen on every front. Now to start a repl you just need the `clj` command
Are you restarting the REPL on every change??
Why would need to keep restarting the REPL?
Borrow checking, generics (dynamics) and lifetimes could be tricky to explain to beginners.
I recently wrote myself a software renderer in rust to learn the ropes and had a pretty big initial hill to climb.
I recently wrote myself a software renderer in rust to learn the ropes and had a pretty big initial hill to climb.
For sketches, I find that in practice I tend not to bump up against the borrow checker at all. Here’s a thread of sketches (all with code) that I wrote when I was experimenting with nannou; explicit lifetimes are nowhere to be seen.
https://twitter.com/paulgb/status/1248698789839454214?s=21
https://twitter.com/paulgb/status/1248698789839454214?s=21
Unrelated to the project, Nannou is also a beautiful Aphex Twin track (one of my personal favourites) and highly recommended:
https://www.youtube.com/watch?v=A-Pkx37kYf4
Video sfw. Comments likely less so.
https://www.youtube.com/watch?v=A-Pkx37kYf4
Video sfw. Comments likely less so.
Co-creator of nannou here, the project is indeed named after this track :)
I had looked at Nannou less than a year ago. It looks like it is really progressing nicely! This may be my seque into learning Rust.
I was also looking at using NAP [1] for creative coding. At the moment, I am playing with Raylib [2], a C game engine, but with lots of libraries to make some graphics with music. You can use any C library for audio creative coding.
[1] https://www.napframework.com/
[2] https://www.raylib.com/
I was also looking at using NAP [1] for creative coding. At the moment, I am playing with Raylib [2], a C game engine, but with lots of libraries to make some graphics with music. You can use any C library for audio creative coding.
[1] https://www.napframework.com/
[2] https://www.raylib.com/
Sorry for the noob question, but what is Creative Coding?
It is probably not the best term, but I'd say it is the term that caught on to describe the use of coding where artistic expression is the main intent. I think the wikipedia entry[1] is pretty accurate with respect to how it is used colloquially.
[1]: https://en.wikipedia.org/wiki/Creative_coding
[1]: https://en.wikipedia.org/wiki/Creative_coding