This week was a short week (after I included the bank holiday Monday into last week’s notes), and (outside of software contract work) mostly dominated by the Wuthering Bytes festival: preparing for my talk on the opening festival day, driving up to the lovely Hebden Bridge, the festival day itself (which is just the start of a week of events for the festival), and then the Open Source Hardware User Group OSHCamp 2019 over the weekend, followed by the drive back. Phew.

---

This year the Festival Day had a strong theme around communities that permeated though the talks on festival day: clearly the organiser Andrew Back had done a good job of curating the talks. JP Rangaswami, retired chief scientist at a lot of places you’ve heard of, kicked off the day with a talk about the value of “lurk” in society, touching on several themes at a macroscopic level that I was going to talk about at a microscopic level in my own talk: reminding us that it’s okay to try things, make a discovery that this isn’t what we thought, and then to move on; and also the importance of communities.

JP quoted some figures around open source projects indicating they typically have 5% of people doing the most obvious/lead work, then another 15% of people who are active in some way, and 80% who are “lurkers”, and he reflected on the under-appreciated value of the lurkers This resonated with me when I think of the community at Makespace, the community workshop from which I operate, and how these days I’m probably considered one of the 5%, but for a number of years I was part of the 80%, and had I not been in that 80% it’s unlikely now I’d be taking more of an active role in the community. In open source software the value of that 80% comes in usage/testing/documenting/etc., but it’s just not as readily recognised as the leading lights of development despite its importance. In Makespace the 80% who use the place even occasionally provide the justification for the place as a whole to even exist.

JP’s board picture looked at how we try to see value in people to let us blur those percentage divisions: he questioned what if we valued people not on their financial renumeration for a task (if it’s work), but on the usefulness of their output, which then may level the perceived value of those percentages. It was wondefully thought provoking start to the day.

From there on there were talks raging over engaging children with their world by enabling them to map air-pollution in real-time, letting them think about the non-obvious impact of small changes in habit, the history of the local area as the kickstart to the Industrial Revolution (again, a focus on community there), a lay-person’s guide to how nuclear decay in doped glucose is used to trace blood flow in the body, and that was just the morning session! The afternoon was similarly as diverse and enthralling.

Actually, that’s a slight fib, as I closed the morning session with my slot. In my talk I tried to pull together two strands: talking about how a guitar is built, going from the broad components of the guitar down to the details of fretwork and so forth, and at the same time using this to illustrate aspects of what it takes to keep up momentum and be successful at whatever endeavour you might choose to turn your hand at.

(a hat tip to Adrian McEwan for the picture!)

I’ve done talks at events in the past, and whilst I wouldn’t say I’m an expert, normally I feel I do an okay job and don’t stress too much about the prep, but this time I really did feel a need to up my game given how much I’ve enjoyed the talks at previous Wuthering Bytes festivals, so I ended up putting many hours trying to refine my talk.

I suspect trying to do two thematic threads rather than just one was a bit ambitious for me, but I felt I needed to make the talk pay off differently for different audience members: when giving a talk (as with writing these posts) I try to keep in my mind that people are giving up their time to listen to me, so I have to try my best to make it worth that time, and so here I wanted it to give something even if you felt on top of one side or the other.

When JP started his opening talk it was a pleasant surprise to hear the same themes I had embedded in my talk coming from him. I spent a lot of time stressing the importance of community as a maker. I’m fortune enough to have both a real world community in the form of the members of Makespace, and a virtual community in the form of instagram and other places luthier’s hang out and share advice/tips/techniques: I could not do what I do without those people. I may be a 5% at Makespace but I’m definitely an 80% in the luthier community, but thankfully the luthiers of the world seem to appreciate the lurkers out there, and I’ve been given lots of help from professional luthiers as I’ve made my way into this world of guitar building.

I only had one traditional slide (the rest were just photos of bits of guitars being built), so if you missed it, here’s the summary :)

My talk seemed to go well, in that it provoked a number of lovely conversations later in the day with people for whom it has resonated, so the stress and effort was worth it. My only lingering embarrassment from the whole thing was someone asked me to play something (I had my guitar and amp there as props to let me illustrate various points of the guitar) and due to stage fright I had a total brain blank and played a few dreadful chords and got a bit of a pity clap - oh the shame :)

---

Following on from the festival day was OSHCamp 2019, the annual get together of the Open Source Hardware User Group in the UK. Whilst perhaps less obviously linked to guitar building, I think there’s a lot of common themes here: whether we like to admit it or not most luthiers, amp builders and pedal builders are making designs that are either heavily influenced influenced by or direct descendants of existing guitars, amps, and pedals, so the idea of sharing physical designs is not new to us, just we do it in a slightly less well defined way.

The fact I can build an amp based on a 1950s Fender Champ because Fender shipped the circuit diagram with the product is something that would make most modern day Open Source Hardware advocates happy (though I hasten to add that Fender didn’t do so in order that you can make and sell clones, they did it to help with repair and maintenance).

Anyway, it was a good couple of days where I got to exercise the part of my brain I don’t use much these days - I have worked on digital electronics in the past, and I’m always trying to find a way to fuse that back into my hobbies.

Whilst the talks were good, the main thing relevant for here was the workshops on the Sunday, where I attended an introduction to KiCAD ran by Tim Telford of Devtank. Whilst learning Autodesk’s Eagle PCB design tool has been on my todo list for a long time (mostly for ideas around building pedals etc.), Eagle has such an archaic interface that I keep putting it off, and so I jumped at this chance to learn a simpler to use tool, on the grounds that the principles will likely carry over, and knowing any tool is better than knowing none.

KiCAD is no slouch as PCB tools go: it’s a very the popular open source package, which is ran by CERN and is accepted by on-demand PCB manufacturers like OSHPark. Indeed Tim’s company do all their high end test kit PCBs in KiCAD, so it’s definitely not a toy despite being relatively easy to get started with.

Whilst Tim did provide a simple digital circuit for learning KiCAD with I decided to go with a design somewhat more familiar to me: the classic Fuzz Face circuit that I made a bunch of by hand earlier this year:

Here’s the same circuit (with some extra bits for the jacks) as a schematic in KiCAD:

And then a very poor PCB layout:

Not bad for a couple of hours in a busy workshop. I’ll need to actually complete this design properly: here I’m using random components I found in the KiCAD library quickly rather than the actual audio jacks etc. and I’ve missed out a few bits due to time constraints. I don’t think I can really say I’ve learned PCB design until I have one in my hand: only then will I know the actual fiddly details that it’s so easy to miss if you don’t push things to completion.

If you want to get started on PCB design, KiCAD seems a much more friendly option than Eagle (or at least as friendly as PCB design can be), and runs on most platforms, so is definitely worth giving a shot.