Creating a Financial Foundation for Shared Infrastructure

Over a decade ago, I was one of the founding members of the Dallas Makerspace. My major contribution was designing the financial models that allowed the group to have a solid financial footing for renting it’s first dedicated space.

The other founders were more involved in all the growing pains of starting an organization like that, and I moved to another city and didn’t lift those boulders. But (as far as I know) the original membership models kept the group bootstrapped long enough to attract more members and grow into the organization they are today.

A member of the ThePrepared Slack recently asked how I did this, and in retelling the tale, I realized that I’d never written down the methods I used. I think sharing them here might be helpful to other people looking to start either their own hackerspace, makerspace, or other opt-in, volunteer-driven group that seeks to have a single costly piece of shared infrastructure.

The Problem, Or What Not To Do

First let me lay out the problem. A volunteer organization starts with zero money. It can ask for donations and have some non-zero value of money, and then they can spend that money on projects. This model works fine if the projects are less frequent than how often you can ask people for money. If the organization wants to rent a space, they will now have a monthly operating cost that extends into infinity. There is no time when you’ll have raised enough money to pay for all the rent forever. You can only raise enough money for some number of months. You can think of each months rent as a “monthly project” you need to raise money for. If you organization has a regular meeting once a week, that means you will be either about to ask for money, asking for money, or telling people how much money you raised three out of the four weeks of the month. A primary task of the volunteers who have donated their time to keep the organization running will be to figure out how to collect enough money each month.

Suffice to say, unless your organization is a group of people who love to ask other folks for money, this will not be an activity that is long term sustainable by volunteers. They did not join the ranks of your group to run around asking folks for money.

A Better Way

So you need a different model. Enter “membership subscriptions”. To be part of the club, you have to pay some amount. It should be automatic, like a PayPal subscription, so there is almost zero overhead on the volunteer leadership. It should be automatic so that your members don’t have to think about it. It should be monthly because your costs are monthly and matching those two time periods up is simplest and the least amount of work.

You will now need to do a solid amount of research to understand what your real monthly costs will be. There will be rent. There will be tool upkeep. There will be consumable supplies like toilet paper or sodas or paint or whatever it is your group needs. You will want to understand what kind of pad you need each month to save for annual costs or unforeseen problems. You probably also want to budget in some saving each month towards improving your group’s shared resources – eventually buying that laser cutter, for example. Or saving up for the down payment on a bigger space. You may also want to save up for a fund for member scholarships, or sponsored members, or paying for invited speakers.

After you know the monthly budget, you now have a sliding tradeoff between how much each person in the group will pay each month and how many people are in the group. The extremes are easy: If you need $1000 a month, you could have 1000 people give $1 or one person give $1000. But neither of those are likely, so you’ll be somewhere in the middle. Is 100 people who give $10 a month possible? What about four people who give $250? What about 33 people who give $30 a month? You can imagine situations where any of these could be the most appropriate case – it really depends on your group and what it is doing. My experience would suggest that you’ll have easier luck attracting fewer people that give more than having to find many people who give less, but you know your group better than I.

If you don’t, now is a good time to start going to the group members and finding out what sort of monthly contribution they’d be comfortable with. Have honest talks with people and get to a real value. It might be lower than you’d like, but it is best to get something people will actually commit to. In this day and age, folks have a lot of subscriptions running. When I was doing this, it was much less common. People will know what they are willing to contribute.

So now you can build a membership model. You’ll have a set rate of monthly contribution per people, and you can then find how many people you’ll need contributing. If you already have that many people, you’re finished! Congratulations! Chances are, you don’t have that many people, and so your new task is to attract enough people to your group who are willing to contribute. Even if you do, I recommend the following steps because it will cement a solid group of “founders” who are dedicated to the project.

How To Do It

The advice could end here and be pretty straight forward. I basically described “how to do division”. But there is a key strategy that you should use.

First, go around to all the members and present the model. Show them the spreadsheet. Share copies with them so they can tinker with it if they’d like. Make sure to answer all the questions on the different monthly costs you put in there. You’ll get to explain to them how much insurance costs, probably. They should check your work.

