A few months back during the holiday break, I had an opportunity to reconnect to some old friends on IRC via Libera.chat and my memories of a Common Lisp library for scoring music called Gsharp were revived. Not bad after 22 years.

I attempted to load up the old software, but the graphics library that it’s built upon, McCLIM, has had some real development done in recent years by Daniel Kochmański and team. They’ve been keeping that direct lineage of the Symbolics early and revolutionary graphics interface going and subsequently the old Gsharp code needed too many changes just to half render.

In stepping through that process I had a chance to discuss the current state of Common Lisp as well as Gsharp’s creator’s vision for a new library for music scoring along with some of the changes in Lisp Library support and some big happenings in the big wide world of musical fonts.

I decided it would be fun to try and crack into this, since it combines a few of my passions into a single coding project. First, I needed a way to load fonts into a Common Lisp graphics system and render them to the screen. Here is where Daniel and team’s hard work of building a TrueType font backend to McCLIM came in handy and so I got to work in making a simple proof of concept.

CLIM is a really interesting design based upon the Common Lisp Object System, which is one of the most pleasing object oriented implementations to use. It’s a big and robust system with a very open design that allows for a ton of customization and flexibility. The spec is rather huge and I remember being kind of overwhelmed by it all many years ago.

I’ve since had two decades of professional and amateur coding experience with Common Lisp and coming back to this spec is still a lot to take in. Talking with Daniel, Robert Strandh, and I few others, I was able to cobble the couple lines necessary render a TrueType font out to the screen. Now I just needed a music font.

The game changer in the world of music fonts is the W3C standard called SMuFL, which defines a set of glyphs (plus relationships, ligatures, sets, ranges, attributes, engraving, and registration details) in a standard way, so that fonts can be used across various scoring software. These fonts typically use OpenType font files, which are an extension of TrueType.

Attempting to load OpenType fonts using the ZPB-TTF library didn’t work, so instead I changed tact to converting the OTF files into TTF files using FontForge, which ZPB-TTF could read, and subsequently McCLIM could render.

You can find the source for this here:

http://elliottjohnson.net/lisp/McCLIM/Leland/leland-ttf.lisp

The problem with converting OTF fonts to TTF fonts is that OpenType allows for the SMuFL metadata to be stored in the font directly. This important information is used to properly render and position the font in a viewpane, but during the conversion to TrueType all of this information was lost.

As much as I would like to extend the ZPB-TTF library into an EAJ-OTF library, it is a non-trival undertaking for a future-future date. Instead I chose to examine the JSON files that accompany the SMuFL standard as well as each compliant font. These JSON files provide all of the metadata typically stored in the OTF font itself for other font types such as SVG, WOFF, etc.

Using the JSON definitions from the SMuFL spec and Bravura the model font that the spec was built around, I was able to build out a library to parse all of the font metadata and load it in such a way that all of the definitions and associations could be made between glyphs. There 13 main phases to loading a SMuFL font, each with a need to pull in data, cross reference and build out the font metadata for general use.

After doing the proof of concept, I dug into the SMuFL spec and started writing code to parse and relate all of the JSON data. The result is a library called Cloveleaf:

https://github.com/elliottjohnson/cloveleaf

Cloveleaf allows for a TTF metadata font to be defined, loaded, and prepped to use by other software. The ultimate goal is to create a cloveleaf backend for McCLIM to allow the TTF fonts to be rendered using the correct positioning, ornamentation, and clarity in order to make a useful, readable scoring application.

The immediate goal for Cloveleaf is to get unit tests written, correct issues in trying to load lesser compliant SMuFL fonts and then look at OpenType support. If you have any comments or suggestions, please leave a note below.

My triple sloths module, which is an amazing source of chaotic modulation, took a dive.

The module initially worked, but the “apathy” portion of the module recently started outputting a constant -12V instead of the ever undulating voltage that I’ve grown accustomed to using in practically every synth patch.

On President’s Day I had a moment, so I visually inspected the board and all my hand soldered SMD connections looked OK. I verified all of the values of the resistors and the position of the ICs. Using the multi-meter I also confirmed all of the connections in the Apathy circuit to ground and the voltage supplies. Everything looked good.

At the end of all of that I wiped down the module to remove all of the left behind solder flux. Plugging it back in it worked!! Great, all done :)

Of course that wasn’t the end of the story, because after adding a few cables it went back to not working. The fact that it was intermittent was an clear sign that it was a non obvious bad solder joint.

Re-flowing the solder with lots of flux was the next step and greatly improved the soldering around the ICs. Another quick wipe down with flux remover and it fired right back up and ran as it should.

Happy ending, nice smooth modulation and back to making music.