Help! Conditional Sample (or sample lock) time stretch settings?

Hey!
I am using the OT to play backing tracks, and therefore need to find a way to have a conditional sample/sample-lock not time stretch. If a track has time stretch turned off in the SRC menu, and I place a normal trig down, the sample remains non-time-stretched :white_check_mark:. However, if I add a conditional sample/sample-lock to that trig, it is time stretched and not conforming to the SRC menu setting :x:. Is there any way around this to keep conditional sample trigs non-time stretched? Thanks!
(for those wondering, these conditional samples are long stems used as backing tracks, and therefore time stretching needs to be turned off)

Select the sample slot on a track with that particular sample, go into the audio editor, FX1 page. Turn off time stretch :+1: that way it’s turned on for the sample by default. That should solve it I think. Cheers

1 Like

Thanks for the suggestion! I have just given that a go (navigated to the AED page for that sample, and confirmed time stretch was turned off for the sample), however it does still seem to be time stretching when set as a “sample locked” trig. I had also hoped this setting would have been applied to sample locks.

It seems the case. I made a test with a sample as track default and also used the same sample as sample lock. Same behavior.

SRC setup TSTR settings have priority over sample slot AED > ATTRIBUTES TIMESTRETCH, unless you choose AUTO. With TSTR = AUTO, sample slots ATTRIBUTES TIMESTRETCH are applied.

(So with AUTO, you can use a timestretched sample as track default, and a non timestretched sample lock, if their ATTRIBUTES are set accordingly.)

Trig conditions and sample locks are 2 different things. Did you use both ? I tested condition 1:2 on a sample lock, same behavior.

Please give minimum necessary steps in order to reproduce you issue…

2 Likes

I have tested it out further with about 8 different samples/stems all over 3 minutes in length, and I’ve been able to reproduce this issue with 3 out of the 8 on different patterns. TSTR settings work correctly if the sample is loaded into the track and set as a normal trigger (even with condition of “1st”), but if the trigger is a “sample locked” trigger, it has shown to time stretch out of sync.

  • All samples have “time stretch” turned off in the AED settings
  • All tracks have TSTR turned off in the SRC setup menu
  • All samples BPM is manually set in the AED settings
  • All samples have the BPM labeled in the sample name
  • All “sample locked” triggers are set with a condition of “1st”

Did you change active track default sample slot ATTRIBUTES, or sample slot ATTRIBUTES for each sample lock ? (You have to edit them with func+bank above target slot in the sample slot list)

Anyway SRC SETUP / TSTR = OFF should override ATRIBUTES settings.

I didn’t try with 1ST.

Could you elaborate on this ?

Do original stems have the same tempo as the pattern tempo ?
(In that case they should play normally even with TSTR ON)

What if you set tempo to 30 or 300 ? Can you here a difference on problematic samples with SRC TSTR OFF ?

I tried with sample locks with 1ST, SRC TSTR OFF, they aren’t timestretched (very long static sample).

I changed every sample in this set (this audio pool) to be a specific BPM in the AED Attribute settings. All samples have “Timestretch” turned off, and set BPM. All tracks in every pattern for this set have TSTR-OFF set in the SRC settings.

Yes, the pattern tempo (109 for example) matches the “sample locked” sample of 109, but the sample plays slightly faster or slightly slower than 109.

I will try this when I get back to my studio. My guess is that it’d probably not change the “sample locked” trig.
Just to rule it out, I am on the latest firmware as well.

That’s were I have some doubts.
There is no need to set BPM if TSTR is OFF : the sample will be played at original BPM anyway.

Which would mean original tempo was wrong when you exported your stems, or wrong sample rate (has to be 44.1khz).

1 Like

I thought I’d try to replicate the issue with a test that would make it obvious if something was wrong

I set the same sample playing on two tracks

The sample itself is just recorded and saved. No adjustments to (stated) bpm or file name

One track has it trigged on step 1 as unconditional track-default sample. The track has timestretch turned off in Playback settings. Balance is fully left on Amp page

The other track also has timestretch turned off in playback settings, but the trig is a sample lock (to the same sample as the other track) and condition is set to 1st. Balance is full
right on Amp page

I pressed play, then removed the trig from the track with no condition or lock (so that it wouldn’t retrigger)

Any difference between the two would be obvious but they’ve played in sync, with a centred mono-sounding output for several minutes now

1 Like

Oh and wildly moving the project tempo while they’re playing has no effect

1 Like
  • Origional tempo verified to be correct, all samples verified to be 44.1khz and works correctly unless set as “sample locked” trig (condition of 1st).
  • Verified that this issue does not exist for many of my tests, but does exist for some of them.
  • For context: These samples have multiple spots of no audio before coming in/out

Thank you for giving this a test! It’s definitely very odd that this seems to be an issue with some samples, but not others. One sample is very rhythmic and has very apparent timing issues if played as a “sample locked” trig, but another is rhythmic, but has no timing issues if set as a “sample locked” trig.
I will see if there’s a way to log this bug with Elektron to see if it can be looked at for the next firmware update (if they do one).

1 Like

@Inkwell.box thanks for these precisions, but the timing issue is still not clear to me. Not sure if it is a timestretch problem.
Would it be possible to hear it ?
A/B comparison of a sample played normally, and then played with sample lock timing issue.

Maybe a card reading problem : please try with a FLEX to check if the timing issue is the same.

1 Like