Second, start collecting monthly subscriptions now. Maybe not everyone will be enthused to contribute to a shared resource that doesn’t even exist yet. But you need to bootstrap your finances. Your group should be meeting regularly as if they actually had the shared resource. If you’re trying to find a permanent space, keep meeting at the temporary spaces. It will be a key time to bring everyone together and say something like “We are meeting here now, but according to the model, we’ll have our own space in a few months!” It helps people understand that the project is succeeding.

Third, do a “founders fundraising”. There will be some members that can spare a little extra money to kick start the project. Maybe they’re deep pocketed or super committed. I suggest asking for a round of three months worth of contributions. This is really only two months, because they should be contributing their monthly amount already. You won’t ever do this again – it is a one-time deal. In effect what it does is pay for some members that you haven’t attracted yet. It should be uniform – don’t have different tiers. Don’t fall for the trap of having one super-donor. You want there to be a sense of shared ownership in the group, not one person that gets an outsized say because they donated more. These founders are the committed folks and they’ll be the core of the volunteers that keep the project going in it’s infancy. They need to be on even footing, because a lot of them will be putting a lot of time volunteering for various tasks that need to be completed. folks that join later, but before you actually have the shared resource, could also join as founders if that makes sense for what you’re doing.

At this point you’ll be able to plot a chart of membership growth that shows when your monthly contributions will match your planned monthly expenses. You’re still out there gathering members right? Well, as long as your numbers grow or stay steady, that crossover point gets closer and closer. Meanwhile, you’re collecting money to build a reservoir to deal with folks coming and going.

Possible Outcomes

There are three possible outcomes: your contributing membership keeps growing, flattens outs, or starts decreasing.

Increasing membership

If the contributing membership keeps increasing, then you’ll quickly reach your break even point and be able to buy whatever shared resource you were trying to buy. You’ll be solidly able to hit monthly expenditure targets and will probably even start to grow a surplus. The group can use that surplus to improve the shared resources or buy new ones. It can use that to sponsor scholarships for new members. Figuring out what your group will do with it’s surplus is a great problem to have. I strongly caution against lowering the membership contribution level. This will upset previous folks who already were contributing at a higher amount. It also means you need to go back to the drawing board on what people are willing to contribute. You’d rather begin with a lower contribution than a high one that gets lowered later.

Flat membership

If you can only keep the same number of people contributing, or you lose people at the same rate that you are gaining people, you aren’t in that bad of a situation. Since you are collecting each month, eventually you’ll simply save up enough money to pay for your goal. The degenerate case here is that you’re the only one contributing and eventually you just save up enough to do whatever it is you’re trying to do. Earlier I said that you need to have a monthly contribution rate that matches your monthly contribution spend. That isn’t technically true if you’re doing something like a yearly lease. You’ll save up enough money to have a whole year’s worth of lease – it could take longer than a year depending on how many founders you had. You’ll then be able to sign that lease in a responsible way knowing that your group has saved up enough money to cover all the costs till the end of the lease contract. You’re making a bet here that by actually having the shared resource, you’ll be able to attract more members in the upcoming year. Attracting new members will be an important part of the group’s activities that first year if it wants to continue having that shared resource for the next year. But if it can’t do it, maybe it just wasn’t meant to be. You’ll have a good run of a year, and honestly that’s pretty great.

Declining membership

This is the failure mode. I would seriously reconsider the nature of your group. Are there toxic members driving away others? Are the membership rates incorrect? Is the shared infrastructure just not in demand enough? Something has gone wrong. I can’t tell you what, but signs don’t look good.

All is not lost. If you can keep a core group of folks to keep the dream alive, eventually you’ll build up enough funds for your group to get that laser cutter or storage unit or taco truck. Once the group has access to it, hopefully you can use whatever it is to attract enough people to get your membership numbers back up.


Hopefully this is a helpful guide. You and your founding team will have a lot of work to do, and if they’re volunteers, that’s a whole other resource to manage. But hopefully you’ve got a growing group of interested and people and a cool piece of shared infrastructure you can all rally around.

Comparing Engineering and Design

In an earlier post I wrote about the similarities between engineering and design. After discussing the concepts with a few engineers and designers, I thought it would be helpful to explore the differences between the two disciplines.

a crushed empty soda bottle on the ground
Photo by Roberto Sorin on Unsplash

Known solution versus unknown solution

In the introductory chapter of Designing Your Life, the authors point out the most salient different between engineering and design problems.

… [E]ngineering is a good approach to solving a problem when you can get a great deal of data and you’re sure there is one best solution.

Designing Your Life (Evans and Burnett, 2016)

They position design problems as not having a known single best solution.

[Creating the first laptop with a built-in mouse] was a design problem. There was no precedent to design toward, there was no fixed or predetermined outcome; there were plenty of ideas … but nothing was working.

Designing Your Life (Evans and Burnett, 2016)

In other words, engineering explores a problem space with a clear well-defined solution, while design explores a problem space without a well-defined solution.


A professor introduced me to the idea of asking whether a problem is “solvable by design” or not. This is a question a designer should ask when identifying a problem to solve. I found it incredibly helpful to break out of an engineering mindset. I was in the early stages of a project, exploring a problem space and being a bit overwhelmed at all the different facets of a large and complicated situation. My process was to try and create a framework for understanding the entire problem space, and then using that framework to come up with “the solution”. The framework was helpful – it provided a way to organize my group’s thoughts and gave us a common language to talk about the different facets of the problem space. But it did not point to a “solution” – instead it made clear that the tree of problems we were looking at had a root problem that was simply not solvable by design. The best we could do is mitigate some of the effects of the problem and provide a tool designed to help the people affected cope.

I’m not sure that engineering has such concept as “not solvable by engineering”. Certainly there are problems that aren’t, but I don’t recall that being part of any engineering course or discussion I ever participated in. It is perhaps a blind spot in the way engineering is practiced. Or perhaps such problems are dismissed as “not solvable by engineering yet“.

Tensions versus Trade-offs

Engineering is completely about trade-offs. The engineering Iron Triangle is a well-known diagram explaining the relationships between quality, time, and cost. Many physical parameters result in trade-offs – current through a device versus the amount of heat which can be dissipated or the range an aircraft varies as you trade off the weight of fuel and cargo. A trade-off is well-defined, often to the point of a precise mathematical relationship.

Tensions are similar to trade-offs but are not well defined. When a worker is remote, there is a tension between the amount of freedom a worker experiences by being “more remote” pulling against the connectedness they feel with their coworkers as a result of in-person experiences together. There is no precise amount of one or the other which is traded. Someone in a hybrid remote/in-person job experiences both, in a complex and continuous relationship. It is not possible to create a rule between the two, other than that in general and for most people having more of one will tend to have less of the other.

In both, two desirable properties cannot be completely fulfilled.

Avoiding the wrong methodology

I ended my earlier post saying that the two fields could learn from each other’s methods, and I don’t feel like the above differences refute that.

Instead my suggestion is to identify which kind of problem you are solving and avoiding the wrong manner of solution you seek. Solving a design problem with an engineering methodology leads to the collapse of an unknown solution space into a known solution space, often by reducing the problem to simply “Can this be done?” or “Can we do this?”. These can be a dangerous questions to solve because they do not consider if something should be done or not.

From a personal perspective, I believe that engineering-oriented organizations not coming to terms with whether they should be creating something or not has resulted in many negative consequences for society. Understand your problem space and choose carefully.

Building a small team

When starting a new venture, your team is often small due to timing, budget, or uncertainty. Growing a team from a small starting point takes careful thought about both the current needs and the future. When only a handful of people are on the team, each hire has a dramatic increase in the communication costs and cognitive load of relationships. There is a combinatorial jump as N goes from 2 through 6 that is unavoidable.

Photo by Wolfgang Hasselmann on Unsplash

On a small team, each member has to cover a wider spectrum of topics, even if the depth of understanding or time commitment of each topic is small. Someone needs to do all the little administrative tasks but they do not all sum to an amount of work that represents a full position. And that is often the case for many other topics. You do not need specialists yet.

But the software and technology industry is geared towards specialists. The cynic would say it is because it is easier to put people into a box with a label and disregard the other skills someone has. I think it is simply the nature of a tech industry culture dominated by huge players that are assembling large teams that are looking for very specific specialized roles. Those companies’ influence sets the tone of the discussion. When someone might get a job at a 10,000 person company or a 100 person company, which framing are they going to gravitate towards for themselves? It seems the gravitational pull of the big players wins out.

So building a small team is difficult. It is intrinsically difficult to do, and the hiring marketplace is slanted against giving you the information you need.

My advice, and the techniques I use follow.

