I’ve continued to work on the optical ray diagram tool prototype. I added a way to measure the effective focal length (EFL) of the lens system. It isn’t automatic, but by adjusting the parameters you can align an intersection at the optical axis and read off the EFL. Obviously this should be a one button click sort of thing, but it is kind of interesting to see how the various parameters affect EFL.
The UI is still very rough and the code is even worse. But I’ve actually been using it!
My main area of interest before going to automation is identifying and coding all the various measurements that you want of a lens. To identify these, I’ve been reading the excellent Applied Optics and Optical Engineering edited by Rudolf Kingslake. Chapter 3, Photographic Objectives, traces the history of the development of lenses from the development of photography to the book’s publication in the 1960s. I would recommend either starting there if you have some familiarity with optics already. If you’re new to optical design, start with Chapter 1, Lens Design. I got my copy from the public library but you can also borrow a digital copy from the Open Library on archive.org.
I realized I should change the example lens configuration in my prototype to a Cooke Triplet after reading Chapter 3. As the book points out, a lot of modern lens designs can be traced to or analyzed as variants of the Cooke Triplet. It is also unique in being only three elements but having performance that is good enough to warrant doing the work of designing one yourself. It is also non-trivial enough that you want an automated tool to design one, so it makes a good example.
The next step will be to add proper measurements of the various aberrations and distortions. I’ll be using worked examples from Applied Optics and Optical Engineering to check the calculations of my tool. The current default configuration is from this student project in MIT OpenCourseWare by Choi, Cooper, Ong, and Smith. I think I’ve already found a discrepancy in my results so my work is cut out for me.
Another source for a worked example is Dennis Taylor’s original patent from 1895. While Taylor invented it, the design is named after the company he was working for at the time – T. Cooke & Sons of York.
Over the weekend I tore down an old RCA Super8 camcorder. It came with a power supply but it had already been damaged in the past. The viewfinder showed text over static and the tape mechanism just made a horrible squealing sound.
The good stuff – varifocal zoom mechanism and a teeny tiny CRT
I was interested in perhaps using the imager somehow but it seems to be damaged and not worth chasing down. The autofocus and motorized zoom work great though, so I’m hoping to use those paired with a Raspberry Pi camera. Even if I don’t ever use the motorized features, they’re manually adjustable so that will make for a nice setup.
Most of the parts that I didn’t use.
The other electronic parts of the camera are a bit too specific to be useful. I’m hoping to reuse some of the mechanics of the tape transport in my 1/4” audio tape experiments. 8mm is larger than 1/4” (6.35mm) so I think some of the various guides and rubber pinch rollers will come in handy.
Before I send all the extra parts to the electronics recycler, I need to plug it all back together and document the connector pin outs.
I have a few prototype Eurorack modular synth modules in the works. I tend to get them working well enough to be musically interesting and then move to work on the next prototype. It’s not because I don’t plan on finishing them – it’s more that all the biggest questions are answered and I want to move on to the next prototype and answer whatever questions it is trying to answer.
The prototype laid out
This module is based around the Yamaha YM3812 chip, also known as the OPL2. You might know it as part of the capabilities of the AdLib and original Sound Blaster sound cards. Think of the classic sound of the Doom soundtrack – that’s coming out of a YM3812 (emulated or otherwise).
But you can do a lot more than what you hear on the Doom soundtrack – even though I’d be fine if that was the limit of it’s sonic capabilities. FM synthesis is “weird” in the way it can produce wild sounds that are very hard to produce with subtractive synthesis. As an added bonus, the YM3812 has multiple symmetrical channels and is this capable of impressive polyphony. One module isn’t just one voice – it’s 6. Also it has a drum synth mode… It makes sense that it is so capable if you think about all the great PC game soundtracks made with one, but it isn’t what you’d expect to be coming out of a single modular synth module.
The Problem
In the modular world, you tend to break apart and de-integrate as much of the synth chain as possible. This is so you have the freedom to reconfigure the synthesis signal path in wild and fun ways. So a module with not only a complete voice but six complete voices is swimming against the current in how you typically design these things.
How the front and back circuit boards attach together in the prototype
One outcome of such a non-modular module is the matter of the number of possible parameters available. Typically a module might have 1-4 inputs and 1-2 outputs. That’s a gross simplification but gives you an idea of the majority of signal complexity involved. A single channel of a YM3182 has about 16. And then you have 6-8 copies of those – each voice can be configured more or less independently. So we’re talking hundreds of possible inputs.
It has one output.
So on the face of it, this is a bad match. And therein lies the hypothesis of this design. “How can you adapt a YM3812 to the modular synth design norms?” How do you make it understandable to someone thinking in terms of fairly straightforward signal chains? How do you present the configuration of a YM3812 so it matches the mental model of someone used to something like the Behringer Neutron?
A Lone Voice
I can’t do anything about the output space. There is literally only a single pin for the output and there isn’t any access to the individual voices. So right off, I decided that this prototype would be a single voice. That might seem wasteful, but I can use the other voices to “mirror” the main voice to fill it out by slightly detuning them or by playing notes related by harmonics such as octaves or triad chords.
That also reduces the input space. We’re down from hundreds to a dozen or so inputs if we’re only treating this as a single voice. Some existing designs stop there, but I wanted to go further.
Time Variations
There are broadly two types of inputs to a voice: time varying and time invariant. The time varying inputs configure, for example, the way the amplitude of the sound changes over time. In a modular synth, input like this are controlled by other modules. So I decided to discard all time-varying parameters. Parameters like the amplitude of the voice would be modified externally using voltage controlled amplifiers (VCA) just like you would do with a standard modular signal path.
This reduces the input space by half. We’re looking at about 6 inputs. That isn’t bad – there are definitely synth modules with 6 inputs. But I wanted to go further.
Digital Zippers
The YM3812 is a digital chip. All of the OPL series of synth chips are. This is what made them such a great product for Yamaha. It was easy to make a digital chip out of silicon so they could produce the entire sound path out of a handful of parts that would take thousands of separate analog components to replicate. And because it’s digital, it’s very easy to use in a PC sound card. The CPU just sets the input registers of the chip and away you go.
In a modular synth, all of the patch paths are analog: continuous time varying signals between about -10 to 10 volts. To adapt these kind of signals to the YM3812, I would need to digitize them using an analog to digital converter (ADC). But there’s a problem here too – what sort of digital resolution should I use? If I use too low a resolution, the continuous varying signals end up being converted to broad, stair step patterns. It means your smooth subtle varying input gets turned in to sudden chunky sound changes. People call this effect “zippering” because it can cause a sound similar sound when a parameter moves through those discrete stair step values. That isn’t intrinsically bad in the world of analog synths, but you’d like to at least have the option to avoid it.
Some of the input parameters of the YM3812 have a very limited range of possible input values. As an example, the strength of the feedback from one internal voice generator to itself is controlled by just three bits. That’s only 8 possible values! That does not map well to a 20v swing input.
So I took all the parameters that did not have enough bits of configuration available to be used with an analog input off the table. I would still have them accessible, but through manual switches and control knobs. They’d be more for setting the broad mode of the voice, not for use inside the time of a single note playing. That removes a handful more inputs from consideration. In fact, you’re down to only four. That is a completely respectable number of inputs for a synth module. But I wanted to go further.
A page from my notebook where I went through all the possible inputs to a voice
Getting Rational
One of the interesting things about FM synthesis is that a lot of the timbre results from the mathematical ratio between the different frequencies of the oscillators involved. In the YM3812, each oscillator has 12 possible frequency multipliers to aid in defining these ratios. So while there are only 12 values for a given oscillator, there are 144 combinations between the two oscillators of each voice. Twelve steps isn’t enough for an analog input but 144 is fine. So my final reduction was to combine the two ratio inputs into a single input.
I wanted to think about the ratios as actual ratios so I wrote this out by hand. This is the type of thing I think about to fall asleep sometimes.
And that leaves us with just three inputs: one that controls the frequency of the voice, one that controls the amount of mixing between the two internal oscillators, and one that controls the ratio between the oscillators. To put it another way: one controls the pitch and the other two control the timbre. That sounds like a perfectly understandable module. It is still more integrated than you would see in a traditional module where the timbre modification would occur in a separate module (or sets of modules), but it is much closer.
And there you have how I arrived at the final design of the prototype. All other design considerations stem from the decision of which inputs to use: the physical layout, the specifics of how signals map to sound changes, the size of the module, etc.
There are a lot of details I’m glossing over here, and I’ll talk about them more in future articles.
Because the first assembly language I learned was for my TI graphing calculator, I’ve have a soft spot for the Z80 CPU. It’s a nice 8 bit architecture and widely used in pre-MSDOS machines. The Apple II used a 6502 but more or less all the “business class” machines ran CP/M on a Z80.
It has a 16 bit address bus so it can address 64k of RAM, which is fine for an 8 bit machine. You can do bank switching to get access to more, which is what CP/M does.
I’ve breadboarded some very rudimentary Z80 machines over the years, but the Z80-MBC2 by Just4Fun is a great take on the genre. The twist is that it uses a Atmel AVR as a supervisor/ROM emulator/IO coprocessor of sorts. It makes it very easy to rapidly develop ideas when your IO system is reprogramable!
After assembling and experimenting with one, I decided I wanted the ability to support traditional expansion methods. There is standard DIY-oriented bus format for Z80 systems called RC2014. It is more or less the 40 pins of the Z80 CPU itself spread out in a 1×40 header. So I built an adapter that sockets in-between the CPU and the MBC2, pulling the bus lines out to one side. I used veroboard because its straight-through traces make extending the bus a cinch.
I haven’t had a chance to revisit the project lately, but I plan to. I assembled a composite video card for RC2014 and need to try it out.
The American internment of Japanese Americans during WWII is one of the many shameful things in my country‘s past that I didn’t really learn about growing up. Only when I moved near a park in Seattle that was on land taken from interned people did I begin to grasp the horror of it.
Highly recommended
Miné Okubo was interred herself and details the account in Citizen 13660. The title comes from the number assigned to her by the government as she went through the whole injustice. Citizen 13660 is autobiographical and told in a combination of words and images that are brief and poignant. It’s a book I revisit occasionally when thinking about the sociopolitical forces that have gotten is where we are.
The edition I have includes an introduction by Christine Hong which helps explain the portions of Okubo’s journey in the creation of the work. The book is inextricably connected to her release from internment.
The author is present in most of not all images – reminding you that this is autobiographical
I should also mention Okubo’s art. I find it brilliant and engrossing. There are very specific details in some images – someone’s expression or just the way some space is drawn. I can’t help but consider how emblematic certain things would become.
I’m not really qualified to relate the gravity of the experience of Japanese Americans imprisoned during the war. Miné Okubo’s Citizen 13660 is the primary source I suggest starting with.
I haven’t shared much about my modular synth, but I really should. I’ve created several custom synth modules – even designing PCBs and custom 3D printed faceplates for them. The circuit design is also my own although heavily inspired by the very helpfulsynthDIYcommunity. There’s only so many ways to build an Arduino-based utility module, anyhow.
Front panel printed with what I’m starting to call “prototype orange” – my least favorite color of filament on hand.
This module hasn’t been finished but the front panel is pretty much complete. In addition to visually displaying a signal on the meter, it also has an “attenuverter”. This is a circuit which multiplies the input by a manually adjustable value between -1 and 1. This can both attenuate and invert the input signal – thus the portmanteau attenuverter. It’s a handy capability for modifying control voltages like and LFO or ADSR. I’m adding the ability to add an offset to the output, which allows you to move some control voltage up or down by some bias amount in addition to attenuating it.
I think I’ll also add a few modes to the meter such as a low value mode for voltages between -5 and 5, a high value mode for voltages between -10 and 10, and something like a VU meter – which looks at the average peak value. These have all been breadboarded in the past but I need to combine them all into one circuit and make a PCB for it.
The front panel printed out correctly on the first shot – even the snaps that hold the meter in place work great. That’s satisfying.
The snaps are hard to see but they work great.
I need to find a typeface more suitable to printing though. Anyone have recommendations? Drop me a line. I’d like something that doesn’t have floating regions unconnected on the first print layer. Those seem to get messed up when I use cheap filament because of adhesion issues. You can see that in the photo in the case of the second capital R.
I’ve dug into this ray diagram sketch on CodePen because it’s pretty satisfying to twiddle the properties of the simulation and see how things change. I’ve added some sliders, but beware of the code – it isn’t pretty. I’d say it’s about reached the point of unmaintainability.
Screenshot as of this post
The UI is a total wreck, but you can currently alter all the major parameters. There aren’t any measurements yet, which is probably the next most important feature. It’s fine and dandy to move these virtual lenses around and see how the rays refract, but without the proper measurements it’s not actually a useful tool. Also there isn’t a way to change the lens type or order, and once you can do that, you’ll really want to be able to save and load a given configuration.
And this hasn’t even gotten into the optimization part! That’s the whole purpose!
If you’re interested in know “How did we get here?” then I highly recommend Cathedral, Forge, and Waterwheel by Frances and Joseph Gies. It dispels the myth that Europe of 500 – 1500 CE was some mud-filled backwater just waiting for some brilliant Renaissance thinkers to come along.
The cover of my copy
Don’t get me wrong – it wasn’t a glorious time either. But CF&W explains the development of specific technologies and how they changed society in a way that led directly to the (more celebrated) events of the Renaissance.
Probably one of the most important developments was of a merchant class as a center of power that could rival dynastic royalty. These developed into guilds and families that were patrons of those famed Renaissance artists as much as royal and religious wealth.
It also marked some of the first mechanical industry due to the shift of a source of power not dependent on animals (or people).
Is that person making a glass vase or jamming a wicked trumpet solo? Who can say?
The history of technology as recorded by Western historians is usually Euro-centric and that does leave out the larger context of how knowledge was flowing from Asia and Africa. It’s been a while since I’ve read CF&W, but I recall it doing a good job talking about how the origins of many things came from outside Europe. (And the back cover says so too, so I’m probably remembering right.) As you read any history, it’s worth keeping in mind the bias and agenda of the authors.
It’s an approachable and interesting read about a time you might not know a whole lot about. It looks like ThriftBooks has it, too.
During lunch I whipped up a software sketch based on that notebook entry I posted earlier. I thought I’d start with actually drawing the shapes required for a ray diagram, and then make it more data-driven over time. I should be able to then make a clean seam in the code where the diagram is controlled either by a human or a robot – maybe both at once!
Screen shot of where the ray diagram software sketch is so far.
Also I obviously need to write the actual solver, but that’s “just” a bunch of geometry and shouldn’t be too hard. I think I’m okay to assume that each ray will hit each boundary in order. If a ray doesn’t hit it’s next boundary, it gets dropped from the list.
This is pretty software-oriented compared to what I’ve been working on lately, but it’s the easiest thing to write up and very recent work.
