I currently have OT MKII, before I had a MKI for a couple of years. In both units I have experienced the same issue:
When I’m going through an audio file which I’m slicing, I have my left hand ready over FN and YES and my right hand on the LEVEL knob. So as I move back and forward, I’m constanly pressing FN+YES to listen from where the pointer is at.
When you press and hold FN+YES it is possible to move the pointer over the playing area with LEVEL which makes a sort of temporary slice area from where you started auditing the audio until the end of it. I usually do this to go along the playback point and releasing FN+YES and pressing again to listen from a new starting point
AND THE PROBLEM COMES HERE (sometimes):
This action causes the Octatrack to stutter/get stuck for a moment, making any slices done before to disappear and leave only this temporary slice I mentioned before as the only one available. The only way I figured is to save every godly second so you can reload and get them back
Can anyone relate to this? is it a card speed problem? before I had another card with my OT MKI and same deal. It is very annoying specially when you’re trying to go fast with some preliminar slicing. I’m adding a video demostrating the action I described before but of course the error never happened when recording.
I think you have to retain a degree of realism about what is possible streaming from a card … it will not be a bottleneck of the card write speed it will be related to how the OT is reading, so i doubt changing cards would address the issue
Static is not like RAM (flex)
I linked a discussion where read/access speed is touched upon and you’ll see it’s kinda part of the territory for a Static machine
iirc in a further test even the number of a slice would appear to have a bearing, almost like the access algorithm was weighted favourably towards straight division points of a sliced sample - like 1 5 9 13 (of 16) but it would bug out a bit on in between numbers
It suggests to me that there is a degree of juggling going on in the OT to offset/prioritise the access-read speed ‘bottleneck’ to help the situation - it’s not something i expect to be as simple as a cared-swap away - i think it’s more fundamental to the hardware, but it’s best to accept a degree of compromise whilst using Static machines
I wanted to come back to this and give the best advice I found to anybody having this issue in the future:
Simply, just always work inside a slice when you’re scavenging through a long sample. Throw a slice down and use it to audit smaller sections of audio, so the machine doesn’t have to deal with the whole of it. It never fails
