> When using the long one that came with the softstep my audiobox wasn't detected by the macbook. Switching to a shorter cable it worked fine.
That's a drag - you want the longest cable possible for performance!
So I now have some strong theories about this issue.
If you exchange a long cable for a short cable and your problem goes away, it's often an issue with noise on the line - that is, individual bits are getting flipped in transmission.
This can be particularly bad for MIDI devices, because a single bit flip can change data into a "command" (as in a note on) - and then due to "running status" you'll never get a chance to recover. Or it can change reasonable data to unreasonable data that will crash the software.
We do know that this unit is noisy in the audio fashion when the backlighting is on. It's not so unreasonable to assume that its line might be noisy too.
*** How to fix this? ***
You can deal with this on your end by getting the highest quality USB cable you can (not Monster Cable). I don't know much about USB cables, but there must be a known good brand with heavy shielding...
The firmware clearly needs to be much more robust. If I were developing this, I'd have the following criteria:
1. there should be no possible input - and by that I mean correct inputs, minorly incorrect inputs, malicious inputs, or just random crap - that could ever lock up the pedal under any circumstances or any data speed.
Clearly if you continuously flood the pedal with data beyond its ability to process, it is going to have some troubles - but you have to be able to do that and have it bounce back.
This is easy to test - you write a test harness that lets you do exhaustive testing and create a few specific tests - one with a flood of random data - one where you take a lot of real-world data and add random one-bit errors to it fairly liberally - one where you deliberately try to create malformed packets in many different ways.
2. The data flow from the computer to the footpedal should be such that *any* one bit error is corrected automatically.
I didn't just pull those numbers out of my, er, derriere, there are well-understood error correcting codes that will do this for you every time - they're called Hamming codes: https://en.wikipedia.org/wiki/Hamming_code
and with a little more work they'll actually correct any one-bit error in your packet and detect any two-bit error (and yes, that includes errors in the check bits too...
There's a nice 72, 64 code with this property - there's one byte overhead for every eight bytes you send and it can correct one and detect two with just that - impressive!
Hamming(7,4) with a parity bit is really easy to implement and corrects any one bit error (and detects 2) in every 4-bit chunk! It does have 100% overhead but in this application, this might not be an issue - I suspect the data flow from the computer to the pedal is a tiny fraction of the possible USB rate anyway.
(oh, and yes, I could write this. I'd give you the family rate - I worked on error correction codes around 1981, can you believe, and it'd be loads of fun to do this with more than 16K of RAM and a processor with a speed much greater than 1MHz...