There’s a pattern which shows up everywhere in programming, often disguised as something else. Once you see it, you can’t unsee it. I don’t think it has a single name. But I can give many examples! The pattern is, in an abstract sense:

1. Generation: Take an input dataset and apply a function to project it into a different shape
2. Restriction: Write another function which restricts the results of that function to only those which are “interesting”
3. Reduction (optional): Write yet another function which reduces this to a single value, say, by summing the results or picking the minimum, or just taking the first result that comes in

The Prolog community called the naïve form of this “generate-and-test” since at least the 1980s:

“Generate-and-test is a common technique in algorithm design and programming. Here is how generate-and-test works for problem solving. One process or routine generates candidate solutions to the problem, and another process or routine tests the candidates, trying to find one or all candidates that actually solve the problem.”
– The Art of Prolog by Leon Sterling and Ehud Shapiro (1986)

Formally, this is called the constraint satisfaction problem.

The Abstraction

In case this isn’t absolutely clear, let’s look at some JavaScript which uses the brute force method to solve problem 9 of Project Euler:

A Pythagorean triplet is a set of three natural numbers, a < b < c, for which $$ \begin{align} a^2 + b^2 = c^2 \end{align} $$ For example, 3² + 4² = 9 + 16 = 25 = 5².
There exists exactly one Pythagorean triplet for which a + b + c = 1000.
Find the product abc.

Ok, we can do this in a one-liner:

const result = 
  // Generate numbers [a, b, c] where a + b + c = 1000 and a < b < c
  Array(1000).keys().flatMap(a => Array(1000).keys().filter(b => a < b && b < 1000-a-b).map(b => [a, b, 1000-a-b]))
    // restrict to Pythagorean triples
    .filter(([a,b,c]) => a*a + b*b === c*c) 
    // Reduce to the product
    .map(([a,b,c]) => a*b*c).take(1).toArray()[0];

This looks incredibly simple! It’s not a “pattern,” it’s one line of code!

The abstraction really is that simple, and the implementations try to stay close to that abstraction as much as possible. However, there can be a surprising amount of complexity in how the code is executed.

Perhaps you’ve been programming for a long time and consider all of this to be very obvious? Fine, you may not get a lot from this post! However, I do remember when I was new to software development and how I might solve a Project Euler problem was not obvious to me! One thing that I specifically did not understand at that point was that brute force might be the right solution to a problem at least in an abstract sense. Having written a solution in terms of brute force we can then optimize our solution if the performance is inadequate.

I will further say that when I hear some of the dialog around agent-based programming, specifically the “it might hallucinate!” or the “look how fast I can blast out garbage!” arguments I hear from both “sides,” that I am reminded of this pattern. If you don’t restrict your solutions, with comprehensive tests or proofs, then yes, you’re going to get errors, whether you generate your possible solutions with AI or by hand.

Worked Out Examples

The same pattern keeps coming up, over and over again. Also, the implementations of this pattern vary quite a lot, so there is depth behind the seeming simplicity. You can implement this pattern in various languages, and they will be executed differently!

MapReduce

Classic MapReduce would seem to be a direct mapping of the pattern above, but I will note that it’s more of a distributed execution paradigm. Running a Project Euler problem on a cluster would be a bit silly and probably missing the point of Project Euler. But you can certainly see how the “map” (generate + restrict) and “reduce” fit in here.

SMT-LIB/Z3

Are you ready to get weird? Here is the same Problem 9 from Project Euler implemented in SMT-LIB, a pure specification language:

; SMT-LIB is pretty basic and doesn't have exponentiation built in
; So we'll define this for legibility
(define-fun square ((num Int)) Int (* num num))

; The "generation" is "all possible assignments to a, b, c"
(declare-const a Int)
(declare-const b Int)
(declare-const c Int)

; We restrict it to "those which satisfy the specification" by just writing it out!
; We are looking for a set of three natural numbers, a < b < c
(assert (and (>= a 0) (< a b) (< b c)))
; for which a^2 + b^2 = c^2
(assert (= (+ (square a) (square b)) (square c)))
; for which a + b + c = 1000
(assert (= (+ a b c) 1000))

; And we want to return the product, since Project Euler needs a single number
(declare-const product Int)
(assert (= product (* a b c)))

; This checks if there's any solution at all
(check-sat)
; This returns the solution
(get-model)

If we hand this specification to a solver such as Z3, it will use decision procedures to solve the constraints directly rather than enumerate with brute force. Try it!

It is less the case here that we are “generating” triples of integers and restricting them to those for which a² + b² = c² and more the case that we are generating possible assignments to a, b, and c and restricting them to those which correctly satisfy the specification we have given.

Prolog

Similarly, Prolog lets us directly encode the problem from the specification:

answer(Product) :-
    between(0, 998, A),
    % a < b
    between(A, 998, B),
    % a + b + c = 1000
    C is 1000 - A - B,
    B < C,
    % a^2 + b^2 = c^2
    A*A + B*B =:= C*C,
    Product is A * B * C.

One way to think about what Prolog is doing here is that we are not so much writing a generator and restriction function as we are binding the input arguments A, B, and C to the output Product.

Still More Examples

I will spare you the implementation of Project Euler problem 9 in SQL, but this pattern is applicable to many problems in programming!

For example, when fuzzing, we take a bunch of random inputs, restrict them to those which crash or trigger AddressSanitizer, and then reduce the output by running a corpus minimization.

When doing agent driven development, we can generate many programs very quickly, but they might be incorrect! If we have a formal proof of correctness then we can reduce the set of candidate programs to those which satisfy the specification. Agents turn out to be quite good at finding such programs. But without a proof, we might end up with something sloppy!

In classic TDD, we start with a system under test which we are modifying (in effect, generating lots of candidate programs). Our restriction is the test suite, and we reduce this via a pass/fail verdict – do the tests pass?

Measuring Generation and Restriction Efficiency

The last example, TDD, might feel a bit unsatisfactory. One can imagine trying to solve Project Euler problem 9 via TDD:

  // Arrange -- choose some random inputs as a first trial
  var a = 1;
  var b = 2;
  var c = 3;

  // Act
  var actual = Euler.sumOfSquares(a, b);

  // Assert
  Assert.assertTrue(a < b);
  Assert.assertTrue(b < c);
  Assert.assertEquals(1000, a + b + c); // Fail!
  Assert.assertEquals(c * c, actual);   // Fail!

I kid, I kid. Java can do brute force, just like JavaScript, even if TDD purists might sincerely suggest the above as a good starting point. But nonetheless, this example does indicate a difficulty with TDD: Finding meaningful inputs for your problem space.

“…program testing can be used very effectively to show the presence of bugs but never to show their absence.”
– Edsger W. Dijkstra, On the reliability of programs

This might be a helpful way to judge implementations of the constraint satisfaction problem: How much data does the generation produce, and how effective is the restriction step? Can programs written using this pattern go wrong?

Let’s consider the problem of finding bugs in source code you’ve produced. We generate candidate bugs and then apply some test to figure out which candidates are actually defects. (For example, a static analyzer might look for string concatenation in SQL statements and then attempt to restrict reporting to those instances where the data being concatenated is user-controlled.) Generation can be too sparse to find bugs or so dense it overwhelms you. Restriction can let real bugs through or flag false positives. Both axes can fail in two directions.

Lest you consider me too judgy for the table above, I don’t mean to suggest that you should not, for example, use static analysis due to false positives! Static analysis is a fantastic way to avoid bugs, even if you must occasionally suppress a false positive. Still, the ideal static analyzer would have no false positives. Indeed, all of the techniques listed above have their place, but I do think that the table is honest about their shortcomings.

Embracing Constraint Solving

These examples show the constraint satisfaction problem hiding in plain sight. Every tool above is making the same two decisions any constraint-satisfaction approach has to make: how to generate candidates, and how to test them. SMT solvers generate via decision procedures and test via assertions. Fuzzers generate via mutation and test via sanitizers. Type checkers generate via inference and test via unification. Even TDD fits the pattern, with the developer playing the role of the generator.

Recognizing this pattern lets you compare tools on the same axes — execution model, generation density, and restriction tightness. Pick the one whose performance and failure mode you can live with for the problem in front of you.

The most important thing I want you to take away from this post is to look for constraint solving solutions to programming problems in front of you. When you see one, don’t be put off by questions of efficiency or false positives. There are solutions to those! But by recognizing the abstraction you can focus on the most important part, which is correct generation and restriction.

The mxi x es.EDU sequencer can play loops of 3, 4, or 5 notes. It can output a new control voltage, which is commonly routed to oscillator pitch, and a gate, which is commonly routed to an envelope generator, on each step of the sequence. Why 5? In the instructions, Moritz Klein says, “I simply made the decision to build a sequencer with five steps exactly,” although I suspect the fact that this is already a fairly complicated build and adding more steps would have only increased the complexity might have figured into it.

Also, why limit your sequencer to only 4 steps? This one goes to 11 5!

Commercial hardware sequencers often feature maximum sequence lengths of 16, 32, 64, or even higher number of steps, but that would make the module very large, both in terms of the number of components you would need to assemble and in terms of its physical size. As it is, this is the first module I have built from this series which requires two full-sized breadboards to prototype.

