Hayao Miyazaki and work

I see it’s the 80th birthday of the noted animator Hayao Miyazaki.

I once read his book of essays Starting Point: 1979–1996 and was seized by a desire to do something well, with vigour and clarity, instead of tiredly poking around. At the time this made me a little miserable, and I wondered why.

* * *

The book contains essays, interviews, and documents from Miyazaki during a period in his 30s and 40s in which he directed six highly-regarded anime feature films: The Castle of Cagliostro, Nausicaä of the Valley of the Wind, Laputa: Castle in the Sky, My Neighbour Totoro, Kiki’s Delivery Service, and Porco Rosso. This is an excellent run, and history tells us that the two films he made immediately afterwards would be even more celebrated.

The book contains planning documents, interviews, and some essays written between films. The planning documents describe a film before it has been made, and the interviews talk about it afterwards, when in every case it had been a success.

This structure, no doubt accidentally, gives a sense of a narrative like this: Miyazaki thinks of an idea and writes it up with in clear and forceful terms; he starts drawing without a script or storyboard and develops the plot as he goes; he works solidly for three years; the film is finished; it’s a wonderful piece of work that is just as he had envisioned; the process repeats.

Reinforcing this impression is some of the content of the interviews. For example, when talking about My Neighbour Totoro — a glorious film whose origin seems to speak of as pure a work of art as ever appeared in a cinema — Miyazaki remarks that he felt “tremendous happiness” while working on the film, that he knew throughout how it was going to work, that he could avoid any directorial tricks and keep the plot as simple as possible, that he could almost have made the entire film be just about the excitement and fear of a typhoon passing near a house at night; and that if he were to make the film again, given the same technical constraints, the only thing he would change would be to allow more time with the main characters, two small children, while they live their lives, ignoring the plot.

* * *

This is very lovely to read, but also a little daunting. There is something there, real or imagined, that I found I longed for in my work.

What is that longing? It isn’t about talent. I’m delighted by the talent of Miyazaki, but I don’t yearn for it, probably because I can’t imagine having it. It also isn’t about whether my work is worthwhile — I have doubts, but those are long-standing, unchanging doubts. I think it is about focus and application.

I believe that we all have the ability to create work that satisfies our own critical judgement as a coherent artistic effort, but that we don’t do it, because we can’t find the clarity of mind and the conviction to complete an idea with the quality that we first imagine for it.

As a mere programmer, I’m aware that much of the software I write will never be used, or not in the way I imagined it. I believe this is the unspoken experience of all programmers. Software that is made with care but not used is obviously unsatisfying. But the other side of it is software that is not made well enough to merit users at all. If it hasn’t been made well enough, then the more popular it is, the more people might be damaged by mistakes in it, and so the worse it is. Experience seems to consist partly in learning to suppress the fear of this, and to find sufficient trade-offs to ensure that anything useful ever gets published.

* * *

The perceived narrative I referred to above is not the whole story. There is plenty in the book about team work, and it hints at the vast amount of manual labour going on, with stories about overworked colour artists, slipping schedules, and the continually unmet expectation that everything will be easier next time. And at the end of the book is a retrospective timeline, from which we can see that the narrative doesn’t flow linearly either — the team must often have been working on more than one Miyazaki-directed film at once, and some films were based on ideas that had been sketched decades before.

Focusing on team effort does change the picture. You need a lot of people to make a film, and I suppose before you animate the film, you need to animate the people. If the impulse is enough to carry everyone along, then a team can maintain a direction even if their director isn’t certain where they will end up. Perhaps the sense of purpose that seems so desirable is something that one person can’t readily sustain on their own.

* * *

My reverence for the film artifact might not be shared by its makers either. Throughout this book, as well as in more recent interviews I’ve seen, Miyazaki is actively grumpy about the value of anime: there’s too much animation being made already, this is all a waste of time, we contribute nothing to the world, I only want the industry to continue because I know too many people who are animators and I don’t want them to lose their jobs. It’s only when he is sunk deep into a project that he appears to be happy about it.

On macOS, arm64, and universal binaries

