Use your keyboard and this three step program to tame some noise using the Rust programming language.

Let’s make some noise with Rust! Yes, literal noise. Whats more poetic than starting this journey with the audio to the source of life caressing your eardrums: streams! (google translate “bekk” to discover a coincidence). We will attempt to take some control and tame the noise with keyboard input, using some digital audio signal processing. Disclaimer: This is written by a Rust beginner, and may not apply all best practices.

📢 Friendly advice: Although the software presented here is safe for your ears. I will still recommend as a precaution to not use headphones/earphones (or at least always start low volume) when playing with audio in programming. I speak from experience as I vividly remember almost tearing up some eardrums 10 years ago. I was testing out the Csound programming language while cluelessly choosing numbers for scaling the output volume. In shock I almost punched myself in my face, as I lunged toward the headphones pounding damaging amplitudes of sine waves into my brain. Lesson learned; speakers that don’t go directly into your ear are safer.

Given that you have already installed the rust toolchain. Let’s start by creating the project, we may call it “noisy”.

cargo new noisy

Part 1: Output some noise from speaker

To handle playing sound from your computer we will use the cpal crate (Cross-Platform I/O Audio Library). And to simplify our way around creating (synthesizing) the noise, we utilize another powerful crate: fundsp. «FunDSP is an audio DSP (digital signal processing) library for audio processing and synthesis.» - this seems promising! Run cargo add fundsp cpal. (dasp (formerly sample) also seems to be a popular crate for audio signal processing, and may be more fitting should you need a more lightweight alternative with focus on separation of concern)

We start by setting up the stream for audio playback in main() and generate some pink noise in the run()function, that we pass on to the write_data() function. write_data() writes the audio - sample by sample - to the output stream.

Run this with cargo run and you should hear some beautiful noise from your speakers.




Part 2: Utilize keyboard input

Noise by itself may become boring after some time. Let’s take some control with the keyboard. We add the crossterm crate to parse keyboard input: cargo add crossterm. The raw mode lets the program read each character as it is typed by the user. We register this in the main function. Secondly, we create a loop in the run() function that listens for keyboard input. For this step pressing any button will play the sound, pressing escape will quit the program. We simulate playing while holding down a button by registering a tone_duration. You may change this variable to your own preference.

Try running this and pressing buttons — this should give you some more control of the wild noise.




Part 3: Make noise pretty

Alright! Now that we have some keyboard events to hook into, let’s take advantage of it. There are a couple of things added here, so let’s break it down. Firstly, we replace the pink noise with an Oscillator (borrowed from the cpal examples) to be able to dynamically change the frequencies. The oscillator generates square waves, from a given frequency. Secondly, we create our own little piano on the keyboard. Registering the keys from A-L to represent an octave from C to C (the tone). Check out the code below.




Congrats! 🎉 Now you have created your very own monophonic synthesizer (monophonic → able to play one note at a time)! Have a look at the fundsp examples for more inspiration to play around with digital signal processing. With future endeavours one could for example simplify the audio generation in this example even more by utilizing more of the tools from the mentioned crates.

Make some noise with Rust!

Don't you just hate how boring ls is? I mean, it just spits out the names of files and folders on a line, one after the other. Come on, it's not 1987 anymore.
Let's try to make our own version, using Rust! Don't know any Rust? Go ahead and read last year's Introduction to Rust first! 🦀 I'll be waiting 🥱

Let's list some files


To get started, let's just grab all the files in our current working directory and spit them back out. Let's use the excellent walkdir-crate. Let's create our project and get going, and call our project explore 🔎



And in our src/main.rs:


And run it:


Wow, that's a lot of output! It prints all build files and .git-files, but I truncated it. Let's clean that up by changing the files we're interested in, which means hiding hidden files (e.g. files that start with .) and only show one-level of depth:


Now let's run it again:


Nice! 🎉

Oh, and by the way, I'm skipping showing you all the imports, so if you're following along, just use rust-analyzer's code actions to import them automatically.


Hold for the applause 👏


Let's add the excellent command-line argument parsing library Clap and use that to parse some input arguments. We want it to figure out the parsing, so we add the feature derive as well:


To use Clap, we create a struct representing our input arguments, slap on some attributes to tell Clap how to initialize things, and change our usages so it works just the same:


And run it again to check it still works as before:


It does! And now we can also tweak the output with --max-depth, --min-depth, --hidden and --path/-p!


Awesome!

Sizable files


Now let's spice things up by adding size output to our entries! Let's look at an entry's metadata and find out:


Looks simple enough, but that printing stuff is weird. Let's break it down: {size} will print the size variable, which is in bytes. {size:>9} means to align the number right-aligned to 9 characters in width. \t adds a tab character, which aligns the next stuff somewhat nicely. And also we add a B because the size is in bytes. Let's run it:



Sweeeet! Now we're almost on par with ls.However, at some point in time, or perhaps from the beginning, ls got support for colors. We can't be any worse! Let's add some colors to differentiate directories, files and symlinks from each other. colored looks good!