Breadboarding

The headings in this section correspond to the headings in the instructions for this kit, in case you would like to follow along.

Breadboarding the sequencer gave me a somewhat surprising amount of trouble! Part of this is due to the fact that I didn’t have two full-size breadboards available. Instead I used a full sized breadboard and two half-sized breadboards. This meant that I had to perform some mental arithmetic when connecting leads to the op amp chip, which is a great opportunity to make mistakes!

Counting with Chips and the Clock Generator

The first step is to build a five step LED counter and clock generator. When I turned on this circuit, I saw no LEDs lighting.

Well, this was a good opportunity to practice my debugging workflow. The first step is to look for obvious problems such as power. And this very well could have been the issue as this module requires two breadboards, and the power distribution of +12V, -12V, and GND across two breadboards is somewhat complex! But testing with my multimeter showed I had wired this correctly. I also checked that I had connected the correct IC pins to the power rails, which is a little bit tricky here as there are two ICs with different power pins, but I had done that correctly as well.

The second step is to have a model of the circuit. Here, my model is quite simple: A square wave clock generator makes the sequencer step with every pulse, causing the LEDs to light up one at a time. So given my observation that none of the LEDs were lighting up, the issue could have been that I had miswired all of them, that the sequencer IC was dead, or that the clock generator was not pulsing.

I suspected the clock generator, and testing with my oscilloscope confirmed that it was not generating a square wave. Looking closer at that IC it turned out that I had made an “off by one” error on some of the wiring on the breadboard – I had used pin 51 instead of pin 50, for example. Fixing this made the LEDs light up.

Resetting the Loop

The next step was to limit the sequence to 5 steps (instead of 8 steps, supported by the chip, but not required for this module). The instructions say:

So by connecting step six to the reset pin, we jump back to the first step as soon as we try to move past step five. Testing this on the breadboard is as easy as connecting step six and the reset pin with a jumper.

In fact, an additional step is necessary. I added a jumper as described and I found that it had no effect! I turned off the circuit, and tested continuity between the IC pins; there was no problem there. I thought that perhaps the breadboard wasn’t making a good connection, but this was fine.

(I will use this symbol ⚠ when I discuss areas where I think the instructions require clarification.)

Next, I turned on the power and tested the voltage along this wire with my oscilloscope. I saw no jump when the sequencer got to step 6, although further testing showed that it did jump on step 7 and 8. Then a light went on for me. The reason that the voltage didn’t change was that in the previous step we had wired the reset pin to ground. Jumpering the reset pin to pin 6 meant that pin 6 was now wired to ground, which is where all the electrons were now going! ⚠ So looking more closely at the instructions, the diagram does show the jumper to ground removed in this step, but it’s not mentioned in the text. Removing the connection between ground and the reset pin made the circuit work.

The CV Output

Next we (temporarily!) disconnect the LEDs and instead wire up five potentiometers for setting the pitch CV at each step of the sequence.

This was challenging due to breadboard issues. Both the “split” lower breadboard and the usual breadboard issues (poor connections) presented difficulties, but I eventually got it working. It transpired that the five potentiometers along the bottom of the board were not making good electrical contact with the inside of the breadboard, but figuring out which components were not connecting well was challenging!

CV Scaling

The next step is to scale the range of the sequencer output down from 0-12V to 0-5V. We do this by adding a resistor and a trimpot to reduce the voltage going into the buffer op amp at the output. I had a couple of problems here. The first was that the indicated placement of the trimpot was right on the border between my two half breadboards. ⚠ The second was that the indicated placement wouldn’t have worked even if I had a full-sized breadboard, because the instructions call for a trimpot which takes only a single row of the breadboard (like the trimpots supplied with other kits in this series) and there are only two rows on the breadboard free for it in the suggested layout, but the actual trimpot supplied with this kit is square and needs three rows:

So I had to do some gymnastics with my breadboard routing.

Second, I had a momentary heart attack because the bill of materials says that two 2kΩ trimpots (and one 5kΩ) are supplied, and I only got one. ⚠ But this seems to be an error, as only one 5kΩ and one 2kΩ trimpots are needed to build or breadboard the kit.

In the end, though, everything worked, and this step gave the five potentiometers used to adjust the pitch of the sequenced notes a more useful range.

Status LEDs

⚠ Wiring the LEDs again seemed pretty simple, but at first they didn’t work. The directions, which so carefully specified their orientation when we first placed them on the breadboard, don’t mention moving them, and more importantly don’t mention that you have to rotate them 180º, which is less than obvious in the illustration:

However, once I figured out what my mistake was, everything worked:

The Gate Output

I found this section of the directions a little difficult to understand until I skipped backwards in the directions to the section entitled “Sequencer Basics.” My confusion mostly stemmed from the fact that we don’t connect the gate switches when breadboarding. This is quite understandable given how full the breadboards are without them, but it made understanding the reason for the gate output sub-circuit more difficult to intuit. That section clarified how the switches were supposed to work, which, in turn, made the explanation of how this sub-circuit worked clearer. Also, looking at the simulation helped. After that, it was just a lot of wiring, which did indeed produce a square wave output at the gate jack. Which feels like a lot of work given that we already have a square wave at the clock output, but the switches, which we don’t wire when breadboarding the circuit, will allow us to “disable/suppress” some of the square wave cycles when we build the actual circuit, resulting in only some of the five notes triggering the gate output.

The Failsafe Gate Output

This step was quite easy to breadboard. In order to change the gate output from one (breadboarded in the step above) which ranges from 0V-6V to one which ranges from 0V-12V, we replace the op amp with a voltage divider at the input with a comparitor (which changes the output to either -12V or 12V), followed by a diode and resisitor (limiting the voltage to just positive values, so that it becomes either 0V or 12V), followed by a transistor emitter-follower buffer. Why this configuration (comparitor, diode, and transistor) and not just replace the op amp buffer before the gate output with an op amp in amplifier configuration? I don’t know (I guess maybe you might be concerned that an external source would give you a gate which is not a square wave, and hence you might want the comparitor in the signal path?), but in the end the circuit works well enough.

Building the Sequencer

In contrast to the other modules I have built from the mki x es.EDU series, the sequencer has only two horizontally mounted resistors, and the rest of the resistors are mounted vertically in order to squeeze all of the components onto the board. Although it doesn’t look much more complicated, perhaps due to the vertical resistors, there are probably 50% more parts on this board than in the other modules I have built so far. In general this module required more soldering than other modules from the series. Despite this, assembly went smoothly and everything worked the first time I tried powering it up.

⚠ The 1nF capacitor (C2) was ceramic, per the supplied parts and the bill of materials. However, the soldering instructions and the photos showed a film capacitor instead. Because the soldering instructions have you insert ceramic capacitors and film capacitors in separate steps, they only show 5 ceramic capacitors (C3-C8) in the first, ceramic capacitor step. This means that they don’t call out the fact that one of the supplied ceramic capacitors is a 1nF capacitor, in contrast to the remaining 5, which are 0.1µF, although all of them look identical except for the printed values on the side.

When soldering non-flush-mounted components, such as vertical resistors and transistors, I find it helpful to solder one lead, then turn the board over to correct the position of the component, then solder the other leads.

Here are some photos of the finished build:

Using the sequencer is somewhat challenging as you have to set the pitch of each note – from a range of 5 octaves or so – with just a single potentiometer. And the pitch will drift as the components warm up! Analog synthesis has its advantages and disadvantages!

Resources

Instructions

• mki x es.EDU Sequencer User Manual

Product Pages

• EDU DIY Sequencer
• mki x es.EDU DIY System

Community

• Modwiggler thread
• Modulargrid page

Simulations

These simulations are by Moritz Klein

• Basic Op Amp Examples/Op Amp-Based Clock
• Basic Gate to Trigger/Cut Out Negative Spike
• Scaled CV Output
• Simple Individual Gates
• Comparators/Emitter Followers/The Failsafe Gate Output

Videos

• Introducing the mki x es.edu DIY sequencer kit by Moritz Klein (5:51)
• Designing a simple 5-step sequencer from scratch by Moritz Klein (32:07)

“It was the best of times, it was the worst of times…” -Charles Dickens

My first professional software development job was producing statistical analysis and simulations of physics experiments at the AGS accelerator. My deliverable was the output of the software, not the software itself. Therefore, a “deployment” meant “recompiling and executing the software on my local machine.” This was awesome, in spite of the fact that I wrote the software in FORTRAN. My cycle time was soooo low!

My second professional software development job was working for an ISV starting in 1999 (Y2K fixes!). We produced client/server software which other businesses would install on their local networks. A deployment meant building the software (during my stay there we went from building it on a developer’s local machine to using a dedicated build system) and burning it onto a CD-ROM. After some testing the CD-ROM would be mailed to customers (yes, through the postal system, and accompanied by printed, bound manuals), who could then (optionally!) install it on their systems. We did this roughly once per quarter.

Decades later, these two jobs represent the fastest and slowest release cycles, respectively, I’ve experienced.

Continuous Deployment

I will be using the phrase “continuous deployment” in this post to mean “as soon as you push a commit, that change is integrated and deployed to customers.” I want to call this out because it is different from continuous integration or continuous delivery, which do not necessarily result in your changes being immediately visible to customers.

