UNDLTD

Announcing om, a command line mounter for removable devices

Mon, 18 Nov 2024 00:00:00 +0200

I just published a new opensource project. It is a small program I wrote to solve an inconvenience I experienced with my computer use:

Mounting & unmounting removable devices from command line (on Linux).

Here’s an example of using om to mount a recently attached device:

$ om
Activate device:

1) /dev/sda1                 My USB                  (12.5G)
2) /dev/mmcblk0              My memory card          (116.5G)

Device [1]: ⏎

/dev/sda1: mounted at `/run/media/user/My USB`.

Most of the time, in order to mount a device, one only needs to type the short command and hit Return. Unmounting is analogously simple.

See README for more examples, including encrypted devices and powering off.

Motivation

Whatever DE I use, I tend to work mostly with the keyboard. So I wanted a short command that would do this for me with as little typing and interaction as possible.

That includes mounting / unmounting at the right place, unlocking / locking encrypted volumes, as well as doing anything necessary to safely remove the device (powering off when supported, locking encrypted volumes after unmount, unmounting other partitions on the same device if present, etc).

It uses UDisks as its backend (but multiple backends can be implemented if desired).

Before I wrote this tool, I was using bashmount, which provided inspiration, but I wanted something a bit more ergonomic for my day to day use.

I decided to release it early, as soon as I started using it myself and felt it does the job. If circumstances permit, I’ll be able to add niceties and further smooth out the UX, maybe even add features (see the Roadmap for ideas I have at the moment), but I hope it won’t become “big and professional” 😉 Maybe I can port it to *BSD at some point🤔

Also, this is my first “real” program in Rust.

Enjoy!

(P.S. This program was written during and despite russian war.)

Highlight evaluated SuperCollider code in Emacs

Sun, 28 Jul 2024 00:00:00 +0300

Someone on the Fediverse asked if it’s possible to have Emacs visually highlight / flash the fragment of code that is currently evaluated in SuperCollider (via scel). It is! Here’s the code I use in my init.el to implement this, based on some example from some since-forgotten corner of the Net:

(defun undltd/sclang-highlight-defun (&optional silent-p)
  (cl-multiple-value-bind (beg end) (sclang-point-in-defun-p)
    (and beg end (pulse-momentary-highlight-region beg end))))

(defun undltd/sclang-highlight-region-or-line (&optional silent-p)
  (if (and transient-mark-mode mark-active)
      (pulse-momentary-highlight-region (region-beginning) (region-end))
    (pulse-momentary-highlight-one-line (point))))

(advice-add 'sclang-eval-defun :before #'undltd/sclang-highlight-defun)
(advice-add 'sclang-eval-region-or-line :before #'undltd/sclang-highlight-region-or-line)

(I tend to prefix all my custom functions with undltd/ to avoid potential name clashes with other libraries in the future).

HUK MISTA 2.0 @ House of Sound

Mon, 15 Jan 2024 00:00:00 +0200

An interactive work for House of Sound (Дім Звуку) in Lviv, Ukraine, installed in 2023.

A joystick-operated 2d soundscape “map” where a visitor “wanders” between sounds, thereby mixing field recordings into a composition of their own.

Built using the beautiful Racket programming language with the minimalist r-cade game engine¹ along with SuperCollider for sound (communicating over OSC).

Video & photos cc by-sa 4.0 Volodymyr Mysan-Miliasevych.

appears to be unmaintained since some time now 😢 ↩

Live @ Lviv Art Center

Sat, 30 Sep 2023 00:00:00 +0300

A meditative ambient performance using livecoding techniques in SuperCollider.

Performed as part of an artist talk at Lviv Art Palace in 2022.

The full event recording can be found on Lviv Art Center’s youtube channel.

nannou on NixOS

Sat, 06 Aug 2022 00:00:00 +0300

A very quick note: here’s the shell.nix I use to build a basic nannou app on NixOS and run it:

{ pkgs ? import <nixpkgs> {} }:

pkgs.mkShell {
  buildInputs = with pkgs; [
    pkg-config
    cargo
    rustc

    xorg.libxcb
    xorg.libX11
    xorg.libXcursor
    xorg.libXrandr
    xorg.libXi

    alsa-lib
    vulkan-loader
  ];

  LD_LIBRARY_PATH = "${pkgs.vulkan-loader}/lib";
}

