Rubber Band Library v1.8.2

May 20, 2018May 20, 2018 Chris Cannam

I have finally managed to get together all the bits that go into a release of the Rubber Band library, and so have just released version 1.8.2.

The Rubber Band library is a software library for time-stretching and pitch-shifting of audio, particularly music audio. That means that it takes a recording of music and adjusts it so that it plays at a different speed or at a different pitch, and if desired, it can do that by changing the speed and pitch “live” as the music plays. This is impossible to do perfectly: essentially you are asking software to recreate what the music would have sounded like if the same musicians had played it faster, slower, or in a different key, and there just isn’t enough information in a recording to do that. It changes the sound and is absolutely not a reversible transformation. But Rubber Band does a pretty nice job. For anyone interested, I wrote a page (here) with a technical summary of how it does it.

I originally wrote this library between 2005 and 2007, with a v1.0 release at the end of 2007. My aim was to provide a useful tool for open source GPL-licensed audio applications on Linux, like Ardour or Rosegarden, with a commercial license as an afterthought. As so often happens, I seriously underestimated the work involved in getting the library from “working” (a few weeks of evening and weekend coding) to ready to use in production applications (two years).

It has now been almost six years since the last Rubber Band release, and since this one is just a bugfix release, we can say the library is pretty much finished. I would love to have the time and mental capacity for a version 2: there are many many things I would now do differently. (Sadly, the first thing is that I wouldn’t rely on my own ears for basic testing any more—in the intervening decade my hearing has deteriorated a lot and it amazes me to think that I used to accept it as somehow authoritative.)

In spite of all the things I would change, I think this latest release of version 1 is pretty good. It’s not the state-of-the-art, but it is very effective, and is in use right now in professional audio applications across the globe. I hope it can be useful to you somehow.

Repoint: A manager for checkouts of third-party source code dependencies

May 18, 2018May 18, 2018 Chris Cannam

I’ve just tagged v1.0 of Repoint, a tool for managing library source code in a development project. Conceptually it sits somewhere between Mercurial/Git submodules and a package manager like npm. It is intended for use with languages or environments that don’t have a favoured package manager, or in situations where the dependent libraries themselves aren’t aware that they are being package-managed. Essentially, situations where you want, or need, to be a bit hands-off from any actual package manager. I use it for projects in C++ and SML among other things.

Like npm, Bundler, Composer etc., Repoint refers to a project spec file that you provide that lists the libraries you want to bring in to your project directory (and which are brought in to the project directory, not installed to a central location). Like them, it creates a lock file to record the versions that were actually installed, which you can commit for repeatable builds. But unlike npm et al, all Repoint actually does is clone from the libraries’ upstream repository URLs into a subdirectory of the project directory, just as happens with submodules, and then report accurately on their status compared with their upstream repositories later

The expected deployment of Repoint consists of copying the Repoint files into the project directory, committing them along with everything else, and running Repoint from there, in the manner of a configure script — so that developers generally don’t have to install it either. It’s portable and it works the same on Linux, macOS, or Windows. Things are not always quite that simple, but most of the time they’re close.

At its simplest, Repoint just checks stuff out from Git or whatever for you, which doesn’t look very exciting. An example on Windows:

repoint

Simple though Repoint’s basic usage is, it can run things pretty rigorously across its three supported version-control systems (git, hg, svn), it gets a lot of annoying corner cases right, and it is solid, reliable, and well-tested across platforms. The README has more documentation, including of some more advanced features.

Is this of any use to me?

Repoint might be relevant to your project if all of the following apply:

You are developing with a programming language or environment that has no obvious single answer to the “what package manager should I use?” question; and
Your code project depends on one or more external libraries that are published in source form through public version-control URLs; and
You can’t assume that a person compiling your code has those libraries installed already; and
You don’t want to copy the libraries into your own version-control repo to form a Giant Monorepo; and
Most of your dependent libraries do not similarly depend on other libraries (Repoint doesn’t support recursive dependencies at all).

Beyond mere relevance, Repoint might be actively useful to your project if any of the following also apply:

The libraries you’re using are published through a mixture of version-control systems, e.g. some use Git but others Mercurial or Subversion; or
The libraries you’re using and, possibly, your own project might change from one version-control system to another at some point in the future.

See the README for more caveats and general documentation.

Example

The biggest current example of a project using Repoint is Sonic Visualiser. If you check out its code from Github or from the SoundSoftware code site and run its configure script, it will call out to repoint install to get the necessary dependencies. (On platforms that don’t use the configure script, you have to run Repoint yourself.)

Note that if you download a Sonic Visualiser source code tarball, there is no reference to Repoint in it and the Repoint script is never run — Repoint is very much an active-developer tool, and it includes an archive function that bundles up all the dependent libraries into a tarball so that people building or deploying the end result aren’t burdened with any additional utilities to use.