The DORA metrics encourage us to optimize the deployment process as much as possible. Three of the four metrics, “Change Lead Time,” “Deployment Frequency,” and “Mean Time to Recovery” tend to improve if you can get code changes in front of customers as quickly and as frequently as possible. For good reason, I think. Others have written about this, so I won’t go into detail, but I do think that shipping software frequently minimizes both the time to receive feedback and the overall impact of any bugs in the new version. It forces you to think about how to make the overall experience of an upgrade to a customer as non-disruptive as possible.

However, and this is what I actually want to examine in this post, the phrase “as frequently as possible” is doing a lot of heavy lifting here. What does “as frequently as possible” actually mean?

It depends.

Constraints on Deployment Frequency

Let’s assume, for the sake of argument, that your goal is to deploy as fast as possible: You change a line of code, and you can instantly test it in production. (Perhaps you disagree that this is a good idea, but I think it does represent an extreme case of deployment speed, so it’s a useful scenario to examine.) One big advantage of this model is that it forces you to eliminate customer downtime in deployments.

Inefficiency

There are some things that tend to slow this down which we can handwave away as inefficiency. For example, a compile/build/automated test/deploy step might take time, but perhaps this could be greatly optimized? Some very lengthy tests, such as fuzzing, can be run post-deployment or split into pre- and post-deployment phases. I think “testing in production” can actually be a very correct and practical thing to do in many cases. It can be the only way that you find certain performance issues prior to customers finding them. Depending on the scale of your production system, doing a load test in a preproduction environment may not be representative of the actual user experience in production. You can fix these with another update, hopefully before a customer sees them.

Trust

Other factors are harder to dismiss as inefficiency, though. Remember my second job? The customers would decide when or if they wanted to install the update on their hardware. We live in an age where vendors seem to want to control which updates are installed on hardware we own, but I do cling to a somewhat romantic notion that we should control our own devices. Now I may choose to let the OS vendor install critical security patches without notifying me first, but it is my choice. Similarly, you need to build a lot of trust with a customer who has hundreds or thousands of employees working on software that you produce before they will let you update it on your schedule, during their critical work. If you tend to badly break the software during an “upgrade,” the customer will want to minimize updates or confine them to less critical times.

Complexity

Also, deploying to a customer environment might not be simple! I loved this talk, “Update on Update,” by David Pacheco about how Oxide is improving their update process. Their existing process is essentially “an Oxide employee updates the software remotely.” The process they want to move to is “a customer can download and run a self-service program which will do the update.” Both of these scenarios currently involve downtime on the rack, but they would like to minimize or eliminate downtime. Automating the update, unsurprisingly, turns out to be a very hard problem, for reasons which mostly boil down to “there are a lot of interdependent components on an Oxide rack.” One other limitation discussed in the talk is that some of the production Oxide racks are air-gapped; simply pushing software over the internet is not an option for these. So there are two overall limits on deployment frequency here: The first is that the upgrade process is not currently simple and Oxide is working very hard to make it an “execute a script” experience. The second is that the Oxide rack owners will still get to choose when to apply an update. Dave’s talk is fantastic; I recommend you watch it!

Gates

If you’re developing a native mobile app (or another app store with a review process), deploying to an end user might be a several weeks long back and forth between you and an app store reviewer in the worst case, and many hours on average. “Instant” deployment to a mobile user is simply not possible with a native app. Apple recommends continuous delivery rather than continuous deployment.

For other types of applications, even the hardware owner might not have the option of saying “please update our systems continuously.” I have worked in heavily regulated environments (utility billing) where upgrades to some parts of the system needed to be reviewed by government regulators before they could be deployed. This imposed a hard limit on deployment frequency. I have heard similar stories about people who produce software which is used in classified environments. In such cases you can discuss increasing the deployment frequency with the gate managers, but it’s never guaranteed that they will say yes!

How Fast Is Too Fast?

Above, I assumed that you are trying to deploy changes to production as fast as possible: “You change a line of code, and you can instantly test it in production.” I do not actually believe this is a good idea! In practice, I want to, at a minimum, run a compiler, linter, unit tests, integration tests, security scans, etc., before deploying. In other words, the standard integration process. Before I do that, I’m going to manually test my changes locally, and in many cases I will ask another developer to review them. This takes time, which I think is time well spent!

“Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.” -Charles Goodhart

The danger with metrics, of course, is that you can pursue them to make the “line go up” instead of looking at what you are actually trying to measure. I do think that the DORA metrics are some of the most useful measurements that one can make about a software project, but the results should be discussed, rather than shown on a dashboard. Skipping peer review of important changes to shave a few hours off of your Change Lead Time would be a bad trade, I think!

Similarly, some of the hours spent waiting for app store approval is Apple or Google doing automated vulnerability scans on your apps. A developer can of course do do this themselves, but experience has shown that not everybody bothers.

So when you hear phrases like “you should deploy changes to customers as fast as possible,” I think it’s important to hear “as fast as possible” rather than “as fast as …”

One Size Fits Most

“One size fits all” clothes tend to be a compromise. They never fit as well as a tailored garment. Similarly, I am suspicious of people who assure me that continuous deployment is always possible or even desirable in every situation. I think that continuous deployment is a reasonable default position for starting a discussion about deployment, but I do not think that it is always the best strategy. Continuous deployment can be useful as an “ideal” even in cases where a huge (and perhaps insurmountable, given other business needs) amount of work is necessary to make it happen.

Being as you are a devoted reader of my blog, I presume that you already know a thing or two about computer science? But what if you didn’t know anything about computer science? What if you decided to learn about it by building analog synthesizers?

That’s the premise of my upcoming talk at CodeMash.

This presentation is an alternate history of your own journey learning computer science. If you started learning all over again, and instead of reading books on C# development or watching videos about Vue.js, you decided to become a developer by building hardware analog synthesizers instead, what would the programming world look like to you? Imagine that the first computer you used was analog instead of digital, that you learned about abstraction from op amps instead of base classes, and you had to solve problems with an oscilloscope instead of a debugger. You might be very good at understanding computational abstractions! Building an analog synthesizer from electronic components is a fun way to learn about electrical engineering, but it also holds many lessons about computer science. In this delightfully strange talk, we will build several computational models from the transistors up, learn how to debug from first principles, understand dynamic typing in terms of modular synthesis, and also have a bunch of beeps, blorps, and solder.

My goal is to have the strangest presentation at CodeMash. We will see if I succeed. If I don’t, I hope I’m in the audience for the even weirder one.

This is the second chapter discussing the VCF build; if you haven’t already read the first, you might want to start there. As a reminder, “VCF” stands for “Voltage Controlled Filter.” A VCF can be any kind of filter; the mki x es.EDU VCF is just a lowpass filter. The “Voltage Controlled” for this kit means that we can control the filter’s cutoff using a control voltage signal, such as one produced by the envelope generator. Using an envelope generator allows us to vary the filter’s cutoff over the course of a note, which makes it sound more interesting. Of course there are many, many more ways to use a VCF!

Assembling the PC Board

This turned out to be a fairly easy build. Everything worked correctly after initial assembly. I made one mistake, which was accidentally melting two of the capacitor housings a bit with my soldering iron (I work under a magnifiying lens, and this was out of sight!):

One tip I found handy: Before installing the trimpot resistor, set it to the middle of its range using your ohmmeter, because it’s hard to tell where it’s set once it’s in the circuit. From there you can easily adjust it up or down as needed. I found it needed not adjustment at all, however!

A couple of other views:

Matching Diodes?

While I was building this PC board, I noticed something a bit strange at the top. There were two spaces for diodes, for which no extra diodes were supplied in the kit.

This was not mentioned in the directions, but I found reference to them on the schematic:

There are two links on the schematic, and they go to an article on diode matching and another on how to measure diodes with your multimeter. The latter is clearly aimed at people who have never used diode mode on their meter before. (No shade intended here! We all need to learn!) The former is sort of interesting, but I can’t understand why this little circuit is on the board at all, because, as Moritz notes:

• Careful matching of diodes is not needed for this circuit
• If you were going to build the circuit from the first link to carefully match diodes, it would make a lot more sense to do it on a breadboard than to solder the diodes onto a PC board temporarily!

So, I didn’t bother to match my diodes. I guess it might make sense to do that if I was trying to build the cleanest filter imaginable, but in this case I prefer a kind of crunchy sound!

Finished!

Here we have a square wave input and three possible settings of the filter: No filtering at all, a low pass filter without resonance, and no filtering but a “medium” amount of resonance:

If you turn up the resonance still further you hear a high-pitched feedback.

Next, I connected the output of the Envelope Generator to the CV1 input of this kit, which caused the cutoff to cycle back and forth between “no low-pass filtering, but some resonance,” and and “a low-pass filter with resonance” (this is a video, press play to see it):

At this point you may be wondering how it sounds. Pretty nice! I want to put some demos together, but I will save that for a future post. Hopefully soon! However, it would be nice to have a CV source for the VCO to record a demo, so first let’s build the sequencer!

Resources

Instructions

• mki x es.EDU VCF User Manual

