I would suggest checking their github repo[1] and seeing the examples from the book “nature of code” they are astonishing with a shitload of them ! Same with “generative design”
Nannou talks about control of lasers, what would be a way to learn and get a cheap version of a laser beam I could use at home? Or maybe can I use that to control some light projections? I'm not interested in a full projector aimed at a while wall but was more wondering if I could somehow project some satellite movement on my living room walls and ceiling. I remember in Amsterdam there are some "immersive" light shows in Micropia where you see bacteria floating around and in the floor. Also shameless plug, I bridged Alacritty with Nannou so that one can use nannou primitives as alacritty "background" with animations https://github.com/sebosp/chartacritty
In my limited experience a lot of programmable lighting rigs are communicated with via DMX messages over the ArtNet protocol. Essentially you send UDP messages over a network. I wouldn't know a specific affordable laser rig to recommend but you can look for DMX lasers as a starting point.
Rust is one of the more frustrating languages to dabble in. Usability is explicitly not a top priority. I can't imagine suggesting a rust based project to someone who wasn't already a fairly proficient coder.
We might have different definitions of "usability." Tooling, package management, compiler messages, language documentation. Those are some of the things I think of when I hear "usability" - and those are all top notch. Were you thinking of the learning curve, or did you have issues with some of the above?
I was expecting it to be like P5 but worse (why would you use Rust for that kind of coding?? do I actually care about memory safety in my sketches?) Shockingly the code looks totally reasonable! Im very impressed.
I guess there is a lot of copy happening under the hood (cf the source for Draw) but the result is a very straightforward syntax. I might give it a try instead of going back to P5.
I’m just a hobbyist developer, and I really don’t need Rust’s safety or even speed for anything I do. I don’t even need a compiled executable. Instead I keep coming back to it because of the language itself. Its particular flavor of the type system, traits, generics, error handling, and syntax I just love. It just seems so well thought out and any time I’m using any other language I find myself missing many of Rust’s features.
As someone who’s generally pretty scatter-brained I really love the strictness of Rust.
I'm not referring to the challenge of coding with this style. I am referring to actual trade offs.
It increases safety at the expense of modularity and expressivity by a huge amount. The trap door to get around it, is to implement the copy trait, but the point of rust is to minimize this action as much as possible for speed.
Well, I don’t use Rust for memory safety alone. That would be pretty reductive. I like the language, the syntax and all the cool math crates that I’m used to from other projects.
> why would you use Rust for that kind of coding??
Why people keep asking that? Rust is a very good language even if you don't care about safety at all and barely care about the speed. Value semantics gives you completely unique capabilities when working with complex objects. It fits all applications.
Rust supports copy-on-write, so the amount of copies can probably be kept quite low with no real impact on surface syntax. Anyway, the case for Rust is that it combines memory safety and performance. JavaScript is memory safe enough, but creative coding can be quite demanding from a performance POV.
This seems promising! The creative coding folks I know mostly use WebGL which is obviously a way, way less user friendly syntax, though the tooling itself is much simpler and available. I’ll also note that the majority of the “best” creative coders I’ve met (biggest online following, largest shows) were not SWEs and generally didn’t code much outside of their preferred creative environment.
All that to say that the other commenters are right, and that what is trivial to us (build and run a rust project) is a multi day affair for the technical non-programmer.
I wonder if the author would consider shipping a desktop app with a preview window, simple text editor, and play button. All the pieces are obviously there, it’s just be a bit of a pain in the ass supporting three platforms and certainly less fun that working on the library itself :)
This seems cool! Would be neat to have some kind of feature/performance comparison with processing, which I'd guess is the introduction to creative coding for a lot of people.
Surprised to see this kind of project in Rust but it looks interesting.
Cannot resist plugging a Nim wrapper for p5js (although it’s a bit early stage), in case other are interested in doing p5/processing stuff in a niche but fun (and easy to pick up) language: https://github.com/pietroppeter/p5nim
For those who are starting to learn creative coding from p5js/Processing like me, this framework can appear quite challenging. P5js and Processing are designed to smooth the learning curve of programming for designers and artists without a CS background. Nannou looks more like it's designed for those who already have experience in creative coding but are looking to achieve higher performance with their sketches.
It's worth taking a look at OPENRNDR, which is a framework based on Kotlin. Personally, I think it achieves a good balance between performance and accessibility.
OpenFrameworks[0] is quite popular for creative coding even though it's written in C++ - framework is actually pleasant to use. If you want to do some creative coding on both iOS and Android you don't have many options. If you want to use sensors (cameras, microphones, gyroscope, accelerometer, etc) and e.g. process video stream at 120fps you have even less choices.
Sadly OpenFrameworks development seems kind of stalled. Nannou + Rust could be a good or even better alternative:
1) painless cross-compilation to different platforms
2) plugins installation via cargo
3) more up-to-date plugins as tiny wrappers around CPAL [1] (audio I/O), nokhwa [2] (video i/o), opencv-rust[3] (video I/O and processing), rust-sdl2 [4](IMU sensors + game controllers), egui [5] (immediate mode gui + plotting)
Nanou still has quite a bit to catch up with openFrameworks API surface though.
Also those "plugins" are kind of limited to compile time, not really what plugin infrastructure is about. Nothing that can be dynamically loaded into an existing installation.
At very least I would expect something like DAWs or COM make available.
The quick run speed is great for shortening the feedback loop. I've had great experiences with Lisp-style environments for that reason, and the language is much higher level than Rust while still offering good performance. I've mainly used Quil, the Clojure wrapper around processing: https://github.com/quil/quil
I'm surprised that this feels more verbose than libcinder, which already pushes beyond a lot of creative coder skill sets. I wonder if it does need another pass getting a DSL together or some abstraction toolkit to get it marrying up closer to the processing experience.
I did. although simpler languages like Python and JS were easier to get your ideas on the screen quickly, they are too resource intensive. Large and complicated pieces become too slow to work on as time goes on, and you have to either get better hardware or use a faster language such as Rust.
Yeah, I don't want to dismiss this project out of principle, because it's cool! But I'd still recommend software like Touch Designer, or Notch (or some free alternative) for creative people. Fleshed out IDEs with both code and visual editors (and preferably with good support for a ton of peripherals).
Try creating some of the more complex examples from "nature of code" in a node-based environment.
The networks you get are huge. And understanding them, after a month e.g., becomes tedious at best.
The creation may seem more artist friendly but understanding/modifying are very much less so when a certain complexity threshold is reached.
Code is simply easier to read when you reach that aforementioned threshold.
Writing code is also a different experience than using a node-based editor but that's more philosophical than pertaining to what is better when.
My experience is mostly with Houdini in VFX.
Whenever I have to touch a complex node graph, my own after a while, or someone else's -- the more nodes just containing plain VEX or Python code are in there, the easier it is usually to understand (vs someone making a sub network with another 30 nodes for what could be expressed with 10 lines of VEX).
As a programmer and visual thinker, I always wish there was some kind of hybrid approach. There's no reason standard function calls can't be visualised as nodes, while keeping each function as pure code.
Possibly it would work best in a functional language like haskell or elixir.
Visual Languages also allow to write modular code, by packing complex stuff into modules and libraries, maybe people try to stop doing everything on a single diagram.
I have creative background, always feared and never learned C++.
Maybe if one has years of OOP experience, feeling can be different, but for me, borrow checker felt straightforward.
There could be some complicate cases of trait bounds using some 3rd party libraries. However one will hardly encounter that while playing with Nannou.
The most important feature of a tool meant to support creativity is interactivity. Last time I checked, Rust didn't have a REPL, didn't support live-patching, and didn't have fast compile times - all features critical for interactivity. Has something changed since then?
Also, while cold compile times can be very slow of you have a lot of dependencies with macros etc, incremental compile time is often very fast. Rust has one of the most advanced incremental compilers out there. So for experimenting, tweaking and updating code, that's not going to have a long cycle.
Does this REPL support all of the features that traditional, batch-processed Rust does? Last time I checked, I found "REPLs" for Rust that were hacks, just putting code into a file and re-compiling and re-running the whole thing - didn't support all of the features and super slow.
> incremental compile time is often very fast
I tried Rust a few years ago and got incremental compile times in the tens of seconds for medium-sized projects, which is excruciatingly slow. Unless compile times are sub-second, it's not fast enough, unless the REPL is somehow faster.
> The most important feature of a tool meant to support creativity is interactivity.
This seems like a requirement you personally came up with that does not mesh with reality. Throughout history the greatest creative achievement have been made using absurdly difficult to use non-interactive mediums.
Also Rust compile times are not as slow as you imagine them to be.
> This seems like a requirement you personally came up with that does not mesh with reality.
No, it's actually pretty obvious, if you actually take a moment to think about it. Creativity is about making things in reality, which necessitates the construction of new things, which means that you either need to keep design details entirely in your head while you work (which is infeasible for many things and challenging for most things) or you need to work with a medium (paint, clay, code) as you create, which means that the medium (and tool) need to be interactive.
> Throughout history the greatest creative achievement have been made using absurdly difficult to use non-interactive mediums.
This is completely absurd. Most, if not all, of the classical arts have used highly interactive media. Painting? Interactive medium. Sculping? Interactive. Mechanical devices, like the steam engine and the plane? Interactive. In almost every single creative field, you get the opportunity to work with things incrementally.
Unfortunately, for historical reasons (namely their C lineage), most languages are non-interactive batch-processed monstrosities which inhibit creativity, and Rust is no exception.
> Also Rust compile times are not as slow as you imagine them to be.
I've used Rust, and the compile times are exactly what I remember them to be - tens of minutes for large programs, and tens of seconds for incremental compiles, which is tens of seconds too long.
[1] https://github.com/nannou-org/nannou/tree/master/nature_of_c...