I have a question that’s really been bugging me for a long time, and I’m wondering whether any of you have any insights.
I love the Turing machine dearly, but there’s a problem with it that causes me to sometimes hold back on using it for music: It regularly just stalls! It simply stops producing notes for a while, just sits there with no lights in the queue and then after a while it starts again. It’s very odd and is obviously not conducive to using it musically, because dead air is not pretty.
This is a problem with both the Stellare Turing Machine and the newer ALAN, in exactly the same way. As far as I can tell, it’s completely independant of parameters used, on twiddling knobs or just leaving it alone.
Does anyone know whether this is a problem in the original hardware module as well? Or is it simply a flaw in the software implementation of the algorithm?
Do you experience this as well? Has anyone never experienced it?
Thanks for any insights!
In more seriousness, a good test would be to throw the ALAN to 100% Alpha when it starts showing a chain of zero bits. That should force the bits to always swap meaning the chain of zeroes will become a chain of ones. If this happens then the sequencer is working correctly and we can rule out memory bugs as the culprit.
Assuming the above test fails: some interesting memory problems might be happening and it’s likely other modules would break randomly too.
Assuming the above test succeeds: it is possible that your computer is just magic however it would be possible to put in a system that detects if some very unlikely stream of non-flips occurs to kick the random number generator so this stops happening for you.
I can verify Lars’s experience, I recorded a performance today that includes a long section of pretty much nothing happening, i.e. no looping sequences. However, changing the Length value usually kicks it back to life.
Thanks for your reply Skrylar, and Dilbert quotes are always great.
Dave (above) is on Linux I know, and I’m on Mac, and a couple of months ago I happened to catch someones’ patch video, where the Turing stalled, and as I recall it was on Windows. So I think we can reasonably rule out platform-dependency.
My machine (iMac) behaves pretty exemplary, I have no weird problems with the OS or any other programs, my Rack runs rock-steady and all the other modules run fine, barring the inevitable bugs, so it’s reasonable to rule out flaky hardware or OS.
Since this happens in both Stellare Turing and your Alan (thanks by the way!), I’m left with two reasonable hypothesis (Occam’s Razor and all):
This is an algorithmic flaw in Whitwell’s original hardware implementation, and so is simply inherited in other software implementations.
Stellare Turing and Alan share a common ancestry of software implementation of the algorithm, which has a corner-case flaw that causes it to stall once in a while, which is unfortunate for making music.
Whatever the case may be, it’d be wonderful to have the problem identified and fixed.
If your above “test suceeds” was a suggestion that you could provide a special debug-build, that I could run for a while to try and catch the flaw, I would be happy to try that. Thanks!
Aha! Thanks! Very interesting - hypothesis no. 1 confirmed. It obviously begs the question why Whitwell hasn’t fixed it. Does no one complain about it?
I guess you’re right. However I don’t turn the knobs that much and so I’ve been bitten by it quite a few times now. How lovely it would be, if in Rack we could fix this particular problem and thus make the Turing even better for making music (Think: “Rack - even better than the hardware”) . Up for the challenge @Skrylar? I’ll help running crazy test builds for long hours, promise…
Tom Whitwell graciously replied on that issue, and it wasn’t the reply I was expecting But I think he makes great points and I think the only thing to do is: Live with it and be happy
It would still be great to attempt to fix this particular problem in software though, which would make it even better for music making. As I write on the issue - maybe attempt to detect this particular condition, and temporarily speed up the generation. That might work, or…?
It would likely either be to reset the random number generator, or continuously read from it until a flip happens. I’ll work on it when I touch that module next.
however it would be possible to put in a system that detects if some very unlikely stream of non-flips occurs to kick the random number generator so this stops happening for you.
. Up for the challenge 
But I think he makes great points and I think the only thing to do is: Live with it and be happy 