Following on from previous posts on SFX electronics:

Here’s some data and discussion on reducing artefacts like flickering if using low-frequency PWM LED lighting on-camera.

The best laid plans of mice and men…

Extremely tight deadlines for pre-production mean there’s no time to fab+assembly (given that a revision to first fabs might be needed), so time for plan B: a much simpler push-button wired solution, no MCU etc.

But first a summary of where I got to with the PCB.

Here’s a bird’s eye view of some git topics.

These are things a seasoned git user should be aware of.

I’ll be your Captain for this flight.

I’m talking to a film producer friend about a make-up prosthesis that includes small lights that need to be remote-controlled. Here’s some thoughts on practical design and safety.

Trade-offs loom large in a project like this; the practicalities of filming and production is one of the most interesting parts.

There’s lots of documentation and chat on the web about OpenSCAD.

This is good, but it also means some of the things I want to remember are scattered all over the place.

So here is a collection of some of useful reminders for OpenSCAD.¹

This is a collection of notes on change ringing. Will be occasionally updated.

I’ve experimented with method design at various times and place notation is a very useful tool, but it’s lacking in some situations. Here’s a few ideas for some bolt-ons.

In which your hopeful protagonist describes Million Point Sculptures, and a highly interactive exploration tool written in Metal.

In the 1980s there was a wave of fascination with fractals and chaos in popular culture, and several books really caught the imagination of young me.

One was Chaos by James Gleick (un classique)¹. Also there were some lovely books by Clifford Pickover, like Computers and the Imagination, containing curious things like Million Point Sculptures: intriguing generated art showing wispy smoke-clouds. They’re generated by some quite simple equations.

This helper is installable with SPM, see GitHub repo

I’ve been using the Swift Testing framework more. Despite my previous grumble I do like the arguments: feature of the @Test macro and how much it can clean up tests:

@Test(arguments: [
	(true, "bob", 38),
	(false, "sue", 45)
])
func testUserPermissions(isBasketEmpty: Bool, username: String, age: Int) {
    #expect( ... )
}

The ability to supply a list of parameter variants to test is very useful. I think it tends to result in more exhaustive tests because of ease of use.

But being able to easily whack in a list of argument variants soon reveals a slight annoyance. It’s not unusual to end up with a test like this:

The orth concept in 2D geometry and graphics is where, given some vector, we find a vector (line) that is at right angles to the original. We have a tiny bit of choice about how to do it – we can pick a vector to the left, or to the right – but it’s very simple (more here).

The equivalent function in 3D is one of those odd little problems where you are given some freedom with the answer, and you don’t really care about that freedom – just pick something please! – but you’re made to care about it anyway and do what feels like too much thinking. Bah!¹