A handful of notes I made while building and packaging the new Intel/ARM universal binary of Rubber Band Audio for Mac. I might add to this if other things come up. See also my earlier notes about notarization.

Context

I’m using an ARM Mac – M1 or Apple Silicon – with macOS 11 “Big Sur”, the application is in C++ using Qt, and everything is kicked off from the command line (I don’t use Xcode).

To refer to machine architectures here I will use “x86_64” for 64-bit Intel and “arm64” for 64-bit ARM, since these are the terms the Apple tools use. Elsewhere they may also be referred to as “amd64” for Intel, or “aarch64” for ARM.

Universal binaries

A universal binary is one that contains builds for more than one processor architecture in separate “slices”. They were used in the earlier architecture transitions as well. Some tools (such as the C compiler) can emit universal binaries directly when more than one architecture is requested, but this often isn’t good enough: perhaps it doesn’t fit in with the build system, or the architectures need different compiler flags or libraries. Then the answer is to run the build twice with separate output files and glue the resulting binaries together using the lipo tool which exists for the purpose.

How does the compiler decide which architecture(s) to emit?

The C compiler is a universal binary containing both arm64 and x86_64 “slices”, and it seems to be capable of emitting either arm64 or x86_64 code regardless of which slice of its own binary you invoke.

Perhaps the clearest way to tell it which architecture to emit is to use the -arch flag. With this, cc -arch x86_64 targets x86_64, cc -arch arm64 targets arm64, and cc -arch x86_64 -arch arm64 creates a fat binary containing both architectures.

If you don’t supply an -arch option, then it targets the same architecture as the process that invoked cc. The architecture of the invoking process is not necessarily the native machine architecture, so you can’t assume that a compiler on an ARM Mac will default to arm64 output.

I imagine the mechanism for this is simply that the x86_64 slice of the compiler emits x86_64 unless told otherwise, the arm64 slice emits arm64 likewise, and when you exec the compiler you get whichever slice matches the architecture of the process you exec it from.

There’s also a command called arch that selects a specific slice from a universal binary. So you can run arch -x86_64 make to run the x86_64 binary of make, so that any compiler it forks will default to x86_64. Or you can do things like arch -arm64 cc -arch x86_64 to run the arm64 binary of the compiler but produce an x86_64-only binary.

If you invoke a compiler directly from the shell without any of the above going on, then you get the machine native architecture. I assume this is just because a login shell is itself native.

For my builds I found it helpful to provide a cross-compile file to tell Meson explicitly which options to use for the architecture I wanted to target. That avoids the defaults being just an accident of whichever architecture Meson (or its Python interpreter, or Ninja) happened to be running in, without having to litter the build file with explicit architecture selections. I then scripted the build twice from a separate deployment script, using a different cross file for each, rather than try to have a single Meson file build both at once.

How do I target a particular version of macOS?

Use a flag like -mmacosx-version-min=10.13 at both compile and link time.

For ARM binaries, the oldest version you can target is 11. But you can still build a universal binary that combines this with an Intel binary built for an older version, and the result should run on those earlier versions of macOS as well.

How does a version of macOS decide whether my binary is compatible with it?

I had this question because I had built a universal binary (as above) in which the Intel slice was, I thought, built for macOS 10.13 or newer, but when I brought it to a machine with macOS 10.15 it showed as incompatible in the Finder and could not be opened there.

The answer is that it looks at the relevant architecture slice of the universal binary, and inspects it to find a Mach-O version number. In “older” versions of the macOS SDK this version is written using the LC_VERSION_MIN_MACOSX load command; in “newer” versions (I’m not quite sure when the cutoff is) it is tagged as the minos value of the LC_BUILD_VERSION load command instead. The linker quite logically decides which load command to write based on the value of the version number itself, so if you build -mmacosx-version-min=10.13 you get a binary with LC_VERSION_MIN_MACOSX specified.

You can display a binary’s version information with the vtool tool, and it also appears in the list of information printed by otool -l. In theory you can also change this tag using vtool, but (a) that’s a bad idea, fix it in the build instead and (b) vtool segfaulted when I tried it anyway.

And after all that, in my case the cause turned out to be that I’d failed to supply the -mmacosx-version-min flag at link time.

Why is my program being killed on startup?

It appears that if you build a program for one architecture and then rebuild it for the other arch to the same executable file without deleting the executable in between, sometimes it doesn’t run: it just gets “killed (9)” on startup. I failed to discover why and I failed to reproduce it just now in a test build. I guess if that happens, delete the executable between builds.

* * *

Bonus grumble about Mac trackpad and mouse options

This is not useful content. Please do not attempt to read it

I haven’t used a Mac in such earnest for a while now, so of course I’ve been rediscovering things about macOS that I don’t get on with. One that I find particularly maddening is the way it handles scroll direction for the trackpad and an external mouse.

I switch between the two a lot, and I like to use the “natural scrolling” direction (touchscreen-like, so your fingers are “pushing” the content) with the trackpad, but the opposite with the mouse, which has a scroll wheel or wheel-like scrolling zone whose behaviour I became accustomed to before touchscreen devices started sprouting everywhere.

Fortunately, macOS provides separate touchpad and mouse sections in the system preferences, which contain separate switches for the scroll direction of the trackpad and mouse respectively.

Unfortunately, when you change one of them, the other one changes as well. They aren’t separate options at all – they’re just two different switches in different windows that happen to control the same single internal option! So every time I go from trackpad to mouse or back again, I have to also go to system preferences and switch the scroll direction by hand. That is so stupid.

(Linux and Windows both have separate options that actually work as separate options. Of course they do. Why would they not?)

A few pictures from 2020: 4. Deepest black

(Previously: A few pictures from 2020: 3. The living)

I started developing my own black-and-white films at home a couple of years ago. There’s nothing quite like toiling through the process before emerging with a strip of negatives which you have to hang up and let dry, knowing there are pictures on them but being unable to tell what they actually are.

I’ve tried a few different types of film, and I’m most fond of Ilford FP4+. It’s relatively low-contrast, grainy (the accompanying text describes it as fine-grain but I think it must have been written in 1935), very attractive in sunlight due to a bit of sympathetic halation. I like a black-and-white photo with almost no solid black in it. I like it light, airy, and otherworldly. I haven’t ever been keen on reportage-y gritty, contrasty films like Kodak T-Max.

But this post is about the opposite of FP4+. Film Washi “Film S” is a film originally intended, apparently, for optical recording of film soundtracks. It’s not gritty or grainy. It’s a slow film, very smooth, high contrast, tricky to expose properly. The result is a fabulous texture in things like reflections and water surfaces as well as remarkable contrast and deepest blacks.

This is the view below the Westway at Paddington Basin. (All the photos here are from September to November 2020.) The bundles, the stains, the footprints, the textures on the uprights, the terrifying precision, the shiny car.

Under the Westway at Paddington

The building site at Whiteley’s, on Queensway, London W2.

Whiteley's building site

A pedestrian corridor under the Westway.

Under the Westway

The Thames, from the south bank at Nine Elms, looking toward Battersea. With a mudlarker searching on the beach.

Toward Battersea from Nine Elms

A new, not-yet-filled retail unit at Paddington Basin.

Empty unit, Paddington Basin

A rubble disposal barge on the Thames outside the MI6 building. (This looks like quite a small boat, until you check the scale against the railings over to the right.)

From Vauxhall Bridge

A few pictures from 2020: 3. The living

(Previously: A few pictures from 2020: 2. Cinefilm. Following: A few pictures from 2020: 4. Deepest black)

Mandarin duck, Kensington Gardens
In March I discovered that the jammed Minolta Auto-Rokkor 55mm lens I’d just cleaned and lubricated was lovely for portrait-distance shots. But I didn’t use it as much as I should have, because I also discovered I’d reassembled it with the wrong focus at infinity, so it was only good for portrait-distance shots. I never did fix that. Anyway, the nice duck above was one of those shots.

In May I discovered that, if you walked along the sketchy bit of land between the Westbourne Bridge and Royal Oak tube stations just beyond Paddington and peered down over the wall toward the tracks at the right time of day, you would find a family of foxes playing. I came back with a long lens (cheap Soviet Jupiter-11) and took these, a sequence of photos I really love. This was such a joy during a pretty bleak time.

Foxes
Foxes
Foxes

I took the Jupiter lens again to the park in September to try to get a photo of magpies in flight. I do like magpies: they’re beautiful and they move in a very interesting way. They’re quick and sudden, they hop a lot, and they never exactly take off — they just hop and hop and, at the moment they want to take flight, suddenly the last hop turns out to have been liftoff.

There’s a superstition that it’s bad luck to see a lone magpie, but I decided a few years ago that I would always look at a magpie, and appreciate it.

But they’re really hard to photograph in motion, because they move in such unexpected ways. Here’s as good as I managed, a group giving way to an approaching dog:

Magpies scattering as a dog approaches

A crow is simpler in motion. Here’s a crow taking off from the ground. Um, or I think it might actually be a raven. I am not very good at this. It’s much bigger than a magpie and takes a relatively long time to get airborne – but isn’t it fantastic!

Crow

A few pictures from 2020: 2. Cinefilm

(Previously: A few pictures from 2020: 1. Keep Going. Following: A few pictures from 2020: 3. The living)

A company called Silbersalz35 sells 35mm cartridges loaded with various sorts of motion-picture film, at a price including processing and scanning. The films have to be developed with the ECN-2 chemical process, so the inclusion of processing matters, as most still film processing labs don’t have ECN-2 facilities.

The Silbersalz 200T film is (I believe) Kodak Vision3 200T cinefilm. The T stands for tungsten: it’s colour-balanced for studio use and has a cold colour if used in natural light without filters, as I did.

I really like the look of these, but they are hard to display online next to digital photos. The typical bright, contrasty, heavily sharpened modern digital image makes these naturalistic images almost invisible when seen on the same page.

* * *

A tennis court next to the West Cross Route in west London. Closed when I took this in May. The buildings in the background are, I think, halls of residence for Imperial College under construction.

White City across the West Cross Route tennis court

Scaffolding on Craven Road, near Paddington station.

Craven Road

Here’s the Bakerloo Line station entrance at Paddington in February. A couple of days later it will be closed permanently, to be replaced by something fancy at an unspecified later date.

Paddington Bakerloo Line entrance

This film is really nice for photographing people – I take a lot of photos of family but I’m reluctant to make them public online, so here’s one of me (taken by my wife) on the 15th of March, very close to the official UK it’s-all-over pandemic date.

Me

Smithfield Market, in May, with construction for the Museum of London at the back.

At Smithfield

Paddington Station in May. I felt very conspicuous taking this.

Paddington station

A few pictures from 2020: 1. Keep Going

(Following: A few pictures from 2020: 2. Cinefilm)

At the start of January 2020, I hopped on a bus to the North Circular to take a couple of photos of bleak, slightly alarming empty urban scenes. Had I known how redundant that would seem later in the year, I might not have bothered. Though it may have been the last time I took a bus for fun.

A distinctive disused storage company in Neasden. Prominent from the North Circular, I’ve always rather liked it.

Storguard

A rotting board path along the back of the industrial estate in Neasden Recreation Ground ultimately leads to a small pier in the reservoir. I used to go for walks by the reservoir here when I lived near Brent Cross, but I had no recollection of this path. Is the text sinister or welcoming? On the 5th of January I thought sinister, but from this end of the year it feels like an encouraging message from the future.

Keep Going

* * *

Just over two months later, we’re in west London in late March. The weather is bright and the shops are colourful and shiny. But this is bustling Portobello Road and it isn’t really supposed to look like this.

Portobello Road

Other streets nearby are equally peaceful.

Queensway (Key Workers)

Devonshire Terrace

* * *

Getting photos in the park without lots of people in them is a trickier prospect. I’m very fond of the cluster of small oak trees in the bit of Hyde Park known as “the cockpit”, where a roundish ramped area slopes down to the Serpentine. This is a damp June day.

Path and oak, Hyde Park

Or a sunny one in October.

Oaks, Hyde Park

* * *

One industry that seems to have been at least at normal levels all year is construction; here a worker adjusts some fencing on the “cube” building site next to Paddington station.

Building site, Paddington