W/ Firmware Update (v1.2.1)

Some new bits for your W/. If anyone would like to help beta test, I’d love to hear your feedback on this new firmware! There’s a lot of changes (listed below). A lot changed under the hood to make this possible, so it’s likely not completely correct yet!

Download & instructions here.

To clear a tape: Hold record + down while turning on the synth, then follow the prompts.

Edit: Changelog v1.2.1:

  • FIX issue where uninitialized flash could lead to accidentally erasing parts of the SD card
  • CHANGE ‘clear tape’ command (down + record at boot) will exit Izzy to the default tape.

Edit: Changelog v1.2:

  • FIX some persistence issues across power cycles
  • FIX bugs in Izzy causing desync between audio & expected commands

Edit: Changelog v1.2_rc0:

  • FIX Keep-alive for SD card more frequent to avoid occasional remaining crashes
  • NEW CV selector for LIVE mode (see docs)
  • FIX looping no longer breaks when fast-forwarding to end of loop in CUE
  • CHANGE hold-time to enter GLOBAL slightly increased
  • FIX clicks at loop points further reduced
  • FIX SD driver could hang with too many previous/next cue jumps
  • NEW broken SD data will be repaired rather than discarded (no need to ‘clear the tape’ any more)
  • FIX workaround to avoid an issue in Izzy where playback could get out of sync
  • FIX reversing in CUE mode could cause module to freeze in rare situations

Remaining issues for 1.1 release:

  • BUG fastforwarding to end of loop in CUE mode can lead to unresponsive cue navigation
  • BUG clicks when using LIVE.THAT cv while live-looping & changing direction (fw/rv loops are off-by-one frame)
  • BUG clicks in very short loops when using LIVE.THAT
  • FEATURE repair damaged cue list at module/tape load (currently just clears)

Edit: Changelog Beta12 (v1.1)

  • FIX cv functions in LIVE mode no longer stop working after hitting start/end of tape
  • FIX NAV.THAT now checks if the cv level can free a tape locked at the start/end

Edit: Changelog Beta10

  • FIX using both CVs while looping, and manually toggling NAV/LIVE can cause hard CRASH
  • LIVE.THIS cue redirection better handles edge cases
  • First cue on tape can now be looped in reverse

Edit: Changelog Beta9

  • FIX last-cue-location correctly restored after power-cycle (was saving, but not loading)
  • FIX unresponsive forward playback due to wild pointer access

Edit: Changelog Beta8

  • FIX tape-selection & last-cue-location saved between power cycles
  • REGRESSION audio glitch when changing tapes returns

Edit: Changelog Beta7

  • FIX playback aliasing when tape moving in reverse
  • FIX tape-selection was being forced to top-left since b6

Edit: Changelog Beta6

  • input monitoring now continues to work while changing tapes (reduced click even further)
  • FIX: module no longer freezes after ~10+ minutes of non-use

Edit: Changelog Beta5

  • save engine overhauled. all changes are guaranteed to save within 5 seconds of occuring. power-loss while recording will no longer lose everything since stopping the tape.
  • tape-switching no longer has a loud click
  • improvements in sd driver for reliability & error handling
  • more data integrity checks on module / tape load

Edit: Changelog Beta4

  • clicks on loop-boundaries have been dramatically reduced
  • record & overdub level have more smoothing to reduce clicks when activating/deactivating recording

Edit: Changelog Beta3

  • fix issue where tape-selector couldn’t be accessed

Edit: Changelog Beta2

  • increase sdcard buffer for lower chance of dropouts
  • fixed some undefined behaviour when adding a cue / setting loop fails
  • loop lights in CUE mode now reflect full traversable distance
  • fixed issue where CUE mode, after the last cue, would stop when winding forward
  • if leaving CUE mode after the last cue, loop will now turn off automatically
  • refined some led feedback (clearer loop status indication)
  • added ‘clear cues’ command [in global, hold loop for 1 second, then press record] (WIP)
  • audition in CUE mode avoids some undefined behaviour with unexpected command combos
  • writing to microcontrollers flash (tape-selection) is now irq protected (hopefully
    fixes, forgotten tape after reboot)

Changelog Beta1