First, I do my best to look for self-described generalists. If someone is sticking their neck out enough to go against the prevailing demand, chances are they’ve really thought about it. They tend to be well-rounded engineers and designers with a pragmatic view towards getting the job done.

Second, I talk to folks to get an idea of how flexible they are. Are they dogmatic? Do they know how and when to compromise? Have they worked in diverse teams of people with different backgrounds and goals? These are all signs that when something unexpected needs to be dealt with, they’ll be okay stepping up to the plate.

Third, I try to understand how everyone’s paths on the team will interleave and harmonize in the mid-future. What this time frame constitutes is highly dependent on the context, but what I mean is the period between “here is all the stuff we need to do now” and “here is all the stuff we’ll do one day”. When will you need a UX Engineer? When will you need a Usability Facilitator? As dedicated people fulfilling just that role, you will need them “one day”. Right now they might need just half a day each week. How is the role going to be filled by the various members of the team as the amount of work changes? It’s a multi variable optimization problem whose solution changes over time and suffers from unexpected shock events and step functions. Your goal is to keep your heuristic hat on and correct course as needed. This might involve hiring, but hiring is probably way too slow. You’ll need to know your team and who has the interest and ability to pick up something outside their wheelhouse.

You can see that the underlying theme is open and clear communication amongst team members, and that is my single point of advice. Stay in touch with the team – not simply hearing them but actually listening to what they’re saying and what is being left unsaid. Encourage constructive and celebratory feedback as a norm. Set up weekly 1-on-1s to understand where people are and what challenges they’re facing, not what work they’ve done. Create a space for discussion and have regular retrospectives so issues and concerns can be brought up, addressed, and reflected upon. Strive to establish a culture of psychological safety.

Building a small team often goes hand and hand with starting something new: a new project, a new feature, or even an entirely new company. Those are hard contexts for any sized team. But with open and honest communication you can deliver and succeed.

Good luck out there!

The Overlap of Engineering and UX Design

While simultaneously working in software engineering and completing my masters degree in HCDE, I started to notice a few overlaps in both the practice and conceptualization of engineering and design.

Both involve solving the problem of what to build. Both rely on a set of heuristics built by experience in the individual practitioners. Both are concerned with trade-offs.

two giraffes facing away from each other
Photo by Vincent van Zalinge on Unsplash

What to build

Solving the problem of what to build in either discipline is about understanding the gap the solution needs to fill.

In engineering, this is usually framed as requirements gathering. They are typically structural requirements of the embodiment (how many cycles in how much time, how much work done with how much resources), restrictions of performance envelope (an upper limit of acceleration, a lower limit in total capacity), or functional conditions (some response must occur whenever an event occurs).

In design, deciding what to build is based on satisfying the judgement of a person. This could be the design themselves (intuitive design), an end user (user-centered design), or a stakeholder (a mixture).


These appear to be poised opposite each other on a spectrum of hard and soft requirements. But that assumes solving the problem of what to build is simply mechanical. Problem solving is creative and involves synthesizing existing solutions in appropriate combinations as well as introducing novel solutions to the context. Both a designer and an engineer rely on a set of heuristics to build a solution, including the introduction of any sort of formal design process.

Trade offs

It is this aspect that ties engineering and design together. Both require space for ideas to be pieced together and evaluated. In any non-trivial situation, the addition or subtraction of an element affects the performance of the solution in a complex way.

A user experience design is not simply a set of steps to walk through. It must consider the holistic experience of many different types of people. It needs to take into account what is practical.

Similarly, an engineering solution is not simply the set of components involved. It isn’t even the much larger set of combinatorial ways that the components could be arranged. It must consider flexibility to meet future conditions and extensibility. A solution must address maintenance and the skills and abilities of the team who will maintain it.

Learning from each other

Both design and engineering involve sending something out into the world, with all the complexities and messiness that exist there. Both disciplines can benefit from each others’ traditional approaches because of their commonality in purpose. Practicing design with an engineering background brings the strengths of formalism and frameworks. Solving engineering problems with the eye of a designer informs a holistic view of what engineering is and what it can do.

In my career experience, the most successful engineers are those that understand and can articulate the design-inspired, user-centric parts of their solution. I am curious to see if the reciprocal relationship exists in the world of design.

Timing concerns of delay line style memory

Circuit diagram of a delay line style memory system.
Delay line memory simulation. 32 bits are stored in four 1-byte addresses.

