Flex vs Static latency/accuracy issue

Elektron Gear Octatrack
#1

Usually I just use flex machines for everything, and try to keep my projects small. But the other day I found myself running out of memory, so I used a static machine to hold 2 fairly large wave files.

Heres the issue…

I have scene B setup with the slice parameter to play different slices than scene A.
So that by moving the slider, I can have almost infinte variation options just on one pattern.

When I had these tracks on the flex machines, using the fader to play different slices/pieces was instantaneous and accurate in where the slices played from. So I could use muscle memory to play certain phrases, based on where I was on the slider.

However, after moving these two tracks to static machines…that trick of using muscle memory dissappears, because theres noticeably less accuracy in what slices play where, and even if they will play at all. Theres also very noticeable latency in me sliding the slider, and hearing the slices playing different slices. Like quickly sliding from left to right and back again on a flex, would play a neat little pattern, but now doing that, does nothing, since the slide seems to be too fast to even register??

Anyone else experience this? Its unfortunate, because most of the time, I need this feature, with larger “songs” sliced into bits. And static machines are perfect for such tracks. But this glitch removes any reliability in a live setting.

Any ideas on what can be done?
I guess just try to downsample and compress the tracks further?? So that I can use them on flex machines without taking all the memory.

Or do I just have a faulty machine?? It would be nice if someone could try with theirs and give me some feedback. Slice a large static track into 64 slices, and lock scene B to different slices. Then play with the fader. Then do the same with the exact same track on a flex and compare the results.

#2

Yes, this has been discussed a lot before … your machine is not faulty, CF card access is significantly slower than RAM and you will observe latency/glitches

2 Likes
#3

Using the fader to jump between slices is one of the few cases where flex makes more sense than static. Maybe you have other samples that are just being played back, they’d be better candidates for moving to static.

2 Likes
#4

I’m preparing a sample pack today, and testing it out in STATIC, but keep having Slice issues too. The worst most fundamental issue for me is that each time I play a slice, the first time it’s being played, playback starts a few samples into the slice, creating a pretty audible tick sound in the attack of the sound. This is especially audible on bass frequency sounds (because of the “slow waveforms”). When the same slice is played again immediately thereafter it sounds right. Probably related. But I’d say this is actually a behaviour that should be possible to get rid of, if they prioritise this. It’s such a consistent behaviour.

3 Likes
#5

Some months back I sent a file demonstrating it to Elektron, what I noticed in this particular case (32 bars of a repeating 1 bar bass line, sliced into 32 even slices) was that certain slices would sometimes randomly click, other slices never seemed to click, and this was regardless if triggered manually or from the sequencer.

@tnussb theorised that it was a card cache issue, which seems to be a sound theory, I think that if some kind of small buffer could be allocated for each slice it should allow the slices to be played correctly, maybe an option in memory allocation to reserve a bit for static “overhead” would be a good idea.

6 Likes
#6

Yeah, that oughta be a good approach. If the system allows for it without a total rewrite :see_no_evil:

1 Like
#7

This shows clearly that there is some caching going on (the second time around the data is already in memory).

I guess the required changes for preloading at least the very first data block of each slice aren’t technically that complicated to accomplish.

But the firmware has maxed out its available code space. So to fit in any new feature means rewriting and optimizing code somewhere else to squeeze out some free bytes for the new code. As you can imagine this isn’t an easy task.

My guess is that it won’t happen. While it’s very likely that we see more firmware updates in the future the list of possible improvements is long and there are also still some bugs lurking around since years needing attention.

4 Likes
OctaTrack + iPad Track
#8

I’ve been using slices(16) in Static as they are quite large wav files. And i noticed thats very hit and miss. So much so that i will try and avoid it if i can.

#9

…with a highspeed reading/writing access card and some not too deep folderstructure, static machines can do pretty much almost all the tricks a flex machine can offer…almost means only some fast lfo accuracy and realtime retrig tricks on demand can’t catch up with the access speed of ram, of course…

giving static machines an additional buffer is impossible…userwise…as coding wise…for the ot…
remember the days, when ur daws were handling big sample libs…?..and what a trouble it always was with all this prebuffering…sample starts all in ram, just to catch up seamlessly with the rest of it, coming from harddrives…what a mess.

#10

Hmm, I think that when talking about slices clicking we are only talking a few milliseconds probably <20.

So the idea of allocating a small amount of sample ram to sliced statics should easily cover the delay of the flash memory catching up, but of course this is probably difficult to implement at this stage in development.

However, I do find it a bit unacceptable that static files can not be reliably played using slices, which renders the feature somewhat useless under many scenarios.

Maybe a better and more realistic solution would be a very fast fade in from zero to eliminate the clicks, or some kind of optimisation of the current cache code.

2 Likes
#11
  1. Folder structure has nothing to do with how fast the data can be accessed once you have already a file handle.
  2. Even with the highest possible read speeds there is always some latency involved. At 44.1kHz you miss out one sample value for every 0.0227 milliseconds of latency. So without any preloading/caching a few sample values will always be missing.

That’s definitely easier to implement, but may also kill very fast transients.

4 Likes