And in our src/main.rs main loop:




colored adds a Colorize-trait which gives us extension methods like .blue() and friends, but it only works on strings (&str and String), so we need to convert the output of .display() to a string, using .to_string(). If you'd inspect .display(), you would see it returns a Display-type, which implements std::fmt::Display, which is why it works without converting it to a string first. But anyway, let's run it:


Sweeeeeet!! Ehh... wait.. You can't really see the colors like that.. Give me a second... Now!


Woo! It's looking a bit bland with the size missing colors, so let's spice it with some colors too:


And rerun:


Awesome! However, this beautiful new colored output highlights a problem. 9471B? It's over 9000! We should get ahead of ourselves and format large byte quantities into something more readable. Let's add bytesize and use it!


bytesize adds B, KB or whatever, so we need to remove our B from the output. Also, since we want the formatting 123 KB first, and then color it, we need to format it using format!("{}", ByteSize(size)) and then color it green, and then print it:


Rerun time:



Nice!

Putting aside the noise


Now, I don't know about you, but I'm not a super fan about it spitting out ./ as a prefix to everything, and the whole directory path for every line of the nested files.


To fix this, let's grab only the filename and extension without all the prefixing paths to each entry before printing. To avoid printing everything on a single line and not understanding which file belongs in which directory, let's indent each file by the depth it has (the number of nested directories it is in). Also, as a bonus, walkdir gives us the directory itself as a single entry first, so we automatically understand which entry belongs to which directory! Let's make it clearer by putting it into code. Let's change our main loop code for formatting entries to:


And let's compile and run, again:


Awesome! I love the dimmed bars for indentation, too. Nice touch, Isak. 😏

Time for a change


This is a pretty nice-looking CLI-tool already! Let's spice it up to ls's level by adding some date stuff. Rust has support for dates in the standard library, but doesn't support formatting them (trust me, with the amount of weird stuff going on with dates/timestamps and the stability promises of a standard library, this is really a good thing).
Let's use chrono:


We saw earlier that each entry has a .metadata() object. It returns an Option<Metadata> and we've been .unwrap()-ping it without problem until now. This object also contains a .modified()-method that gives us a Result of a SystemTime. We've been cowboying fine so far, so let's unwrap that as well and hope it exists:


Let's add an option for actually printing the date modified, because we might not always need it. In our Options-struct, add:


Onto formatting and actually using chrono. For non-serialization formats, it's pretty nice to see which day, date and time something has changed. I don't know what you like, but my favorite RFC for those types of date formats is RFC 2822, which spits out something in the likes of Mon, 13 Nov 2023 19:18:49 +0000, so we'll just use chrono to spit out that!


Let's create a formatted_date variable that checks if the modified/-m-flag is set, and returns an empty string if it isn't. If it is, it will convert our date to chrono's DateTime<Utc>, spit out the beautiful RFC 2822 output, and then strip away the ugly + 0000-suffix, because who wants that.




We'll print out our dates in blue:


Sick! 🤩


Now let's not compare ourselves with others...


I'm not gonna lie, this is pretty similar to the output of the awesome tool exa, also written in Rust. Let's compare them!


In fact, ignoring the permissions and author of the files (because who cares about those), they're mostly the same! Except our outputs files with hidden files and directories last. This is a simple fix:


And rerun one last time!


Neeat 😎

This article is probably getting a bit too long, so let's leave it at that. Adding more features such as permissions, error-handling and so on is left as an exercise to the reader (but really can be solved by running cargo add anyhow, search-and-replacing .unwrap() with .context("describe the error")? to yeet the error out of the function, assuming you changed the main function's return type to anyhow::Result<()> and return Ok(()) at the end of the function). Huh, we almost could have done all that stuff in the parenthesis, but anyhow.


Time to feed the dog


If you want to use this program as a replacement for ls, it's super easy!
Just run:


And then a bunch of output is spat out. Afterwards it should be installed in $HOME/.cargo/bin/explore ore wherever your Cargo installation is, and assuming you have that in your path (which you should have), you can run it like this now!

Conclusion


Thanks for reading! I hope you see how easy it is to create a tool of your own using Rust and its great tooling and ecosystem. And we did all of this in... how many lines? Well, the title was a lie, we actually only used 68 lines of Rust, according to the awesome written-in-Rust tool tokei


68 lines for all that functionality! And of course some more when we include the dependencies, but oh well. Pretty nice! Doesn't make for a good title, though... Perhaps "A better ls in less than 69 lines of Rust" is nicer. Is it really a better version of ls? Probably not, but that wouldn't make for a good title either.


There's plenty more that can be done if you want to create your own version. As an example, you can add:

Permissions

Author

Date created

Options for all of the above

Support for ignoring files and folders according to ignore-files (perhaps use ignore)- And so on


Happy holidays! 🦀


Rust

Make some noise with Rust!

A better `ls` in 100 lines of Rust