Product Pages

• EDU DIY VCF
• mki x es.EDU DIY System

Community

• Modwiggler thread
• Modulargrid page

Simulations

This simulation by Moritz Klein is the closest to the entire kit as built on the PC board

• Resonance II

Videos

• Introducing the mki x es.edu DIY VCF kit by Moritz Klein (5:04)
• Erica.EDU Diode Ladder Filter Kit! by Quincas Moreira (16:05)

The folling series of videos are iterations on the design of what is ultimately a slightly different VCF built by Moritz Klein. I do think they are useful, though:

• DIY SYNTH VCF Part 1: Analog Filtering Basics (21:45)
• DIY SYNTH VCF Part 2: Active Filters & Resonance (27:30)
• DIY SYNTH VCF Part 3: Resonant High-Pass & Vactrol-Based Voltage Control (29:20)
• Designing a diode ladder filter from scratch (36:03)
• Turning my diode ladder filter into a eurorack module (34:46)

Nearly all synthesizers have a filter of some kind. There are many different filter designs. Even a phrase like “the Moog ladder filter” can mean many different actual circuits. Differing filter designs can have as much to do with the character of how a synth sounds as different oscillator shapes.

A VCF stands for a “Voltage Controlled Filter,” which is similar to a regular equalizer filter except that it can be voltage controlled, which means that we can use an Envelope Generator or a Low Frequency Oscillator to vary the parameters of the filter (such as cutoff or resonance) as a note plays.

Moritz Klein’s goal when designing the mki x es.EDU VCF was to make a “classic sounding” filter with a very simple design. And when you think about how simple a low-pass filter can be – just a resistor and a capacitor, this feels like it should be possible.

Breadboarding the Filter

One really minor difficulty I had when breadboarding these was figuring out which component was which, e.g., which jack was “input” and which was “output.” Here’s the schematic, which is clear enough:

However, the breadboard layout is quite a bit less clear, and the jacks are for whatever reason never labeled in the manual. Quick, which jack is input?

(It’s the one on the right.)

This becomes considerably harder when we start using seven op amps split across two different ICs!

Passive Filter

Anyway, here’s the square wave I used as the input to the filter for my testing. You’ll soon see why I need to show this by itself first.

First we build a passive, first order filter using just a resistor and a capacitor. This does an OK job at filtering the output, but note that it also distorts the input signal as well, because the resistor and capacitor add impedance to the input side of the circuit, since there is no isolation between the filter and the input:

The purple trace above is the input square wave (distorted due to the passive circuit here), and the output of the filter is the yellow trace.

The filter doesn’t just reshape the wave; it also reduces the output at higher input frequencies. Above I’m using a 500 Hz input; here’s with a 2 kHz input.

Second Order Passive Filter

Then we add a second resistor and capacitor to make a second order filter. The output is much more like a sine wave with the second order filter. However, the input is even more distorted.

Active Filter

Next we build the active filter. Here’s the schematic:

When I first build this filter, it didn’t work. I got no output at all. After some tracing, I finally noticed that we were supposed to replace the 1 µ capacitors from the passive filter with 1 n capacitors for the active filter. Unlike the real capacitors, which are visually very distinct, the “1 µ” and “1 n” are just very similar looking white blocks in the breadboard drawings, and the schematic immediately above omits their values altogether!

Anyway, with that sorted, I then had a respectable looking low-pass filter:

Adding Resonance

Next we make the filter resonant. We do this by feeding the output of the filter back into the first capacitor, replacing its connection to ground with the filter’s output.

In the instructions and in his videos, Moritz notes that this “is basically just the filter itself swinging at its set cutoff frequency in addition and reaction to the oscillation it’s supposed to be filtering.” That’s correct, but it’s only part of the story. In addition to the filter “overreact[ing] to any sudden change in voltage at its input,” the filter also introduces a delay in the signal as it passes through the filter and then gets partially routed back into the input of the filter. The portion of the output which is fed back into the filter circuit is out of phase with the input. Both the delay/phasing and the amplification are responsible for the characteristic sound of the resonance.

Adding the Diode Ladder

We want to make the filter adjustable using control voltage. The first step is to make it adjustable at all. This kit solves that problem using diodes as “voltage controlled resistors.” I won’t bother explaining the theory here as that is very well covered in the manual, which I encourage you to read if this project is at all interesting to you. The manuals for the mki x es.EDU DIY kits are (really) great reading.

Adding the Output Stage

In the images which follow, the input square wave is in yellow, the top and bottom of the diode ladder are in purple and green, and the output is in cyan.

Some things to note here. First, the scaling is a bit deceptive. The input signal is much hotter than the rest of the traces (note its vertical scaling is 2V/div).

The output signal varies quite a bit in amplitude depending on where the filter cutoff is set, which isn’t ideal. We will fix that in the next section.

There’s a low-frequency noise, probably 60 Hz, in the output. I blame this on the noisy breadboard and low output level.

This build took me quite a while to debug. At first I found that a couple of wires were in the wrong breadboard sockets, and then after a considerable amount of troubleshooting I found a couple of resistor leads which contacted each other due to “leaning” on the breadboard. Which is, frankly, an easy mistake to make:

Still, this gave me ample opportunity to put my ideas about debugging circuits into practice!

Adding CV Processing and Output Scaling

One part of breadboarding the mki x es.EDU kits which has repeatedly caused confusion for me is, when going from one step to the next in the instructions, figuring out which parts are not needed in the next step and should be removed vs. which parts need to remain.

I think this example will show you what I mean. These two steps follow each other sequentially in the manual.

Quick, which components should I remove to go from the first to the second? Which components need to be added? No matter how carefully I work I still make mistakes. It’s another opportunity to test my debugging skills.

Anyway, after a lot of assembly and debugging, the output is much cleaner. Note that the cyan trace here (the filter’s output) has been switched to 500 mV/div, which is the same vertical resolution as the purple and green traces (which are the top and bottom of the diode ladder), and 10* less magnification than the 50 mv/div vertical resolution of the cyan trace (output, again) of the previous section.

I like this because you can really clearly see how the green and purple traces get further away from each other as the filter’s cutoff gets higher and higher. This “drags the input voltage” (into either end of the diode ladder) into a different part of the diodes’ nonlinear range, making it a variable resistor, which is what we wanted.

Resonance II

The big problem that I had getting the resonance working is that I mistakenly used the Schottky diodes supplied with the kit for the power supply in place of the 1N4148 diodes that I was meant to use. The breadboard instructions just say “diode,” although they are not interchangeable! Anyway, with the correct diodes in place I can now affect the resonance a bit, although at this point every time I touched anything I would knock off the input, one of my four oscilliscope probes, a random electronic component, etc. I didn’t want to spend a lot of effort adjusting the trimpot, which is fiddly enough without all of these other cables to bump into. Still, I can see the effect of the resonance on the leading edge of the square wave here, even if it is a bit subtle:

Anyway, now we are finished with the breadboarding!

The breadboard is by now getting quite crowded. I think this kit might be better built across two breadboards.

This post is getting fairly long, so I think I will save the PC board build for next time!

Resources

Instructions

• mki x es.EDU VCF User Manual

Product Pages

• EDU DIY VCF
• mki x es.EDU DIY System

Community

• Modwiggler thread
• Modulargrid page

Simulations

All of these simulations are by Moritz Klein

• Static cutoff/Variable cutoff
• Two stage LPF
• Active two-stage LPF
• Slightly resonant LPF
• Variable resonance
• Even number of stages/Odd number of stages
• Downwards shift/Upwards shift/Driving the ladder
• The output stage
• Properly processed CV
• Resonance II

Videos

• Introducing the mki x es.edu DIY VCF kit by Moritz Klein (5:04)
• Erica.EDU Diode Ladder Filter Kit! by Quincas Moreira (16:05)

The folling series of videos are iterations on the design of what is ultimately a slightly different VCF built by Moritz Klein. I do think they are useful, though:

• DIY SYNTH VCF Part 1: Analog Filtering Basics (21:45)
• DIY SYNTH VCF Part 2: Active Filters & Resonance (27:30)
• DIY SYNTH VCF Part 3: Resonant High-Pass & Vactrol-Based Voltage Control (29:20)
• Designing a diode ladder filter from scratch (36:03)
• Turning my diode ladder filter into a eurorack module (34:46)

Sometimes you build a circuit and it doesn’t work correctly the first time. This is especially common if it’s a new design, but even when building an existing, known-good design it might be that your specific construction doesn’t function correctly. No worries; it happens to the best of us! But you’re now staring at a hunk of silicon which doesn’t do anything useful. How can you even begin to find and fix the problem?

In the software world we call such an endeavor “debugging.” In the world of electronic hardware, doing this falls under the umbrella of “analysis,” although that also means understanding a working circuit, to a greater degree than “debugging” means understanding working code. The electronics community has informally adopted the term “debugging” for “what to do when the board you’re staring at doesn’t work,” but I find it interesting that I own several books¹ on electrical engineering and none of them have so much as a chapter on debugging circuits! It seems like such a strange omission; I guess they presume that we are learning this stuff in college and can just call a TA over if we get stuck?