I was getting bent out of shape that I needed to somehow reconstruct the system clock out of the data stored inside a delay line. But fooling around with an old discrete delay line simulation in a circuit simulator by replacing the giant stack of flip flops with a proper length delay line shows that I don’t need to be too concerned

As long as

  1. The delay line stays a constant delay length in terms of time (dubious)
  2. The system clock stays a constant speed (actually very easy because amazingly stable crystal oscillators are trivial nowadays)

Delay lines varying in time is

  1. Highly probable with any sort of rotating media (magnetic drums, etc)
  2. Less likely for “solid state” delay lines such as acoustic torsion delay wire.
  3. Unknown for any other technology (tape loops?)

For rotating media or tape loops, it would probably be good to assume they require a second timing track. It’s somewhat of a “waste” of media density, but you should only need one per media – so one track on a drum or one track on the tape. You can have as many other tracks as you can cram on there.

For the more stable media, where the main drift is due to temperature, there could be some type of calibration mode where a signal is put into the delay line and then compared to the current clock speed. The clock speed could then be adjusted to match. This could even be automatic – perhaps something you would perform once on startup, and then once again when the machine is up to operating temperature. Of course any thing that is temperature dependent is probably best handled by installing a heater and keeping it at a steady 100degF (or whatever) no matter what.

Audio Digital Delay with DRAM and Arduino

Aka “ADDDA” or “AuDiDeDrAr” or “aww dee dee drawer” or “A3DA”

I’ve had this idea bouncing around in my head that you could use 1-bit wide DRAM as a delay line if you simply counted up through it’s addresses, reading and writing as you go. 1-bit wide DRAM like the M3764 have separate pins for Data In and Data Out which makes the read-and-write method easier.

The light bulb moment was coming across an old post on where one commenter provides a short snippet of code to do a Delta-Sigma analog to digital converter using the Arduino’s analog comparator pins. I had planned to do this purely in software by using the normal ADC pins and then calculating the Delta myself. But the built-in comparator makes this dead simple!

You can just see the OKI DRAM chip under all those wires.

So armed with an easy way to generate a one bit wide data stream from an analog signal, I went about hooking up the DRAM chip to a clone Arduino Pro Mini. There are quite a few “test a DRAM chip with an Arduino” projects out there, but the datasheet for the OKI chip has good timing diagrams that give the jist of what you need to do. DRAM has a shared set of address pins for the row and column you’re selecting, which you can think of as two halves of the full address. To get those halves in, you put the row on the address lines and strobe the /RAS pin. Then you put the column on the address lines and strobe the /CAS pin. Then your data is on the Data Out pin. Writing involves putting the data you want to write on the Data In pin and strobing the /WE pin after you strobe the /CAS pin. That’s really all there is to it. You’ll see that there are some short cuts you can take to speed up access, like only setting the row once for any number of columns you’d like to access. You can also read the Data Out pin right before writing new Data In. I do both of these in my implementation to increase the sample rate.

To start out, I did everything very simply, using the built-in Arduino functions to make it easy to read and understand. I then measured the performance of the main loop by looking at the Sigma-Delta signal’s minimum change period. This gave me a base line, and then I systematically went through the code swapping out the built-in functions for faster implementations one by one, measuring any increase in performance. If a change didn’t lead to any improvement, I wouldn’t commit it. Instead I’d commit a comment that I’d tried it. In retrospect, it’d have been better to use git revert so I had a better history of what I specifically tried.

Here I am demonstrating the delay at maximum delay length. I add some feedback to make it act like a reverb towards the end.

Doing this I was able to improve the performance of the DRAM access by a factor of about 16. The original version took 8 seconds to cycle through the entire memory and the final version took about 500ms. My commits show the improvements, although I realized later I was measuring the wrong signal! It was at least indicative of the improvements. All of the timing in this project has a lot of jitter due to the many different possible code paths with no attempt to balance them out.

In the end, the DRAM /WE pin is the best measure of how often you’re writing to the DRAM. It is at about 139 khz. I measured the actual audio delay produced by the system using my oscilloscope and it is about 480 ms at it’s longest. Those two numbers agree:

1 second      | 64*1024 samples           seconds
--------------|----------------- = 0.471 ---------
139 k samples | 1 buffer                  buffer

I’m new to working directly with delta-sigma converters, and after reading a few pages about it this morning, I’m not sure what I’ve built is exactly a delta-sigma converter at all!

My current understanding is that 139 khz sampling rate (F) means a Nyquist frequency (F/2) of 69.5 khz regardless of the type of converter used. I found a paper by Aziz, Sorensen, and Van der Spiegel from 1996 describing how delta-sigma converters work, and it gives some equations.

Letting the oversampling ratio, f_s / (2 * f_b) = 2^r …

[Therefore] every doubling of the oversampling ratio i.e., for every increment in r, the SNR improves by 9 dB, or equivalently, the resolution improves by 1.5 bits.

Aziz, P., Sorensen, H., & Vn Der Spiegel, J. (1996). An overview of sigma-delta converters. IEEE Signal Processing Magazine, 13(1), 61–84.
f_s -> sampling frequency
f_b -> signal bandwidth
r -> oversampling

f_s / ( 2 * f_b) = 2^r

f_s / 2^r = 2 * f_b
f_s / (2 * 2^r) = f_b
f_s / 2^(r+1) = f_b

139e3 / 2^(r+1) = f_b
r = 0, 139e3 /  2 = 69.5 khz,  Nyquist sampling
r = 1, 139e3 /  4 = 34.7 khz, +1.5 bits
r = 2, 139e3 /  8 = 17.3 khz, +3.0 bits
r = 3, 139e3 / 16 =  8.6 khz, +4.5 bits
r = 4, 139e3 / 32 =  4.3 khz, +6.0 bits
r = 5, 139e3 / 64 =  2.2 khz, +7.5 bits

Those numbers would suggest a fairly lofi device. And certainly what I have running on my desktop is by no means producing quality audio. But it also doesn’t sound that bad? I’m losing a bit in my calculations because I should be counting the “single bit” of the comparator. If we take that bit and then work it backwards…

f_s / (2 * f_b) = 2^r
total_bits = 1.5 * r + 1
8 bits = 1.5 * r + 1
r = 7 / 1.5 = 4.667
139e3 / 2^4.667 = 139e3 / 25.398 = 5.47 khz

So the system is operating at 8 bits up to a bandwidth of 5.47 khz. That sounds about right. What happens if I add more features and reduce the sampling rate to 100 khz?

100e3 / 25.398 = 3.94 khz

What happens if I find some optimizations and increase the sampling rate to 200 khz?

200e3 / 25.398 = 7.87 khz

Someone check my math.

I vary the delay length from max to about minimum, then set it somewhere in the middle. The reverb feedback is still applied because that makes it easier to hear the changes in delay length.

National Semiconductor 4510 Mathematician

I have a small collection of vintage calculators that I stumbled into collecting. I found one at a garage sale, and then one was given to me, then I found a neat one on eBay for a good price… Before I knew it, I was a calculator collector.

I actually use most of them despite having a great calculator app on my phone because I prefer their physical interfaces. I have one on each desk and one in my bag so I don’t have to go searching. I don’t have that many bags and desks though so there is also a small stash in a drawer.

The brown and tan color scheme is very 70s. I think they’d have used wood grain print adhesive vinyl if they could have.

My latest addition is a National Semiconductor 4510 Mathematician from the mid 70s. It has an 8 digit red LED display and runs on a 9 volt battery. There is a jack on the top edge for connecting a wall supply if you’ve got a lot of math to do.

It is in great condition and the seller even included a brand new battery. It is one of the lesser RPN calculators of the 70s and not expensive. Like most of my collection, is not valuable but it is uncommon.

This model isn’t programmable although they made a version that was called the Mathematician PR. Those are a little bit more rare but their programmability is so limited that I didn’t want to deal with finding a nice one at a price I wanted to pay. I also know that personally I do not use the programmability of much nicer calculators I already have so it wasn’t something I’d use anyhow.

What makes this model stand out is its RPN entry method. If you’re not familiar with RPN, there are some great introductions online. I tried to explain it recently and was told that it sounded insane. You get used to it! It starts to make sense… eventually.

This model’s main downside is that it doesn’t do scientific notation, so the range is limited. Some of the math I do most often is around calculating values for circuit components. They are specified in orders of one thousand units. So for example, resistors are commonly available in units of ohms, kilo ohms, and mega ohms. This means you do a lot of math with numbers involving 10^3 and 10^6. Capacitors are similar but much smaller units. You often deal with pico farads – that’s 10^-12. So I’ll have to keep track of the exponents myself when doing those kinds of calculations.