I also use Repoint in various smaller projects. If you’re browsing around looking at them, note that it wasn’t originally called Repoint — its working title in earlier versions was vext and I haven’t quite finished switching the repos over. Those earlier versions work fine of course, they just use different words.

Actual physical objects made of stuff · Things that Are Gone · Things where Someone Else Is Doing All The Work

A film camera

May 13, 2018May 13, 2018 Chris Cannam

I take a lot of photos and I share some of them online via the antique medium of Flickr. Not many people look at them, which I don’t mind, because I imagine my audience to be (a) family and (b) myself, later. Photos I take with people in them are usually visible only to my friends and family. I’m a person who takes photographs, not a photographer.

But I do take some joy in the practice of photography. That’s partly because I can: at my level, there is very little to it: somebody else has done all the hard work. There is massive, long-term, highly technically sophisticated labour behind every functional detail of image capture and reproduction, which all culminates, for routine takers-of-photos like me, in pressing a button or tapping the screen and deciding whether you like the resulting image or not. It’s a ritual that has delivered a spurious feeling of creativity to people for decades, prefiguring the internet age.

There are four categories of potential joy in a photo, and they go in this order:

Looking at whatever it is you’re thinking of taking a photo of
Solving technical problems, or just fiddling with the camera
Enjoying the picture itself
Finding the pic again later and reminiscing

Obviously, photos of your friends in the pub can skip categories 1 (except in a social sense) and 2. Very deliberate landscape photos might have a lot of categories 1, 2, and 3 but not a great deal of category 4. Please understand that I am vaguely blathering about this category thing because it seemed to make sense while I was typing this, not because I think it’s any kind of real system.

I started out taking photos on film, then moved to a digital camera in 2003. By then a digital camera already gave you more pleasure in the likely quality and serendipity of your pictures, good for categories 3 and 4 above. I did keep a film SLR — a Zenit EM, the cheapest second-hand SLR available when I bought it in 1991 — but it’s very clumsy to use, and the category-2 joy you would imagine getting from it never really materialised.

In search of that sort of joy, I recently bought a slightly fancier second-hand film camera from someone on eBay. I wanted something still mostly manual, but more like the kind of thing I never had access to when young. I decided to buy a Minolta, and I’m not ashamed to say that was mostly because I like the old Minolta logo, before they introduced the more familiar Saul Bass-designed all-caps logotype in 1981. The older logo is verging on Comic Sans in its friendliness, and gives the camera a sweet face:

This manual-focus, manual-aperture, automatic exposure Minolta XG-9 dates from about 1980. It was the cheaper of Minolta’s two SLR ranges at the time; the body probably cost slightly more than a 48K ZX Spectrum home computer. It would have been a nice and very practical camera. It also embodies a mind-boggling amount of mechanical complexity compared with modern equipment. To the right is a schematic of the winder mechanism, one of dozens of such illustrations found in the service manual.

It was sold to me with a lens at least a decade older than the camera, a splendid-looking chunk of metal with an impressive (and apparently rather 1960s) wide front glass element.

Anyway, I bought this for my category 2, the fiddling. But so far what I’ve appreciated most is the thing I gave as category 1: just looking at the real scene more closely. Without a screen to review photos on, you have to assume that your photo will fail and you will never get to see this again. If an image should appear again, days later when you get the film processed, it’s a fresh delight.

The downside is that the economics of successful photos still apply. That is, only one in ten shots is any good. With a smartphone or digital camera you can take a hundred photos and have ten you really like. With film you buy a 36-photo roll, get three or four decent photos, but have to visit the print shop twice and spend at least £15 buying and developing the film. (Though I was surprised to find that you can still get film processed at Snappy Snaps.)

And how are the photos? Well, it’s a bit like listening to vinyl records. It’s nice for things that benefit from a bit of roughness and vigour, like this kind of thing:

(That one wanted a lens hood to prevent the flares in the middle and right, but I didn’t have one at the time.)

Or for snaps of people:

41329457102_3b09963088_c

I like both of those a lot, but I’ve yet to get any really successful landscape or “still-life” pics from it and I suspect I never will, now that I’m used to a cleaner, higher resolution digital image.

Will I be using it much? Am I going to carry it around everywhere, but take far fewer and more selective photos than I otherwise might? Probably not, but it might not be up to me anyway. These are fairly solid cameras, but this one is nearly 40 years old and has a few electronic bits as well as sensitive mechanical parts. They do fail in various ways and I don’t entirely trust that it’s going to be still working the next time I want to use it. That primitive but sturdy Zenit will probably have the last laugh.