It’s not that there is no interest in the topic; there are whole books on the subject. But this sort of material just doesn’t seem to be included in “introductory” texts!

Step By Step

I follow a similar process when debugging code or hardware:

1. Look for obvious problems
2. Have a model of the thing I’m looking at
3. Compare the observed behavior with the model
4. When I find a deviation of the observed behavior from the model, try making a change
5. Observe if the change brings the behavior of the system closer to the model and keep it or revert it as needed
6. If the circuit still does not work, go back to the step 2 and iterate until I have a working system

One difference between debugging software and hardware is that when I debug software I am often writing new tests which run automatically. It’s not that tests are impossible with hardware, and indeed I can see them being quite useful on complex circuits, particularly if there’s a microprocessor available to run them. Testing harnesses are common when doing mass production of circuits. But the circuits I work on are quite simple, nearly always “one off” (not mass production) and there is no microprocessor available to run a test suite, so I must unfortunately do without any tests other than manual analysis of the circuit.

Look for Obvious Problems

Without power, a circuit cannot work. It’s worth testing that the power rail is connected and at the right voltage, and similarly for the ground. Also, make sure that all parts of the circuit have the same “ground”; one problem I’ve encountered myself is when an input to a circuit (such as an arbitrary waveform generator) and the circuit itself have two different “grounds.” (The fix, in that case, was to simply connect the two grounds together with a wire.)

If you turn on a circuit and a component incinerates itself in a puff of smoke, that may give you a fairly good idea of where the problem lies! Similarly, if a component is getting hot or smelly, well, unplug the power and take a look in that neighborhood.

If you’re working on an old circuit it’s probably worth giving all capacitors a visual inspection before you start any deeper analysis. Old capacitors are prone to failure and can be tested in circuit with an ESR meter or out of circuit with a multimeter.

If this is a new circuit board that you’ve just built, a quick visual inspection for cold solder joints can save hours of debugging.

Have a Model

Actually, have two: A logical model and a physical model. To be honest, I usually have more than one logical model, but rather a tree structure of them. “An analog synthesizer is composed of several VCOs, VCAs, VCFs… A VCO is composed of an oscillator core, wave shaping circuits… Etc.” The physical model says things like, “I expect the voltage drop across this resistor to be…”

Another way to look at this is that the logical model is the “top down” point of view, and the physical model is the “bottom up” point of view. Both viewpoints are needed to solve the problem.

This is similar to how I work in code. I have a logical and a physical model of how the software should operate. The logical model is a high level interaction between components or systems, and focuses more on the specific business problem that the softare is solving. The physical model is at the functions and bytes level. Some people argue that this is foolishness and I should just change the code without thinking too much about it until my tests pass. I disagree with that methodology!

Having a schematic is incredibly helpful with both types of models. A schematic will often put the design into blocks, which helps you understand the logical model, as well as listing specific components and voltages, which helps you understand the physical model. Keeping a physical circuit mentally lined up with a schematic can be quite tricky! To give one example, a physical circuit might have an IC containing 4 different op amps, whereas the schematic will put those 4 op amps in 4 different places in the diagram.

Model Building

It can be difficult to keep a model in your head, so sometimes it’s helpful to build a model. You can do this for example with a breadboard. Breadboards are (electrically) noisy, but they allow you to make changes to a circuit nearly as fast as you can change code.

Another tool which I find super-helpful in building a model of how a circuit should work is a simulator. For the work I do, Falstad is honestly all I’ve ever needed, although it’s quite limited, supporting only a handful of components. There are many more advanced tools, some of which are free, but Falstad has worked for me.

Noise

One significant difference between debugging hardware and software is that with hardware, noise must always be considered. Error correction in digital computers is so good that although noise can and does disrupt circuits in a computer, as software developers we rarely have to actually consider this.

But when working with hardware, noise is more than an occasional annoyance; it’s the sea in which we swim. Noise is always present and often significant.

Sources of noise include:

• Poor connections on a breadboard
• Signals reflected in an incorrectly-terminated cable
• Less than “ideal” components
• Radio frequency interference from nearby devices

Sometimes people try to solve problems without having a model. They will say things like “look for cold solder joints,” or “look at the power supply, and look for shorts to ground,” or “look for shorted capacitors.” That’s fine if it works – indeed, such advice probably comes from hard-won experience – but there will be many problems which you can’t solve so easily!

Datasheets

Electronics datasheets are a helpful tool for building your physical model of a circuit. These are particularly important with ICs, because it is an unfortunate fact that knowing the pinouts, signal voltages, etc., for one model of IC tells you absolutely nothing about another, and getting, say, the power pins of an IC incorrect can cook the IC when power is applied. If designing a circuit from scratch, instead of building someone else’s design, I review the datasheets for each active component I use 100% of the time, and I usually end up reading them when building designs that other people have created, as well.

Compare the Observed Behavior

When we talk about comparing actual behavior with observed behavior, we are probably talking about doing this comparison at a specific part of the circuit, and it’s worth talking about how we will choose where to begin tracing.

It may be that the nature of the failure gives us some clue as to where to start looking. If the circuit seems completely dead, perhaps the failure is towards the beginning of the signal path?

But it might also be the case that there is no obvious place to begin looking. In this case a good technique is to do a binary search. Start in the middle, compare the signal with your model. If it seems correct, go halfway further along the circuit. If it seems incorrect, back up halfway towards the beginning. Repeat as necessary.

How do you know what the signal at some point in the circuit “should” be? It may be that your mental model of the circuit is so good that you will just know. But if that’s not the case, there are some other techniques you can use:

• Many circuits have “test points” on the PC board and documentation on what the voltage/frequency should be at those labeled test points.
• You can use a simulator to approximate what the reading should be.
• You can “lower your standards” and just trace “am I getting any signal at all” without thinking too hard about what it should be, specifically.

Whenever your mental model differs from the physical circuit you’re building, that’s a great place to look for issues. For example, your physical mental model might include a pair of op amps in different points in a circuit, but your breadboard might just have a single IC. The confusion this causes can be a source of error – you might connect a wire to the wrong pin, or forget to connect the power leads to the IC, which were omitted from your mental model.

Tools

In order to compare the actual behavior of the circuit with the model which is in your head or on paper, you need a way to see what is going on inside the circuit. A “hardware debugger.” It turns out that there are many different kinds of hardware debuggers.

Why not just have one tool which does it all? There are attempts at it!. But these tend to be featureless boxes which connect to a computer, and I find them quite awkward to use. Having “one knob per function” is really helpful to me when I’m working on a real circuit.

Multimeter

So, at a bare minimum, I think you need a multimeter and an oscilloscope. A multimeter measures voltage, current, and other things when they don’t change very much. That is to say, if I want to measure a voltage which I expect to be constant, then I will reach for my multimeter. I say “very much,” because of course nothing is black and white and many multimeters have maximum/minimum detection, inrush current measurement, etc. But as a general rule this is for measuring things which are fairly steady. A multimeter is also great when you need to measure something such as resistance or capacitance, which are not generally directly measurable with an oscilloscope. Multimeters come in a few different form factors, including the standard handheld “brick” style, a benchtop style, and a current clamp style. All of these do generally the same things, but may have different accuracy or a few specific features.

Oscilloscope

An oscilloscope, by contrast, is all about showing how a signal changes over time. The signal that you are measuring is usually voltage, although you can buy current probes as well. Besides just displaying a trace of voltage over time on the screen, even low-end oscilloscopes today will do frequency counting and Fourier transforms. Even to just list the features of a contemporary low-end digital oscilloscope would be a post by itself.

Audio Amplifier

I got a great idea from YouTuber Mitch, which is connect leads to an amplifier and a small speaker and use that in lieu of an oscilloscope when tracing an audio signal through a circuit. This allows me to hear the signal instead of see it, so that I can keep my eyes on the circuit.

Desoldering Tools

There is one other tool which I’ve found so handy while debugging physical circuits that I’m leaning towards throwing it in the “essentials” category: Some kind of desoldering tool. It’s possible to do this with a standard soldering iron, but it’s so much more of a pleasant experience with a vacuum desoldering iron or tool! You can buy a spring-loaded desoldering tool for about $10, so at a bare minimum you want something like this, even if you can’t justify a more expensive electric vacuum desoldering iron.

One of the reasons that having a really good desoldering tool is so handy is that many parts cannot be tested in a circuit. To give one very simple example, if you measure a resistor in circuit and you try to measure its resistance, you may not get a correct measurement as there may be other resistors in parallel to it. You must remove it from the circuit to get an accurate measurement.

Other Tools

Beyond that, we get into “optional, but nice to have, depending on what you’re doing” hardware. A power supply might seem like a must, although the circuit you’re working on might already have one. A waveform generator is handy to have around, and I’ve gotten a lot of mileage from mine while working on different synthesizer modules, but I could have just used the VCO module that I built if I didn’t have it.

I have a cheap component tester which I can stick a transistor, capacitor or diode into and it will identify the device, the pinout, and a few relevant characteristics. I don’t use this very often. Going further down this road, you might want an LCR or ESR meter if you are testing capacitors, or a spectrum analyzer or vector network analyzer if you’re dealing with radio/RF signals. But I have never needed them.

