Developer Notes: MD-004 Tonic

Introduction

MD-004 Tonic was originally conceived to bring an emphasis to Juniper's V/Oct quantization capability while complementing Juniper's small form factor. During the first prototyping phase the following requirements were formulated:

  1. It needed to be small, ideally 4HP. This fits the space requirements that the target audience would have. People generally want Juniper and Gin because of their small footprint, yet powerful feature set
  2. It needed to communicate with Juniper, similarly to how Gin works
  3. It needed to have an octave keyboard
  4. It needed LED buttons to support additional functionality
  5. It should have diatonic and chromatic transposition modes
  6. A live mode, so users can shift the root note arbitrarily
  7. Some method of changing scales (as of 0.6.0 a user can have up to 8 different scales per channel)
  8. It should be easy to manufacturer, and,
  9. It should integrate seamlessly into Juniper and allow recording etc

As a result, the following technical requirements were laid out:

  1. An I2C connection via a 4 pin 2.54mm connection, using the same Dupont cable used with Gin.
  2. An I2C LED controller capable of PWM (far beyond the audible range of 20kHz) and supporting at least 16 channels
  3. An I2C GPIO expander capable of providing 16bits, one bit for each button used
  4. No MCU would be used, and the I2C bus would be controlled entirely by Juniper
  5. A dedicated power header for +12V and subsequent regulators to provide +3.3V

I2C Bus

The I2C bus communicates directly with Tonic's LED controller and GPIO expanders without any MCU intermediary. This design choice allows firmware for Tonic to be simply bundled together within Juniper, reducing complexity. The I2C header is a 2.54mm 4 pin header. The header provides the typical I2C SDA and SCL lines, as well as a "reset on high" push-pull driven pin, and ground.

When Juniper boots, the reset line is pulled low, then high, then low again, signalling that any expanders connected to reboot also, as necessary. This is crucial for ensuring that the expanders and Juniper remain synchronized and in well-known state on boot.

On the Tonic side, the GPIO expander and LED controller have a "reset on low" input pin and they are connected via a pull-up to 3.3V to ensure normal operation when the reset pin is in an floating state. A simple Schmitt-Trigger Inverter is used to invert the reset line so it works correctly with the GPIO expander and LED controller.

First Cut

The first design of PCBs worked as expected, but there were still many unknowns about optimal layout, as well as button functionality and combinations.

One major issue with this prototype was that the function buttons were located at the top of the module, this was a problem because Juniper and Gin have the 3.5mm jacks at the top of the modules making these function buttons very difficult to reach.

As time progressed the firmware was developed and the proof of concept became operational. Through experimentation and performing with the original concept, it became very obvious that transposition should become a major feature of Tonic.

Second Cut

In order to support the idea of having configuration buttons which would include transposition intervals, as well as the actual notes enabled or disabled for a given scale, a shift button would be needed. It made sense to have this as the primary button as close to the user as possible. To support this idea of transposition, up and down buttons would be required. 

Settings such as PRE, or POST would reside on the black keys, while the transposition intervals on the white keys. After some research I decided on the intervals: semitone, whole tone, minor 3rd, major 3rd, perfect 4th, perfect 5th and octave. 

This design made a lot more sense and upon testing we were very satisfied with the result.

Firmware changes

Embassy.rs

The 0.7.x firmware was developed primary to support Tonic, but this also included a large change to the underlying libraries used by Juniper. Juniper originally used the RTIC.rs interrupt concurrency framework, which allows safe concurrent interrupts utilizing a priority locking scheme, but of course these come with significant overhead. So as time went on these locks were replaced with lockless data structures, such as atomic memory ordering or SPSC queues (ringbuffers). These would provide a more performant strategy for task synchronization. At the same time, Embassy.rs was starting to mature which provided a much more active community, and also an async-await interface which could seamlessly work with the STM32's DMA controller. This resulted in a much more elegant and performant way of dealing with concurrency. So for longevity and to streamline Juniper with newer products, Embassy.rs replaced RTIC.rs.

Adaptive frame-rates

The display rendering routine was originally fixed with a hardware timer at 60 frames/sec. This was of course, an overkill implementation as a more typical way of handling UI rendering is to use a relaxed approach, e.g. a software defined task that updates at roughly 60 frames/sec, but not strictly. This essentially frees up resources for other peripherals allowing the more time-restricted DAC to generate samples in real-time. To adjust for this, the animations are now also adaptive. 

Recorder performance

The recorder implementation was also rebuilt to reduce the data copy overhead when sending data from the signal generation task to the storage persistence task. Although this is still performed by the software (ideally this would be performed by memory-to-memory DMA transfers), its a much improved implementation compared to 0.6.0.

Manufacturing overview

The way a product is manufactured is often overlooked by the end customer, but it makes a significant impact on the day-to-day operations of any business selling hardware. When you sell a small handful of units, complexity doesn't really matter because you can do it by hand, but this scales poorly and ends up eating away at precious time that can be used for further R&D of new products, generation of marketing materials and other operational tasks. So, Tonic really embodies a manufacturing-first mentality to ensure it can be stocked at retailers, easily. 

Everything on the board is soldered by the assembly house, and only the final assembly which consists of fixing the panel and testing is conducted by hand in the lab.

Conclusion

MD-004 Tonic was a successful story, from conception and implementation to manufacturing and shipping. This smaller project was crucial for Mnemonic Devices as a step-up toward our new flagship product, MD-003 Mikado, which will available for pre-order mid '25. 

Back to blog