W/ Firmware Update (v1.2.1)

i think i found a bug with the replacing function while in live mode, reverse playback.

my patch is trigger into THIS
cold mac into THAT sending around +4 volts
mangrove being played by tsnm going into w/

forward playback recording into live mode with a loop about 3 seconds long, getting nice echo stuff. replacing is on, and when record is toggled whatever is recorded to the tape fades away as you would expect when nothing is going to IN.

switch to reverse playback, replacing still enabled, record toggled, and there is a little blip stuck in the loop that will never get replaced when silence is going to IN. i have to switch back to forward playback and then it fades away normally.

when i start live mode in reverse playback, there is a click that doesn’t happen when in forward playback, but other than that the tape does replace correctly this way. as far as i can tell it’s only when switching to reverse playback after recording something in forward playback that these little bits get stuck in the loop…

1 Like

A video showing the behaviour I mentioned earlier. Once the module was in this state I had to downgrade the firmware to get it working again.

It seemed to be a problem with this particular tape - so upon loading the old firmware I moved further into it (I think I was trying to load right at the start), I then reinstalled beta4 and was able to boot into the tape successfully. I then cleared queue points which appears to have fixed it.

I experienced the same unresponsive state. I updated to 1.10b and it was working fine for a while until I entered Cue mode and tried to switch tapes. When I pressed down to load the new tape the module froze with no lights. Switched on and off, still no lights. Tried few more times. Tried Holding down+R, Tried Izzy. None worked, zero lights. Holding record when powering on did engage the bootloader. I thought perhaps my switching PSU (Pittsburgh 270) could be an issue so I switched cases to a uZeus. No difference. Reinstalled 1.10b, still nothing. So I reverted back to 1.01 and the module began working fine again. I deleted the tape it had been on just in case. I didn’t experience any other issues in the limited time (still on the 1.01 firmware). Will be installing beta 4 tonight and will report back.

I got SD card driver to crash? the unit responds properly to commands, but when playing, the orange light over loop just blinks. Just left the synth on for an hour or so while I made dinner, patch cables going into in and out but nothing happening.

Sorry – this won’t be especially helpful due to lack of reproducible steps, but I wanted to mention that I’ve gotten stuck in the short, infinite loop bug a couple of times on the newest beta, where just a sliver of a recording gets captured.

That said, the beta feels much more stable overall, and the reduced clicking on loop points has made this an even more beautiful thing for delay experiments.


Sorry it’s been a few days. If you remember, can I ask if you did a ‘clear-tape’ since installing the beta? Specifically I’m surprised to hear it locked up after trying to change tapes. I thought that bug had been fixed.

Oh just realized. Are you saying you tried to change tapes after the ‘short loop’ began? If that’s the case it totally makes sense as the SD driver has crashed & so the tape-change code will never return.

Speaking of, I’m going to add a timeout for the Change-Tape command such that it will detect a frozen SD card & reset the driver. That way if you experience the stuck-in-loop behaviour, you can just reload your tape to get back to a working state. A workaround, but good to have just in case.

I’m going to look at the load-tape details to see if there is more ways to verify the data is valid.
In your “oh no” moment, you could do a ‘clear-tape’ to get back to a workable state (record+down while turning on). It appears to me that the cue data stored in that tape is invalid & causing the module to try and load non-existing data (and waiting forever for it to return). again, timeouts should be implemented, but obviously finding the source of the problem is more important!


Do you mean a click when you engage playback, or a click at the loop point? Noted the point about the blip in a reversed loop, should be a quick fix…

@alanza @stripes
Special thanks for group testing the NAV/LIVE crash bug cv thing. I would never have made the leap that it was related to looping. Hoping to get this one today.


I haven’t had any problems since clearing the cue points on that tape. If you’ve been able to fix the issue with creating invalid cue points - It feels like it be might be worth forcibly removing them when people bump to this firmware. Or at least strongly advising it in the patch notes? :slight_smile:

1 Like

Is there any chance of getting a clean current tape TT op in the near future (it would be really ncie to have that prior to the TT v2.3 release).

I don’t think so, the reason being 1) it creates a loud click as currently we have to turn off the codec to do this without crashing, or a bunch more code, and 2) it doesn’t seem like a performative command. I’m sorry to insist, but I’d far prefer to fix the underlying problems rather than provide bandaids. Sorry it’s taking so long to get to the bottom of it all!

It does recommend to clear all tapes up top on this thread. The problem is once there’s a single invalid cue, you can’t trust the rest of them (because it’s a linked list and they are created relative to their neighbours). Thus the only real solution is to delete them all. That’s what the firmware is meant to do now, but clearly it didn’t work in your case… It’s on the list!


I still think it could be useful in a performance context (build up tapes and layers, fade down, clear tape, go again). I wasn’t so much suggesting it as an alternative to fixing the tape issue.

Can you also update the docs to include the commends for clearing tape. (note to self: find the instructions and bookmark it this time!!)

I’m thinking this is better solved with a different solution (eg. switching to a different tape. jumping to a next (known empty) cue. clearing the tape with overwrite). Certainly there’s many options for these types of things, but I’d like to give it the time to make sure the metaphor is as consistent as possible.

Funnily enough, I just (for the first time) am experiencing the ‘won’t turn on’ bug, even after factory_reset-ing. Yay! I can actually debug it!


Fair enough. It’s hard to roll this stuff back if it turns out to be the wrong decision.

1 Like

I think I may have been slightly confusing - the tape where I had problems was one for which I hadn’t cleared the cue points. I’ve been able to clear them now and everything seems good!

repeating click at the loop point, it seems

1 Like

After flashing the current firmware, my unit consistently boots at the beginning of the tape rather than the last cue point at power-down. I tried switching tapes and deleting all cues on all tapes I’ve used, but the issue remains. The active mode on power-down makes no difference (I haven’t cycled power in cue mode).

I have not cleared any tapes, but I did start on an unused one after installation.

yes this is what happened.
Glad to hear there will be a workaround!! Thanks for the hard work and lovely machines

edited for bad quote formatting

Oh, I’ve always had this happen to! I thought it was intentional xD

With the first beta, It seemed to happen less frequently. I jumped from that one to the current and I’ve only had it reboot to the last cue once.

Edit: make that thrice. After posting, I gave it two boots and both started where I left off.

Anyone know the brand of the sd card? I know it’s 4gb but was thinking of trying Sandisk and Kingston cards. Is there any limit or disadvantages to using a bigger card? 8, 16, 32 gb? Wondering if changing the card will iron out some issues as cards are pretty cheap nowadays.

Main requirement is it should be a class10 card. Don’t use a U1 or U3 (eg Sandisk Ultra) as they prioritize continuous read/write and are dreadful at switching between read & write accesses. Typically these are only available in <8GB sizes.

W/ reads & writes in small 8kB chunks (necessary in a system with only 512kB of ram) and throughput is typically not an issue. I still believe the issues people are experiencing flow from driver implementation, and impossible accesses caused by bogus cue data.

We bought dozens of different cards and the particular ‘generic’ brand 4GB, class10 card we found to be the best for this purpose.

That said any sdcard will work (it will trash the filesystem), though you might run into different issues like gaps in audio etc.

Notably the metadata that saves which cue you’re at is only saved when entering NAV mode currently, so if you turn off while in LIVE, none of the changes since last being in NAV will be saved (including audio, cuepoints & metadata). This is currently being reworked to be done more regularly (whenever the sdcard access buffer empties).

Of course there could be a different issue if this description doesn’t align with your experience.