A logic analyzer is super-useful if you’re working on digital circuits, and probably unnecessary if you’re not.

Testing Components “In Circuit”

Software developers will be familiar with the distinction between a unit test and an integration test; a similar distinction exists in hardware.

• In a unit test, we test a single function to determine if it returns the expected result given some input. Similarly, we can test electrical components in isolation (not as part of a circuit) to ensure that they are behaving correctly. This is useful because the component cannot be affected by the rest of the circuit, but it can be difficult if it’s necessary to un-solder a component to do it.
• In an integration test, we test an entire program to ensure that it behaves correctly given some input. Similarly, we can test an entire electrical circuit. Note that the test might occur at any point in the circuit, not only at the output. But the important distinction here is that the components of the circuit are connected together, and hence have some influence on eath other’s behavior.

In both cases, there are significant limitations on what we can test when real hardware is involved. For example, you generally cannot measure the resistance of a resisitor in circuit; the effect of the connected components might overwhelm the individual value of one resistor. By contrast, some components can’t exactly be tested by themselves; a 555 timer, for example, requires external components to work.

So similarly to unit tests and integration tests in code, doing tests on hardware “out of circuit” or “in circuit” gives us information about just one component or the component in the context of a whole circuit. But whereas we can generally test a function either with a unit test or an integration test, there are some components which can really only be tested in circuit or out of circuit, and it is up to the engineer to know the distinction, when it occurs.

Make a Change

At some point you will identify a problem in the circuit and will have an idea as to how to proceed. Perhaps you’ve found a bad solder joint, or perhaps a wire has popped out of your breadboard? Perhaps you’ve discovered you used a 100 Ω resistor where you intended to use a 100 kΩ resistor.

Software is so malleable that we don’t really think much about how to change it; we just type. But hardware can be more complicated. You might need to replace a part (or just remove it for testing out of circuit), or perhaps cut a trace on a PC board – or solder it back. Cutting a trace on a PC board is the equivalent of “commenting out” code.

Go ahead and make that change.

Analyze the “New” Circuit

Before powering up the circuit, it’s worth thinking about the “new” circuit you’ve built. Perhaps you think that now it will work, that this one change you’ve made is all it will take to make everything work. And maybe that is so! But it’s worth considering that when a circuit fails it can do so destructively, so you might want to consider that and carefully look at the circuit for other mistakes before powering it up again.

When you do power it up again, you should then decide if the change that you made is good. Hopefully this is the case! But sometimes you will want to undo the change.

Does It Work?

Hopefully the change that you made improves the circuit, but that doesn’t always mean a complete fix. If the circuit now works, great, you’re done, you can stop and consider what you have learned from the experience.

But if the circuit still is not fully functional, now it’s time to go back to step 2, “Have a Model,” and work through the process again.

Grit

Just as with debugging hardware, a significant factor in finding the solution to a problem with hardware is grit: Your ability to stick to a problem and work with it until you find the solution. You need a certain degree of persistence, but not too much. Just as with software, you also need the ability to recognize when you’re not getting anywhere and “call a friend.” I wish I had better advice than just “don’t go too far in the direction of ‘not trying hard enough’ or ‘trying too hard,’” but I will say that if you’ve been in software for a while then you will recognize this problem and hopefully be good at judging for yourself!

The markup used in a Vue.js .vue file is a melange of JavaScript, TypeScript, HTML, and a few other bits of punctuation thrown in for good measure. I encountered one of the odd corners of this today, and as it took me an hour to figure all of this out and the documentation sort of hand waves around it, I thought I should write my notes down here.

Briefly, when you’re calling a method there are not consistent rules regarding whether or not you should put () after the method name. Sometimes you can do this, and sometimes you cannot, whereas other times the behavior of the document will be silently changed depending upon whether or not you use them.

If you have this in a template:

<input :disabled="foo"/>

… and you know that foo looks like:

foo: function() {
  return false;
}

…is that template right or wrong?

Or what if the template looked like:

<input :disabled="foo()"/>

Now is it right or wrong?

The answer is: “You don’t know if it’s right or wrong, because I haven’t told you where foo is defined (in computed or in methods), and that matters a lot. It also matters whether you place this function call in a v-on (@) or a v-bind (:) portion of the markup.

All of the examples here are using functions which take no arguments, for simplicity. Things get even more complicated when your function requires aguments!

There’s a playground here which will help as you read this.

From that playground we can derive this table, which I will explain below:

If your function is defined in computed, then using () will result in a syntax error (even though you have written a function). This is at least consistent and can be summarized concisely. Also, a function defined in computed cannot be used in a v-on (@) binding.

When you write your function in methods things get much less clear. You can use a method in either a v-on (@) or a v-bind (:) binding.

For a v-on binding, you are allowed to omit (), and the behavior of the function will be exactly the same with or without it. That is:

<input @input="inputMethod"/>

…and:

<input @input="inputMethod()"/>

…will behave the same. This is “sort of” documented.

However, with v-bind binding, if you omit the () then you are just returning the method reference itself as a JavaScript expression, so if you have:

<input :disabled="disabledMethod"/>

…and:

<input :disabled="disabledMethod()"/>

…then the top example will not invoke disabledMethod and will return the value of the reference to disabledMethod, which is truthy if it exists. This is probably not the behavior you want!

The bottom example will invoke disabledMethod and will use its result when assigning the disabled attribute.

If any of this is unclear, try the playground , which will hopefully correct anything I’ve misstated.

What Even Is a VCA?

If you have used keyboard/desktop style synthesizers but not modular synths, you may have seen a “VCA” section of your synth before, or, depending on the synth in question, you may have just seen a dial somewhere with a different label.

A VCA allows you to use one control voltage to adjust the level of another signal. The most common use is to use the output of an envelope generator to adjust the level of the VCO’s output (turning an unchanging drone into a note with an attack, decay, etc.). But there are many other uses for a VCA!

Still, because the two uses above are so common, in many synthesizers the “VCA” is represented as a “Volume” knob somewhere, or as a slider by an envelope generator.

For example, here are two synthesizers with two different labels for the same feature:

On the left is the “VCA” section of the Roland Jupiter-8. You get two controls: A simple level slider, and a four position switch which controls how much one of the synth’s LFOs affects the output. On the right is the Retro Synth plugin from Logic Pro; here the “VCA” feature is just sort of implied by the envelope and a slider labeled “Vel” (for Velocity) to the right of the two envelope generators. Neither of these have a “control (voltage) input,” because they are hard-wired to the envelope and the LFO, in the case of the Jupiter-8, and to the envelopes, in the case of Retro Synth.

In the modular world it’s pretty common for a VCA to be a separate module, but you may end up using them in exactly the same way: You want to turn the endless drone of a VCO into distinct notes, so you connect an Envelope Generator to your keyboard’s Gate output and you connect the output of the EG into the control voltage input of a VCA. You then connect the VCO’s output into the audio signal input of the VCA, and the output of the VCA now has distinct notes when you press a key. Success!

However, a VCA can be used for other applications; I’d recommend watching this video (particularly the last two thirds) if you’d like to see examples.

How a VCA Works

A VCA is simply a volume knob which can be controlled using a control voltage. The control voltage is “…typically from -2.5 V to +2.5 V (5 Vpp) for LFOs, and from 0 V to +8 V for ADSRs,” to quote the Eurorack (non-)specification. There’s usually two “volume knobs,” in series: A real volume knob you can set with your fingers and an electronically controllable volume setting you set with a control voltage.

We know how potentiometers work, and the “real” volume knob is just one of those, with an op amp for isolation and gain. But how does a control voltage controlled volume knob work? If we ccould find such a thing as a “voltage controlled resistor,” that would do the trick. It sounds like something which could be done with an op amp, but it would require a somewhat less common circuit, called an operational transconductance amplifier (or OTA) instead. These tend to have an amplifier bias or I_ABC input which will control the gain of the amplifier based on the current going into that input. But other designs are possible, and as we will see the MKI x ES.EDU VCA is based on individual transistors instead of an integrated circuit like an OTA.

Breadboarding the VCA

Before I start breadboarding I ususally separate out the various resistor values, set them in order, and tape them to a piece of paper with their values in Ohms written alongside them.

Breadboarding the Volume Potentiometer

The first thing we are asked to build is a volume control using just a potentiometer. Not exciting, but the idea is that a VCA will essentially be just controlling volume using a control voltage instead of a knob. Of course the truth is somewhat more complex, given the need to isolate modules from each other in terms of impedance, but we’ll get there. Anyway, having built that we can verify that we can indeed vary the volume of a signal passing through our not-quite-yet-voltage-controlled-amplifier by twisting the potentiometer knob. Moving right along…

How a Bipolar Junction Transistor Works

If you look up a Bipolar Junction Transistor on Wikipedia or in many electronics books, the description will start with a discussion of “P-type” and “N-type” semiconductors, and at the end you still won’t have a good idea of what they do. Instead, I’m going to go with what Professor Aaron Lanterman calls the “magic elves theory,” and describe what they do without explaining the physical implementation, instead saying, “they do it that way because the magic elves inside make it happen.” This is actually similar to the “transistor man” presentation in Horowitz and Hill’s The Art of Electronics.