For the W/ project, since the initial 1.0 release.
A lot of this is from memory so likely missing bits.

  • If SD card is not blank but has invalid data, W/ will re-initialize it (fixes case where W/ freezes after completing Izzy)
  • fix crash in I2C driver where too many commands would lock up the i2c bus
  • light driver is more efficient, faster (120hz), and has 4x as many brightness levels.
  • corrected numerous issues in the cue navigation system. particularly addressing start & end of tape situations.
  • fixed issue where the start of the tape could be ‘moved’ in CUE mode (which would mess up all the other cues!)
  • SD card driver no longer freezes if a page is requested that is outside the range of memory (previously resulted in playback & recording failing until restart)
  • fastforward & rewind now work correctly after exiting CUE mode
  • changes in global mode are saved upon leaving global
  • fixed crashes when changing tapes
  • after changing tapes, the tape is now always in NAV mode
  • tapes default to output-monitoring ON after factory reset
  • THIS CV in NAV mode now works correctly for reverse motion (THAT cv, or ‘rewind’)
  • THIS CV in CUE mode now one-shots correctly if CV was already inserted before switching from NAV mode
  • corrected high-speed recording resampler. much less aliasing above 1x speed
  • playback resampling now uses 3rd-order lagrange interpolation (less aliasing, better HF response)

20 Characters of Thank you very much

1 Like

Thank you for your hard work!

Thanks for all the hard work! I’ll test this weekend and try my best to keep track of what I’m doing so I can feed back.

Really pleased to see this. Thank you. I won’t get a chance to test this for a few days sadly, looking forward to though.

Can I suggest that an accompanying getting started video for the official release would go a long way towards diffusing the confusion around expected behaviour VS user error.

Something like this?


I feel a bit silly for asking, but is v1.0.1 the firmware it shipped w/? Or do I need to install that first and after that install the beta?

It shipped with v1.0.1 (moreorless). That file is just there in case someone wants / needs to revert. No need to touch that file! I’ll update the instructions to clarify.


installing now! Thanks for all the hard work!!

Amazing - will install and start playing around with the beta this afternoon.

Big thanks for the update! Just installed 1.1.0b, everything seems stable and smooth.

Instantly noticed that i really miss that aliasing:(

@Galapagoose, thanks for all the hard work on this. Question (thinking like a developer/QA tester here): do you have specific interactions you want people to test for, or is it more preferable to turn us loose on the firmware beta and see if we can break it?

Both can be useful, but I’m thinking in terms of doing QA on the specific things that were fixed. Not wanting to place further burden on you, but also wanting to make sure you get the testing/feedback you need.

To be honest, we had a very difficult time recreating bugs people reported previously. This is for 2 reasons: 1) the bugs themselves were intermittent, and 2) they mostly seemed to be caused by the ‘state’ of the machine (which just happens to be the contents of a 4GB sdcard). Most of the firmware changes were in pursuit of a more robust handling of cue-points which were the primary suspect in the ‘bad state’ search.

I think the best way to test for the correctness of state in that regard is just to use it! Trying to break it is welcome, provided you can list a series of steps to reproduce preferably starting with a clear-tape command. If a bug you find isn’t reproduced after clearing the tape, you’re missing some prior step that created the initial erroneous state.

Does that answer your q?


Thanks! Great start to the weekend! BTW, I know this update probably had priority, but is there any news on W/ Type?

Completely, and very helpful to know.

When I create bug tickets at work, I generally include expected result, actual result, and steps-to-reproduce…this helps us write tests and also test that the specific problem experienced is reproduceable and was fixed.

If it was mostly difficult to reproduce and/or intermittent problems (and oh boy do I know about those) then just turning us loose on the firmware is probably the best course.

Thanks again for doing this! Will load and play tonight. xoxo

The infrastructure is all there (including for multi-W/ standalone control), but we haven’t had the time & space to actually design the interactions yet. Once a spec is complete, I imagine the implementation to happen quite rapidly.

Edit: The current very-minimal spec should be merged into the forthcoming teletype 2.3 release.


It’s a 3 day weekend here. Definitely going to give this a run.

i just picked up a second w/ because it’s brought my lofi sampling a lá dr. sample styles into the modular, which has been amazing for me.

to see these bugs in writing really is awesome, since up until now, it was seemingly random for me. rare, but seemingly always to do with moving to a new cue point in the current tape.

i was reluctant to monkey with the card/resetting, as i wasn’t sure it wouldn’t make things worse. this is all reassuring and thanks a lot for the upgrade/update!



Me too, and when I posted on Facebook, it the first thing that was mentioned by another user. Aliasing can be a good thing :slight_smile: Best not to call it aliasing, call it character!


I think it was a bit much for most purposes before. It still gets nicely grungey IMHO. Though if there were an option to switch between the previous and current sound (maybe from W/ Type) I wouldn’t complain :slight_smile: