Static slices clicking on first pass

Elektron Gear Octatrack
#1

We all know you can’t expect a static machine to keep up with some crazy lfo modulations, but i’m consistently getting this dropout (i think since one of the fairly recent updates, i’m on 1.25H)

This is with the stock later CF card, has this been discussed before, thoughts ?

Getting bad clicks on a simple Static chain when i go from a high slice to a low slice, the low slice will play fine after it has played once- it all works well on a Flex m/c

This has happened on and off a bit lately

This ONLY happens the first time i come to that slice, it’s consistent, sometimes there’s an artefact on the other sample (first strike) … it may rarely even seem to go away, in that case i double stop and the glitch returns consistently

it’s just tapped out manually in slice mode, the first half is Static
Static machine clicks

Audio starts well but suffers a drop out !! Left is Bad, Right is Fine

dropouts.png1396×573 17.3 KB

Glitches when playing drum slices in Static machine
Modulating Start Time on Static Machines?
Slot locking statics
Slices and crossfader (drums, one more time)
#2

Ping me your project, I’ll see if I can replicate in v1.25E ?

1 Like
#3

Thanks… I can rustle up the chain perhaps, but this is just a single machine with everything else off, i found a similar issue with the AR recently using chains

I was wondering if it had been noticed before or if anyone had a thought on why the dropout would happen so soon into the initial strike of a slice, i should have added, i think it was better when sequenced iirc

#4

I can add a bit more detail to this.
Sequencing the same ‘pattern’ will not introduce the glitch, so there’s some element of ‘anticipation’ engineered in imho

I’m sure it’s not related to the material i tested it with (but may simply be much more evident with simple low freq samples such that a click really pops out) and in this try out with the same chain, it was glitching more obviously on the alternate sample (this time double stop did not affect it in the way discussed above)

As it primarily affects live input, i’d be welcoming of any official insight in case it’s not explainable and this points perhaps towards CF card issues

Here is the chain, it was a drop of 16 random cr78 samples onto a chainer utility, so the order is not ideal, anyway, the sounds in the demo above are 2 and 15, but it pretty much clicks in live play on one sample or another - so in a new project, slice it in 16 and choose NO for zero crossing

Thought i’d flag it with @Ess too if you had a chance to comment/try :okej:
If you still wanna try in 1.25E @Rusty it’s 10s work to get to the testing point with sample :thup:

The above recording was internal re-sampling

#5

This is expected behavior.
A static machine cannot jump between extreme points in a sample rapidly without artifacts.

There is a buffer that will keep the sample in memory a bit ahead of current playback position, which helps prevent these issues in certain situations. It’s actually a quite complex algorithm that does some very cool things under the hood!

4 Likes
#6

Is this really expected ? ! Sorry to keep digging :wink:

I took that kick, took one channel of it, trimmed it, doubled it until I had 16 in a chain perfectly spaced forming a short sample

Now, I manually played from slice 16 down to 1 consecutively (and slowly) and the glitch happens at every step until I get to slice 4 (or so) when the slice plays without the very obvious glitch

I cannot believe that this is how it was before, otherwise surely there would be a lot of discussion on this, not just on fast LFO glitchiness, but for simple bread and butter sample-slice playing ‘slowly’ whilst recording a pattern in … it is surely odd that there’s not a lot more forum noise about this, even just as an observation

The manual certainly does not give the impression this type of interaction would be problematic, I also compared a sine tone chained in the same manner and it’s the same issue. If it has to be flex, then so be it, I’m just surprised this isn’t a common observation and thus my thought it was a new behaviour

Is this in any way mitigated by card choice ?

What I don’t follow is that the sample seems to be playing from the correct start point, but that the ‘streaming’ of the sample is interrupted after the start … it has the feel of something potentially fixable. I dunno, also wondering if I’ve missed something too !

I wonder if @myhrman can add a bit of perspective/science ?

#7

LFO’s and sample slicing can be surprisingly similar in effect! Both require fast lookup of a sample. This is something that is problematic with Static machines. Flex is there for a reason.

2 Likes
#8

+1 what @Ess says, only Flex can guarantee perfect results when slicing or modulating start point. Static player streams from card in real-time, but does so via a cache mechanism that - with some intelligence - tries to determine what parts of the sample should be pre-loaded into cache even before sample playback has started.

Note, however, that regardless of any potential dropouts in the beginning of the sample, the playback phase will always stay correct in relation to your other tracks. So you never have to worry about loops getting out of sync even under heavy modulation. Hence the reasoning behind allowing static samples to be sliced at all.

When you suffered from the dropout, were your slices selected manually (by changing the slice part parameter), or programmed in the sequencer with p-locks? The cache prioritizes things differently. For example, the trimmed start- and loop-points have very high priority, thus trying to ensure that traditional triggering of a (non-sliced) static sample never results in a dropout. Slicing is a little bit different story though, since it has a lot of potential start points (due to the slice trig mode).

At what sample position in your kickdrum do you get the dropout anyway? And is this position consistent? May be worth checking if it’s at an exact cache page boundary.

3 Likes
#9

That’s a useful insight, as indeed were some of the comments. I can now see the picture a little clearer.
My observation was that it was always glitch free when manually playing the trigs in slice mode if you tapped on 1 and 9 (also 3 it seems). I also noticed that the glitching was consistently worse if you stepped backwards (16 to 1) through the slice trigs than forwards (1 to 16)
I can now see, as you allude to, that the STRT Param set to SLx will ‘protect’ SLx
So indeed there’s a selection of aspects being managed behind the scenes.

My probing was fuelled by not having noticed this (it is incredibly obvious) and not having read about it, using Flex machines may not be an obstacle most of the time, but it’s nice to preserve the RAM and know the limitations … it will play back impeccably if sequenced, but if you rely on live recording in, then use Flex if possible
.
.

I screengrabbed the glitching for manual Trig playing (STRT Param SL1, no sequencing) 16 down to 1, i trimmed the first three cycles from a low C (~65Hz) Sin wave chain (x16) and have highlighted how the dropouts manifest. There are occasionally glitches which interrupt streaming (as discussed above) but mostly these show that the initial phase of the slice is omitted (a consistent length)

I’m not sure what a cache page boundary would be, but for my purposes i only needed to satisfy myself of no CF card issues. Going forwards, if it’s not a bug, but merely a constraint of the technology i’m happy to adapt, maybe the manual could be more upfront in this regard (alongside fast LFO comment).

StaticChainDropouts.png1349×733 53.4 KB

Hopefully someone will find this useful and reassuring, a comment on the wisdom of faster CF cards would be welcome

1 Like
#10

I don’t think a better CF card would help very much. I’ve always experienced clicking on all my CF cards.

1 Like
#11

I also ran into this issue several times. I p-locked slices on the sequencer using a static machine, and I also got clicks occasionally. Same experience when playing slices live even on slow tempo.

One thing that I feel a bit conflicting to what Simon stated above (“This is the expected behaviour”) comes directly from the Octatrack’s manual:

“Parameter locking the STRT parameter will however make the sample play back exactly according to the locked position.” If it clicks where it shouldn’t, it’s not exactly the locked position :slight_smile:

#12

My previous research on static vs flex led me to believe flex would work fine when doing normal p-locking of pitch on slices.

This thread throws a wrench in that.

Seems like the rule should be always use flex machines when slicing (at least for me).

Any news since this thread was last updated?

#13

I’m not sure there’s any prospect of change wrt slices played back from static machines - what intrigued me was that there seemed to be slice positions that worked consistently well

I think I may have investigated further or revisited this if the official comments weren’t so discouraging about the realistic potential for static machines to be used in this way - there seems to be some coding in there to anticipate what a user may try which mitigates the issue somewhat, but whether this has changed/improved seems unlikely

3 Likes
#14

I’m loading up sliced samples with drum hits into a Static machine and had a problem with a click/glitch at the start of a sample. It was weird because it would only glitch the first time play a slice, if I played it multiple times then no glitch, but changing slices often glitched on the first trigger of it.

I guessed it might be a problem with it loading from the CF card and yep, when I load it into a Flex machine then it works fine.

Is there any trick to avoid this and play drum slices off the CF card? From the manual I thought this was possible/supported if you didn’t do things like set LFO to start points, etc.

I’m not doing anything fancy with the sample/slice, just triggering drum hits and I’d like to avoid taking up memory if possible (as some of the cymbal samples are pretty long).

#15

Probably a card issue…

Which CF card are you using?

I use a Sandisk Extreme 64GB, which is quite fast, and doesn’t give me any issues.

#16

Exactly the same card :confused:

I’m wondering it it could be anything else but it seems unlikely at the mo.

#17

I’d backup, format card, restore. just to rule out the easy solution

2 Likes
#18

Cheers, sounds like a good idea. I’ll give that a go.

#19

moved to existing topic - see above - not a card issue

#20

Ah ok thanks. I’ll stick to flex machines for this.