The purpose of these kits is perhaps more about teaching you how electronics work than it is about building the greatest synthesizer in the world. We’ve used a couple of transistors in the past, but we haven’t gone very deep into how the work. So, no time like the present! The instructions now take a (pages-long) digression into how transistors, and bipolar junction transistors (BJTs) in particular, work. I won’t repeat that here, but there is a points that I found confusing which I would like to try and clarify.

In the VCO kit we used a transistor as a kind of variable resistor controlled by the base input. The VCA instructions spend a good bit of time explaining why a transistor is not, in fact, a resistor. A transistor provides resistance, clearly: A fairly high resistance value when no voltage is connected to the base! You can control the amount of current passing through the device using the voltage you connect to the base.¹

But resistance is not the same as being a good resistor. A transistor is designed to allow current to (easily) flow in only one direction, unlike a resistor, and, also unlike a resistor, a transistor will pass a fairly steady current regardless of voltage applied to the collector. So the transistor is not a drop-in replacement for a resitor, even if it was useful to us in supplying a voltage-controlled resistance when building the VCO. It’s also noteworthy that the VCO required a resistance which varied exponentially with the input control voltage, and thus it’s super convenient to use a transistor, which more or less does just this. With the VCA, however, we want the volume to change linearly with the control voltage, so we will need to be careful about how we use the transistors.

The Problem with BJTs

One problem that BJTs have is that they are not very consistent devices. Even BJTs from the same manufacturer with the same part number will vary in how much current they pass and the precise base thresholds that control the transistor. They will also vary considerably with the outside temperature.

So, we would like to compensate for these variations. How do we do that?

Negative Feedback

We start with a circuit much like the one on the right but without the 10k resistor at the bottom. Then we get to the point that I found confusing! Moritz talks about “introducing negative feedback” by connecting a resistor between the transistor’s emitter and ground. That’s the 10k resistor at the bottom of the circuit at right. What I didn’t understand was: A resistor is a passive component; how could introducing just one resistor provide any kind of feedback?

The answer is that although the resistor is passive, the transistor is very much not passive, and putting a resistor between the emitter and ground makes a world of difference because it changes the behavior of the transistor. How? When the transistor’s emitter is connected directly to ground then the emitter voltage will always be at ground, no matter what the base of the transistor is set to. But when there is a resistor between the emitter and ground, things get more complicated.

A transistor is “active” when the voltage between the base and the emitter is over a certain threshold, around 0.6V. When the transistor is active, current will pass between both the base and the emitter and the collector and the emitter (for an NPN transistor). This current flowing out of the emitter has to flow across the 10k resostor. When a current flows across a resistor you get a voltage. Therefore the voltage at the transistor’s emitter is no longer being held at ground. Instead it varies depending upon the amount of current passing through the resistor. And this change from “voltage is fixed at ground” to “voltage varies with the amount of current being passed out of the emitter and across the resistor” is the key to understanding how adding just that one resistor can be called “negative feedback.” The more current that passes through the resistor, the higher the voltage difference across its two ends will be, right? However, this means that the end of the resistor connected to the emitter will be at a higher voltage, and therefore the higher the current, the lower the difference in voltage between the transistor’s base and emitter will be… which reduces the current! This is the negative feedback.

Therefore, if something changes the gain of the transistor, such as its temperature, this circuit will have the opposite effect: More amplification means a higher voltage at the emitter which means a lower voltage from base to emitter which means a lower gain!

Another Way to Look At “Negative Feedback”

One of the things that confused me about the directions use of the phrase “negative feedback” is that I hadn’t seen this phrase in other tutorials about transistor amplification. But once I understood what he meant by negative feedback I could line up what he was saying with other explanations. So now I will explain this in a different way, but I will be describing the same “negative feedback” mentioned above. It helps me to have multiple ways to consider the same phenomenon.

In this section I’m summmarizing the explanation from Practical Electronics for Inventors, Fourth Edition, by Scherz and Monk.

The gain of a transistor, by definition, is:

$$ \begin{align} Gain = \cfrac {V_{out}} {V_{in}} = \cfrac {\Delta V_{C}} {\Delta V_{E}} \approx \cfrac {R_{C}} {R_{E}} \end{align} $$

Where V_C is equal to the voltage at the collector, R_C is equal to the resistance at the collector, and similarly for the emitter. However, that’s not quite the full story, because a transistor has a small internal transresistance in its emitter region, and one way you can think about thermal instability in a transistor is that the transreistance changes with temperature. So a somewhat more accurate model is:

$$ \begin{align} Gain \approx \cfrac {R_{C}} {R_{E} + r_{tr}} \end{align} $$

Where r_tr is the transresistance value, which, again, is not constant. This is not 100% accurate as there is some small current flowing from the base to the emitter. But this does tell us that we can minimize the effect of r_tr by making R_E comparatively large relative to it.

$$ \begin{align} r_{tr} \approx \cfrac {0.026 V} {I_E} \end{align} $$

How much is that? Well, we have I_E apporximately 600 μA, which works out to arount 46Ω. So a 10KΩ resistor should make its effects very small indeed. Scherz and Monk say, “In practice, R_E should be chosen to place V_E around 1 V (for temperature stability and maximum swing in the output). Here we’re around 6V, but note that in the very next step we will be reducing the voltage at the emitter!

Breadboarding a One Transistor VCA

So now let’s build a VCA (with actual voltage control, not just a potentiometer). It looks like this:

When we look at the output on a scope, though, the results are not so great:

The yellow trace here is the output of a function generator I’m using as my “signal.” This is like the audio signal I would be running through the VCA in the real world. The magenta trace is the input into the base, and the cyan trace is the VCA’s output at the jack. These last two look “blurry,” but note that the vertical scale on the oscilloscope is much smaller for them. (20mV/div vs. 1V/div.)

Breadboarding a Differential Amplifier

There are a few problems with the circuit we have built so far:

• Poor amplification (low gain)
• It’s noisy
• The output is inverted
• It’s still sensitive to temperature variation in the resistors, even though we have improved things by adding the resistor at the emitter
• When we change the CV signal, the DC offset of the audio output changes

Moritz proposes to fix all of this by using a differential pair of transistors. So first we add a second transistor and arrange both in a differential pair.

Now we get two outputs, which are in opposite phase:

Adding a couple more transistors and the second op amp (in the same IC package as the first one), we can combine the two signals, subtracting them to produce the difference between them (hence, differential pair). This is an op amp configuration which I didn’t show in my op amp tutorial, so here it is:

If you’ve read that tutorial, you’ll understand how this works. It’s exactly the same as an inverter configuration, except instead of having the non-inverting (‘+’) input tied to ground, instead the non-inverting input of the op amp is connected to another signal input, via a voltage divider. Without going into too much detail in this post,² it hopefully makes sense if you think that when the non-inverting input is at ground this is exactly an inverter, because 0/ground minus the inverting input is the opposite of the inverting input.

Anyway, with the op amp outputting the difference of the two transistor signals, our trace now looks like:

The next step is to add a trimpot which allows adjustment to compensate for small manufacturing differences between the two transistors. Even when both transistors are at precisely the same temperature, two different transistors of the same lot from the same manufacturer may vary in their gain. One way around this is to buy a matched set of transistors in an IC package. Another way around this is to add a trimpot:

Finally we change some resistor values to make the last op amp in the signal chain boost the amplified signal up to a 10V peak to peak output.

I realize the signal looks quite noisy. Some of that is real, because breadboards tend to be pretty noisy. Some of that is due to the high magnification of the output signal vs. the function generator signal. Here it is with the same vertical scaling:

Soldering It All Together

One curious fact about this project is that even though you are building essentially two entirely separate VCAs, they are laid out differently on the PCB. I’m not sure why this is the case; perhaps it has something to do with where the sockets and potentiometers would have landed. But it’s necessary to be very careful when selecting parts, because the layouts are mostly the same, except where they’re different.

Resistance is Futile

Soldering on the resistors was unexpectedly complicated.

The manual notes that some of the resistors need to be closely matched, and therefore they have supplied a few ±0.1% tolerance resistors where they need to be as close as possible. This is really helpful, but it would have been even more helpful if they had mentioned it prior to page 51 of the manual! As above, I didn’t notice this difference when breadboarding and had to sort out the differently specced resistors.

The manual states:

You can identify these ±0.1% tolerance resistors by their light blue bodies
[emphasis in original]

There is a difference in the blue, but it’s quite subtle. The ±0.1% and the ±1% resistors look near-identical, and I therefore had a bunch of sorting parts to do from my breadboard assembly (made even more complicated by the fact that 100Ω and 100kΩ resitors also look near-identical when you test them with a multimeter, and their color codes aren’t that distinct, either).

Adding to the “light blue woes,” the colors in the photo in the manual (left, below) don’t match the tolerances in the layout diagram (right)!

A much better way of distinguishing these different kinds of resistors (unmentioned in the manual!) is the fact that the resistor tolerance is encoded in the color band code. So a 1% tolerance 100k resistor will be “Brown Black Black Orange Brown” whereas a 100k 0.1% tolerance resisotor will be “Brown Black Black Orange Violet”

Choosing Transistors

