New Unified Init File Maker App

In an ongoing attempt to be more efficient, I took a break from working on Tsunami and WAV Trigger firmware to develop a new Unified Init File Maker utility that works with both products.

In addition to looking a bit more up-to-date, it improves upon the previous individual apps in a number of ways:

  • One app will work with WAV Trigger and both mono and stereo versions of the Tsunami.
  • Offers online help with tooltips.
  • Provides live updates and remote control when used with a suitable USB-to-serial adaptor.

A beta version is now available and I encourage you to use it. The Windows and OS X versions are posted on the download pages of both products. Please use this post to provide any issues or feedback.

Note: If you use the new app to open previously saved init files, it will always open them as WAV Trigger files. You’ll need to start new Tsunami files (mono or stereo) from scratch.

A note about the linux version:

After doing some research into distributing Linux executables, I’ve come to the conclusion that it’s not practical to provide a ready-to-run Linux app that will run on all distros and machines. For those of you who want to run this utility on Linux, it’s not that hard, but you do have to download JUCE, install some dev packages, and then run make on the source project. I’ve included a link to the project’s source github repo on the download pages. When I get time, I’ll write up a step-by-step guide on how to do this (at least for Ubuntu) and include it in the repo’s readme.

Let’s Talk Tsunami!

tsunami_250

Tsunami is a new Robertsonics / SparkFun product, available now. Think WAV Trigger on steroids.

You can read the details on the new product page. I thought I’d use this post to discuss the design philosophy, how Tsunami differs from the WAV Trigger and what that means for you.

The WAV Trigger has been an ongoing exercise in optimization; trying to eke out the maximum performance in terms of number of voices without sacrificing quality and stability. I don’t ever want to hear a glitch, and nor should you!

While the WAV Trigger’s STM32F405 processor speed is certainly a factor, the limiting resource is actually the amount of on-board SRAM, used to buffer each wav file being played by a voice. The absolute maximum number of voices the WAV Trigger can support with 44.1kHz, 16-bit, stereo wav files is 14. Even then, I don’t have enough memory to support true seamless looping (which requires more buffering per voice.) With the latest WAV Trigger firmware release, I feel as though I’ve reached the performance limit for this platform.

Tsunami began when I read about the new Atmel S70 ARM Cortex-m7 processor and realized that it runs almost twice as fast and has twice the amount of on-board SRAM. If I was going to design yet another audio player, this seemed like a good place to start.

Another motivating factor for a new product was the fact that customers were writing to tell me that they really wanted more than a single stereo output. Indeed, some people were using multiple WAV Triggers not to get more voices, but to get more audio output channels. In addition, people are always asking about audio input, which the WAV Trigger doesn’t support since it only has a stereo DAC.

I started with the following goals based on customer feedback from the WAV Trigger:

  • More voices
  • Seamless looping
  • 8 line-level audio outputs (4 stereo)
  • 2 line-level audio inputs (1 stereo)
  • Reset button for changing microSD card without a power cycle
  • Ability to update the firmware directly from the SD card
  • Dedicated MIDI port so you can use MIDI without additional circuitry

I also thought long and hard about connectors. Everyone seems to want something different – 3.5mm, 1/4″, RCA, direct solder terminals… I ultimately decided to keep it simple and just provide dedicated 0.1″ header for everything. You can either wire directly to another unit or make your own connector/cable assembly. This also keeps both the size and cost down. Same with MIDI – No sense in burdening the board with a 5-pin DIN since not everyone will use MIDI. If you do, you can just cut the end off a MIDI cable, connect two wires to the header and you’re in business.

After selecting a multi-channel audio codec and designing a prototype board, I started porting the WAV Trigger code to get a feeling for the performance capabilities of the new processor.

Mono vs Stereo

Another consideration was that many customers have expressed a desire for support for mono wav files. Stereo is not necessary, or even desirable, for every application. And moving to a mono format increases the output routing flexibility, not to mention the fact that memory-wise I can support almost twice as many voices in mono as stereo. In considering this for the WAV Trigger, I came to the conclusion that supporting mono was too costly from a DSP standpoint. The WAV Trigger’s stereo DAC is actually better served by stereo data – it’s much more efficient because the wav files contain the same interleaved format that the DAC wants. Supporting mono playback in the WAV trigger would very likely have reduced the performance.

Tsunami’s TDM codec, however, wants the channels split to begin with, so the penalty for mono is nowhere as severe. Since Tsunami’s firmware can be updated easily from the SD card, without additional hardware, I decided to provide both mono and stereo firmware versions. (Supporting both at the same time is a bit more complicated, and I’ve provided a way to play stereo content in the mono version.) The stereo version is similar to the WAV Trigger, with 18 stereo voices to any of 4 stereo output pairs. The mono version provides a whopping 32 mono voices to any of 8 mono outputs. A new “Synced Pair” trigger function in the mono version plays 2 specified tracks out adjacent outputs for stereo content. (Yes, they are sample-synced.)

MIDI

MIDI was an afterthought with the WAV Trigger. By that I mean that when I initially designed the WAV Trigger, I had no inkling that the performance would allow for real-time playability. It wasn’t until I got the latency down to around 8ms and the voice count up to 12 (now 14) that serious MIDI control seemed sensible. While it works great, I had to share the serial port and customers have to construct their own MIDI input circuit (to convert MIDI’s 20mA current loop to logic level serial.) This is a royal pain.

So Tsunami has a dedicated MIDI IN (and OUT, not implemented in firmware yet) with an integrated opto-isolator. It’s a separate UART from the serial control port so you can use both at the same time. The firmware now supports proper use of MIDI Channel, including Omni mode. Even more exciting is a new file-naming convention that lets MIDI users specify the output and looping on a per MIDI note basis. Yes, you can map each key to any of 8 mono (or 4 stereo) outputs.

3.3V Only!

I know, but unfortunately the Atmel SAM S70 is a 3.3V device without 5V tolerant inputs. This means that your first choice in mating it with another microcontroller should be a 3.3V Arduino. Tsunami, like the WAV Trigger, has a pin-compatible header for the FTDI-Basic USB-to-Serial adaptor, but make sure you’re using the 3.3V version! For you modular synth folks, you have to voltage-limit the gate signals anyway, so this shouldn’t be any more of a burden than for the WAV Trigger.

Please use this post to ask questions and provide comments, feedback… whatever.

 

 

Update: First panel off the press: