Pre-sliced recorder buffer issue 1.25H

Elektron Gear Octatrack
#16

hey I just decided to look into this. When you save and assign the sample in a recorder buffer and choose “to SELF” then yes it does reload with the sample content, but it can still be used as a track recorder - albeit with whatever name you gave it rather than “RECORDING 8” or whatever.

The big plus is that the slices are still there, so it serves as workaround.

I guess that slices can only exist within content - & that’s why you just get that annoying ‘ghost’ slice when you reload a project, with its emptied recorder buffers.

I’d prefer a different kind of behavouir where the slice grids stay intact. As things stand you really have to be vigilant about this. Projects using sliced recorder buffers (which must be very common, no?) will always be broken when you return to them. Definitely not safe to rely on the working autosaved version - and the user save doesn’t help either!

Did you raise the issue as a support ticket? I’d be interested in the response.

2 Likes
#17

Hey, honestly I moved to start points and forgot about this. I’ll check if I filed a support ticket but I don’t think I did. Interesting work around, thanks for looking into this. On the E version of the os, you wouldn’t have to save sample settings or anything, you just sliced the recorder buffer and it would remain through power cycles. My project would use that as a main feature and it would always be there every time I powered up the ot. I’m now using start points because I always slice evenly anyway and they keep in time with tempo changes, so it’s actually better for me.

1 Like
#18

Checked my support log, I did not file a ticket. I’ll do it sometime soon…

2 Likes
#19

Support ticket filed, I’ll report back when I hear something…

5 Likes
#20

Confirmed as a bug by Elektron. Was recommended to downgrade to E if really needing this, first making sure to backup to a computer. No mention of if it will for sure be fixed or timeframe. I’m gonna stay on H with fingers crossed for a few more bug fix updates…

I encourage all OT users to narrow down bugs(especially with pickups) and file support tickets cause maybe if they get enough we can get some more bugs squashed before we reach legacy land…

4 Likes
#21

And where we can get this older 1.25E OS ?
Any link ?

#22

Contact support and they’ll get it to you, or try the link in this thread:

2 Likes
#23

Pre-sliced recorder buffer issue 1.25H

please fix this!
this issue is more than a year old… :frowning:

2 Likes
#24

Clearly they know about it, so it would perhaps be of no benefit to report, but it’s still probably more beneficial than posting here … perhaps support could give an indication on when an update may be forthcoming … clearly there are a few more distractions for Elektron these days and bug fix roll outs don’t seem to be as frequent as we’d all like

ps - creating threads pointing to threads isn’t recommended … it’s not a given Elektron would see it anyway, but in this case it’s clearly a known issue and I am sure it’ll be fixed in the next os

2 Likes
#25

thanks!

#26

Why don’t you downgrade to 1.25E ?

#27

is there a 1.25E? can’t find it on the support page…

#28

Just above your first post here ! :grin:

1 Like
#29

Hi. I was thinking about pre-sliced buffers. I can’t test the issue because I’m on 1.25E. Wondering if it would be really useful for me, and go for TRC without any regret.
Apparently it doesn’t work properly if you change tempo.

As @Clancy mentioned, you can assign a saved silence sample. It’s not a big deal. You use start points now ? What’s really interesting with pre-sliced buffers. Tell us more ! :content:

1 Like
#30

Is there a big advantage to using pre-sliced buffers over shortly spaced recorder trigs?

Just wondering as I’ve never used them :slight_smile:

#31

I’ll write something up about sliced recorder buffers and also start points when I have more time, unless someone beats me to it… :ghost:

2 Likes
#32

Anyway your point of view will be interesting.:wink:
I was almost ready to answer 1 hour ago, but I made other tests before. And now I’m not sure anymore. Short records or plocked start/slice points ?

Some thoughts…

It can sound the same, with trigs corresponding to rec trigs for short recs, or slices with correct linear locks (or lfo on start). Played real-time, some limits like pitch up or rate reverse seems to be in common.

But you can also use slices for short recs, play with Length and go up to 1 octave up depending on Length, and slice duration.
Many things to explore. Realtime pitch shift, lfos on pitch…Realtime granular stuff ?

For tests you can rec track 1 with track 2 (rec trigs > SRC3=T1). - 1 microtiming for rec trigs.
If you record inputs, normally no need for microtiming, maybe timestretch off.
(Settings for realtime playing)

1 Like
#33

Hmm, thanks for the info! i should just try it and see! I’ve gotten into the habit of using lots of rec trigs on flex tracks for glitchy fun with the inputs. I know you mention some uses but most of these are things that I already do with flex tracks. The OT cannot predict what will be recorded so before slice 16 can be played, it must be recorded, so doesn’t that make it the equivalent of 16 rec trigs? Although I guess you can have much smaller chunks of audio with slices, and also you get multiple chunks of audio. Rec trigs just give you one piece of audio that is constantly overwritten

I’ll have to check it out properly tomorrow :slight_smile:

1 Like
#34

Is this bug still not fixed?
I’m on the latest OS and it seems to be still there

#35

Stil on 1.25H here, so your telling me… :slight_smile:
It’s weird, it won’t even revert to start points if slic is on as if there were no slices, it leaves one zero length “ghost slice” that ruins it… Is that still there?

Anyway start points work great for even length slices for buffers and work better after changing tempo then re recording. But slices should stick, they did on 1.25E and before…