Most of the rest of the soldering was uneventful, but when it came time to attach the transistors I wanted to match them as closely as possible. I have a component tester which I used to measure the hFE of all four transistors included in the kit; their values were 524, 536, 552, and 572. So I paired the 524 & 536 and the 552 & 572 transistors.

Which Way Does the Front Panel Go?

At one point the manual says to attach the front panel, but this kit has two perfectly symmetrical VCAs and there are two possible ways to attach the front panel! Only one way will result in the jacks going into their labeled spaces on the front panel, though (with the “IN1” jack going into the hole labeled “IN1”), so be careful and check the labels on the board when attaching this.

After attaching the front panel, the last step is to insert the two TL072 ICs. I always get a little nervous when I do these, because if you insert them the wrong way you will cook the ICs when you power them up. The two ICs are aligned differently on the board, the photo in the manual is unclear, and the “notch” on the IC doesn’t match the notch on the socket, so you will want to triple-check this before you move on.

Powering Up

Mortiz suggests first testing the VCA using an oscillator (which I have) and just seeing if the “Offset” potentiometers work correctly, so I did that, and it sounded fine. Then you’re supposed to adjust the trimpots to center the oscillation around ground. This is mentioned way back in the breadboarding section of the manual, but it’s important to set your oscilloscope to DC coupled when doing this adjustment. If the trace doesn’t move when you adjust the trimpot then you probably have the oscilloscope input set to AC coupled.

I had to fix a cold solder joint. It took me longer to find than it should have. Hint to future me: If something that used to work stops working, start your search with the jack socket into which you’ve just plugged a cable. One thing that confused me while I was fixing this was a feature I didn’t know the VCA had: IN1 is normalled to IN2, so you can use one input for both VCA sections (and similarly with CV1 & CV2). This is mentioned in the manual, but only in the appendix.

In the trace below, there is a sawtooth waveform from the VCO connected to IN1, and nothing connected to IN2 (so the IN1 signal is normalled to the second VCA). The Offset knobs are set to different positions. The yellow trace is OUT1 and the purple trace is OUT2. I’m pleased that there is far less noise in this (the PC board version of the VCAs) than there was in the breadboard version.

With that finished, I now have a more or less functional synthesizer! There is no filter (yet!), but I can play a note and have an envelope which sounds nice. I’m very happy with the progress I’ve made!

Resources

Instructions

• mki x es.EDU VCA User Manual

Product Pages

• EDU DIY VCA
• mki x es.EDU DIY System

Community

• Modwiggler thread
• Modulargrid page

Simulations

All of these simulations are by Moritz Klein

• Voltage Dividers
• Transistor vs. Resistor
• Transistor Amplifiers
• The Emitter Resistor
• Gain Changing Tricks
• The Differential Amplifier
• The Differential Amplifier (with Signal Subtraction)
• The Differential Amplifier (with Mismatch Fix)
• The MKI x ES.EDU VCA

Videos

• Designing a classic transistor-VCA from scratch by Moritz Klein (48:42)
• Introducing the mki x es.edu DIY VCA kit by Moritz Klein (6:19)
• MK1 vs es.EDU Dual VCA - Build and Demo by Quincas Moreira (31:04)

If you own a synthesizer, or have worked with software synthesizer plugins, you have no doubt encountered the term “VCO” or “Voltage Controlled Oscillator,” and indeed we have seen it before in this series. Today most synthesizers are fully digital and just have “oscillators,” which produce arbitrary waveforms using a computer, but you may also encounter “DCOs” or perhaps just “Oscillators,” and wonder if these names actually mean anything distinct.

In this post I’ll explain the “oscillator” part of how synthesizers produce sound, look at three designs for actually building an oscillator, and talk about the differences in sound that you may hear from these designs.

Voltage Controlled Oscillators

I won’t spend a ton of time explaining how a VCO works because I’ve already done that. For the sake of this post I’ll just say that the entire oscillator, including both the control of the tuning/timing as well as the shape of the wave produced, is analog.

The earliest commercial synthesizers,¹ such as Moogs, ARPs, and Buchlas from the 1960s all used VCOs.

One of the major downsides of a VCO is you have to tune it. A lot. Some later commercial synths with VCOs introduced an automatic tuning feature which helps considerably, but they will still drift as you play them due primarily to temperature changes but also due to aging of electronic componaents and the inherent differences between two “identical” components. Two transistors from the same manufacturer with the same model number and made in the same production run can have very different electrical characteristics, for example. Also, as the name suggests, they are Voltage Controlled, that is, controlled with an analog voltage which might be produced by a keyboard or a sequencer, and there is no single standard for control voltages, so you have to tune the VCO to produce the correct note when you, for example, press keys on your keyboard.

On the other hand, VCOs often sound amazing, and the tuning drift may be part of the reason! One surefire way to fatten up nearly any synthesizer sound is to add another oscillator and detune the second oscillator so it doesn’t produce precisely the same frequency as the first. Make it “fatter” still by using a LFO (Low Frequency Oscillator) to vary the detuning over time just a bit. Our ears hear this difference in frequencies as a beating sound which might be pleasant or unpleasant, depending upon the amount of difference between the two oscillators. Do this with two VCOs and there will be a certain amount of drift between the two oscillators as you play, and this can be a very pleasant sound. For a while, anyway, until it goes way out of tune and you have to stop playing and retune it.

VCOs are said to have a characteristic sound due both to a limitation in the waveshapes which are used (typically, square, sine, sawtooth/ramp, triangle, and a few others) and also due to the variations in tuning. Happily, though, many people really like the sounds that they produce.

Digitally Controlled Oscillators

A DCO still produces an individual cycle of oscillation using analog electronics, but uses a digital timer (typically controlled via a microcontroller) to trigger each cycle. This allows the DCO to always have “perfect pitch.” Like a VCO, a DCO is also an analog oscillator which uses analog circuits to produce the wave shape that you hear.

A DCO will never require tuning. The note “A 440” will always sound at 440 Hz. You can detune a DCO, which as above you might do if using two oscillators together to produce a fatter sound. But there will not be any random “drift” in the tuning.²

The first synth with a DCO was the Roland Juno-6, which was available in 1982.³ DCO-based oscillators are not so common today. The majority of commercial synthesizers are digital, and folks looking for an “authentic” analog sound often want a VCO in spite of tuning headaches.

Essentially, the way a DCO works is the microcontroller sends a signal to the analog circuit when it’s time to produce each cycle of the waveform. You can think of a microcontroller sending a pulse every 1/440th of a second to produce an “A” note. From there an analog circuit produces a single cycle in almost exactly the same way that a VCO does, and then it stops and waits for the next pulse from the digital controller.

I would explain how a DCO is implemented in hardware, but Thea Flowers has already done a much better job of this than I ever could, so if you’re interested (and it is very interesting, I think!) then I recommend you go read her article!

Conceptually, the only “audible” difference between a DCO and a VCO is that the DCO will never drift in the tuning of its fundamental frequency. From a practical, real-world standpoint, however, they might be implemented with different components and hence sound very distinct, and even two “identical” analog oscillators can sound different because of the difference between “identical” analog parts. Also, VCOs, as noted, do drift in pitch, and this also makes them sound different than a DCO.

Digital Synthesis

Digital Synthesis produces a sound by using a computer program to produce a waveform digitally. This includes samplers/sample players, all software synthesizers, and “virtual analog” synths which use clever programming to try to reproduce the sound of a VCO or DCO. Some of them do it quite well!

The first mainstream digital synthesizers were the Casio VL-1 in 1979, which was something of a toy but considerably cheaper than the other digital synthesizers available at that time which were > $10000 in 1980 dollars. Other notable milestones in making digital synthesis a mainstream technique were the E-mu Emulator, released in 1982, and the Yamaha DX-7, in 1983.

The sound of a digital “oscillator” will be precisely what its programmers specify. This could be a perfect sine wave, playback of a sample, a modeled recreation of an analog oscillator, small slices of a sample as with a wavetable synthesizer, or many other things. A digital synthesizer will have a Digital to Analog Converter (DAC) in its signal path; a VCO or DCO based synth will not require this.

Some people will tell you that they can hear the digital “stepping” as, for example, a 16 bit, 44.1 kHz digital oscillator changes its output through its 65,536 possible amplitudes over every 1/44100s. I will tell you that these people are wrong, and that they cannot hear this.⁴ However, they may in fact hear the difference between a VCO and a “perfect” digital recreation of the “same” VCO, because, once again, even two “identical” VCOs may sound different because of differences between the analog parts, their variance with temperature, etc.

While it’s both theoretically and practically possible for a digital oscillator to reproduce the sound of an analog oscillator well, there’s no denying that many synth manufacturers have not bothered to do it well. Sometimes this is on purpose; a wavetable synth, for example, is not trying to reproduce the sound of a VCO. But even in cases where a synth manufacturer explicitly claims to have an “analog sound” from their digital oscillators, well, some of them do it better than others.

Synthesizers Today

The majority of hardware synthesizers, and all software synthesizers, sold today are digital. Digital oscillators are quite common even in the modular synthesis world. However, there are still fully analog hardware synthesizers produced, in keyboard, desktop, and modular forms, generally with VCOs.