The NatSemi Mathematician is delightfully slow for some operations. For example computing a logarithm of a number is slow enough that the calculator displays an animation of sorts to show that it is “thinking”.

Computing the natural logarithm of pi takes long enough for you to wonder when you’d ever want to know such a value.

I don’t know how much I’ll use this addition to my collection. If I leave it where I can see it, I’ll use it occasionally if only as a muse for an earlier time in computing history.

From the notebook: Tape Transports

Todays notebook sketch is some ideas for building a tape “transport” – the mechanical bits that move the tape around in the right way and at the right tension.

Three transport configurations and my current thinking on a capstan.

I have a weird fascination with magnetic storage media and tape in particular. It was a key technology in computing for decades and it has more or less completely disappeared.

All that time in home, commercial, and industrial use has left lots of bits and bobs to experiment with, although it is very very quickly disappearing.

Other than the playback and record heads and the media itself, the devices can be recreated from scratch. (And let me get back to you on making heads and media…)

Prototype Game of Life Synth Module

Conway’s Game of Life (CGoL)has always fascinated me. It is probably the most well known of all cellular automata and also probably the most intuitive. Yet even simple patterns can turn into complex sequences of shapes, patterns, and noise.

Years ago, when learning about the HTML5 WebAudio API, I came across a fun little demo called Blips of Life by Mike M. Fleming. Use your mouse to draw some dots and then click the triangle Play icon in the bottom left. Great, right? I’ll let you play around with that for a while. Leave it running while you read, perhaps?

This is in 1U Eurorack format.

When it came time to start prototyping new modules for my modular synth, I was inspired to recreate Mike’s work in hardware. I didn’t have exactly the parts to fully recreate his Blips of Life, but using the parts I had in hand I made a prototype.

My version has only an 8×8 grid and only has a major pentatonic scale. The small grid means that there are fewer possible patterns, although not so few it is monotonous. The major pentatonic scale is fine. The largest problem with the prototype is that I used CircuitPython to write it, which has no interrupt support. I love Adafruit – they’re a great company and they design terrific boards. But removing interrupts from their fork of MicroPython has cut several projects short.

The prototype works pretty well and exposed a new design challenge: how do you deal with “games” that end in loops? They’re a subset of steady state patterns in CGoL – a pattern can go “extinct”, “steady”, or loop in a finite sequence. The first case is easy to detect and deal with. If all the cells of the grid are off, repopulate the board. You can detect a steady state by comparing the next board with the previous. If they’re identical, repopulate.

But loops can be any arbitrary length, and can step through rather complex patterns. The only way I know to detect them is to have a list of boards known to be part of or lead to a loop. I’ve got some ideas how to do that either via live loop detection or with a precomputed list of boards. As yet, the performance limitations of CircuitPython really prevent tackling it. I’ll need to reimplement the code in C++ using Arduino. Hats off to Adafruit for supporting both Python and Arduino on their boards.

Book recommendation: Turing’s Cathedral by George Dyson

If you’re interested in the early history of computing, check out Turing’s Cathedral by George Dyson. It covers an interesting middle phase between the original electronic digital computers and the wide commercialization of computers in the late 50s.

The cover of the book recalls a punch card.

Specifically it examines the people and development around “the IAS machine” at the Institute for Advanced Study at Princeton. Big and not as big names make an appearance, and it is a detailed account of the forces at play: academia, industrial, military, and political.

The design of the “IAS machine” was the pattern for dozens of machines around the world. More than one country’s “first computer” was one built using the design developed by the people at IAS. I think of it as the first practical computer – the construction needed to solve a lot of problems that the original electronic computers didn’t need to address because they were just struggling to exist.

I’m not going to lie: there are a lot of “white men in ties” involved.

It’s been a while since I finished the book, but I do refer to it when I need details of how some design constraint was surmounted. It also includes enough biographical information that I use it to jog my memory of exactly who was who. The world of computing was still small enough that people who contributed to the IAR project show up in other places pretty often.

It’s widely available. It looks like Thriftbooks has it for under $5, so you could get it for free if you’ve got some reward points there.