With this, I can launch a nix-shell and cargo run the example nannou project.

(The LD_LIBRARY_PATH line is required to make the app find vulkan libraries at runtime; otherwise it would fail to run with the following error: could not build default app window: NoAvailableAdapter).

Live audio visualization using ffmpeg

Sun, 08 May 2022 00:00:00 +0300

ffmpeg can turn audio files into videos with nice visualizations, for instance displaying a scrolling spectrogram using the showspectrum filter.

It turns out you can also use it to do visualization of live audio signal onto the screen. On Linux I used the -f jack input option to route live audio from any jack application into ffmpeg, and the -f sdl output option to display the result as a window on the screen.

Assuming you have jack server running, you can do:

ffmpeg -f jack -i ffmpeg \
    -filter_complex "[0:a]showspectrum=s=1980x500:mode=combined:slide=scroll:fps=30:scale=sqrt:gain=5,format=yuv420p[v]" \
    -map "[v]" -f sdl "ffmpeg visualization"

Then connect the desired audio signal to the ffmpeg jack ports and enjoy. For more elaborate examples of ffmpeg visualizations see Luka Prinčič’s post.

Thoughts on Lisp #0: what is code?

Tue, 08 Feb 2022 00:00:00 +0200

Programming languages are not only tools for commanding computers, but also for communicating and structuring our own thinking; and they shape our reasoning about certain problems in their own way.

In this post I reflect on a few characteristics of Lisp (and specifically Racket) that capture my mind again and again.

Syntax vs data

When I write, say, Python (which is a great language!), I tend to have this mental image of writing a certain syntax that’s then parsed into the actual logical structure (the abstract syntax tree or AST) of the program by the interpreter / compiler, similar to how HTML is translated into the DOM in memory. Of course, I rarely consciously think about that distinction, but when switching to/from Racket I notice this nuance. The syntax is just an arbitrary set of rules to write out the program in this specific form, and alternative syntaxes for Python exist.

In contrast, when I write Racket, conceptually it feels like I’m typing out a data structure that represents the algorithm(s) of the program (very close to the AST). Obviously there are still many translation steps between the input I provide and the result (a running program) inside the runtime; but the relationship between the source code and the actual program is somewhat special.

The famous parentheses in a Lisp program map directly to its logical tree-like structure.

Let’s take a very primitive example:

Python:

1 + 2 + 3 ** 2 * 4

Racket:

(+ 1 2 (* (expt 3 2) 4))

A few things to note in the Racket example:

The computation is directly dictated by the structure of the expression, delimited by pairs of (...), and not some other factor like operator precedence - i.e., the way it is written expresses how it is computed;
Most expressions follow the pattern: (<OPERATION> [<ARGUMENT> ...]);
Arithmetic operators like +, -, expt are not special syntax but regular functions: the expression (+ 1 2 3) means apply the function + to arguments 1, 2, 3.

Thus, there is a symmetry in Racket between writing (+ 1 2 3) and, say, (build-path "/" "tmp" "somefolder" "somefile.json") - both are expressions applying functions to values, and returning values.

Also, just like any function, + can be passed to other function as an argument. The following expression:

(map (curry + 5) '(5 10 15))

results in '(10 15 20). The single quote before ( is a shorthand for (quote ...) and means that what follows is not evaluated as a function call, but returned as a list instead (we will talk about this more below).

Code as a tree

Let’s look at another example, say, computing whether a given number is a fibonacci number:

Python:

from math import isqrt

def is_fibonacci(num):
    if num >= 0 and float(num).is_integer():
        intermediate = 5 * num ** 2  # save some repetition
        if (is_square(intermediate + 4)
            or is_square(intermediate - 4)):
            return True
    return False

def is_square(num):
    return num == isqrt(num) ** 2

Racket:

(define (fibonacci? num)
  (cond                                        ; conditional
    [(and (integer? num) (>= num 0))           ; clause
     (define intermediate (* 5 (expt num 2)))
     (or (square? (+ intermediate 4))
         (square? (- intermediate 4)))]
    [else #f]))                                ; clause

(define (square? num)
  (equal? num (expt (integer-sqrt num) 2)))

Again, in the Racket program nested parentheses define the “shape” of the computation. Pairs of [...] are syntactically equivalent to (...) and used only by convention.

Conditionals like cond (a generalized if), and, or, etc, follow the same pattern: (<OPERATION> <INPUTS>), and also produce a value. However, specific conditionals have specific shape of their inputs, for instance cond takes one or more clauses mapping tests to values.

Since conditionals are expressions that evaluate to values, there is no need for explicit return - the evaluated expression is the value:

(and ...) tests if none of its subexpressions are false (#f) and returns the value of the last one or #f otherwise;
(or ...) returns the first non-false subexpression or #f if none;
and cond returns whatever the last expression of the matching clause returns.

Functions return their last (outermost) value.

Overall, the program looks more like a tree of expressions that produce values to give the final answer, rather than a chain of actions or commands. This mental attitude is something I admine in Lisp.

Code as data, data as code

One last bit I’d like to touch on here. The source code in Lisp is actually a data structure, not just a particularly shaped long string.

For instance, with this command (executed in unix shell):

$ echo '(+ 1 2 3)' | racket -e '(read)'
'(+ 1 2 3)

…I have just parsed a chunk of source code "(+ 1 2 3)" into data - a list consisting of the symbol + and there numbers 1, 2 and 3, but have not executed it, just printed it back as data again. This small data structure can also be executed:

$ echo '(+ 1 2 3)' | racket -e '(eval (read))' # this is what happens normally
6

Notice how, conceptually, it’s not the source code that is executed, but the data structure - a list of items - that is read from the source code.

Reading is a separate, distinct operation from executing.

Nothing stops you from doing something with the data before executing it. For instance, running the following program would produce the familiar "hello world":

(define my-program
  ;; the single quote before the list means `read` that thing
  ;; as data but do not `eval` it yet.
  '(string-append "world" " " "hello"))

(eval (cons (first my-program) (reverse (rest my-program))))

In the above example I reversed all but the first element of my-program before executing it.

Now, this is obviously not what most Lisp programmers would normally do. But the fact that your program is a data structure changes how you think about it.

You can also read things you don’t plan executing at all. For instance, you can point the reading machinery of the interpreter at a configuration file without ever executing what’s inside, just using it as passive data.

Nevertheless, writing programs that transfrom themselves before being executed is very common in the Racket world, although this is done in a much cleaner and more declarative way using macros.

But why, you ask? Because programmers love abstractions and macros provide a way to abstract out patterns of code that emerge in this or that specific domain (or accross domains!).

I’ll end this post with a final example: a quite popular instance of macro use in Racket, providing a nice way to “pipe” values sequentially through a chain of operations:

#lang racket  ; selecting the main Racket dialect

(require threading)

(~> "world hello"
    (string-split " ")
    (reverse)
    (string-join " ")
    (string-append "💜"))

The (~> ...) fragment actually translates to:

(string-append
 (string-join
  (reverse
   (string-split "world hello" " "))
  " ")
 "💜")

The ~> form is not a language feature or special built-in syntax - it is a macro coming from a a third-party package. Macros are Lisp functions that transform Lisp code before it will be executed.

As you can see, the language allows great creativity and flexibility in applying itself (code) to itself (data), so to speak.

(Recursion in general is also practiced quite often by Lispers, but that is a topic for a dedicated blog post).

Live @ Contrasts Festival 2021

Wed, 13 Oct 2021 00:00:00 +0300

I was invited to perform at the CONTRASTS International Contemporary Music Festival in Lviv, Ukraine.

The performance was done in SuperCollider, but with very little live coding - instead I used a midi controller to manipulate the sound most of the time. Hence the picture is not very eventful, but I thought I’d share the screen anyway.

Photo cc by-sa 4.0 Danylo Bedriy / Contrasts Festival.

Music for "Відчинені вікна"

Sun, 10 Oct 2021 00:00:00 +0300

I’m glad to share “Відчинені вікна” (“Opened windows”), an art / poetry film by Olha Povoroznyk and Ostap Slyvynskyi, to which I composed the music track. The film is published on youtube.

The sound material for the soundtrack is mostly layers of clarinet multiphonics and “solos”.

Sonic memories from MC6

Mon, 20 Sep 2021 00:00:00 +0300

I was recently invited to join a diverse art-focused gathering at Creative Residence MC6 in Slavsko (yay!); I brought a few recorders and invited others to experiment with them and make their own recordings. I recorded too. This is a short collage of what ended up on the memory cards afterward.

flac download

#ArtNarysy #АртНариси