Thanks for the heads up @garf !
I had to use the Stretch Machine to have it synced. I’ll do further experiments.
Thanks for the heads up @garf !
I had to use the Stretch Machine to have it synced. I’ll do further experiments.
I have a question regarding anyone who’s experienced the missing samples issue. I’m on 1.10A still and have several patterns save incomplete recently. The whole kit is there and the sample slots are selected on the given tracks but the samples are not loaded to the slots with the project. Is there a way to repair this after updating? It’s been a few weeks and I can’t recall what specific samples were in those slots to recreate the patterns whole. What’s weird is that all the machine and synthesis settings are correct. Filter assignment etc. just no sample loaded to the slot.
Would be a pitty to loose this set but, alas.
Should note it’s only some of the samples as well.
Is it patterns that save incorrectly ? Or kits that are saved from patterns ? The latter was solved on 1.10A.
Are you sure you’re on 1.10A ?
This is an issue with Patterns. not kits. and Def on 1.10A I updated right when that one dropped.
Might be a new issue
Getting crashes:
I upgraded to 1.15 and had no problems during the integrity check of the samples. The slice machine worked wonderfully without problems.
But I then realized that many of my presets (which I had luckily backed up) had been wiped, so I tried to send them over via Transfer back into their respective banks. This made me get the crash screen filled with weird characters. Powered it off, tried again with Transfer and the presets, and got the same crash.
Have you experienced the same? Do you think I need to do a whole reformatting?
In a track using the slice machine, I have p locked slices and change the tune of some of them, now the p lock indicates « error » in the slice menue and there is no sound. Happened twice while using slice machine
To really get to grips with the modulation I’ve been playing around today with sending MOD to all the destinations.
A test was having a note playing, a SCW with the Loop Playmode the sample and hold random LFO and scrolling through the parameters. (def think using a small amount of this on panning with the sample at point of note on is going to be fun!)
When getting to Play mode the sample stopped, so I looked at it. Play mode has: play forward and stop, play backward and stop, loop forward, and loop backward,
ok, I must be jumping from the loop mode I was in to one of the “Play Forward Stop” or “Play Backward Stop” and the waveform stops playing. Mystery solved.
But then on a longer sample I tried to set the depth really low to get it cycling between loop forward, and loop backward. No matter how small the value I just can’t get this working.
Is there a trick or something I’m missing to get LFO to cycle between the Forward Loop and Reverse Loop play modes?
Can anyone else confirm if there a bug when using MOD to modulate SRC play mode?
It’s definitely tricky to get it cycling back and forth without hitting one of the points that stops playback. I got it sort of working by using not the LFO but trigless trigs to reverse the playback direction.
Have a search for ping-pong looping here. It’s a requested feature and there are some workarounds.
EDIT: take a look here
I’m not making a feature request. Play Mode as a MOD destination not working correctly for me.
Either I’m making a boneheaded mistake, overlooking a toggle or similar, or this is a bug that needs to be looked into and fixed.
If someone from Elektron could indicate the intended usage of MOD to Play Mode I’m sure that would clear things up.
If I remember corrently it used to work on DT1 (square LFO hopping between fwd.l/rev.l) but stopped working quite a while back, don’t think it’s ever worked on DT2.
[edit]
Right … hence my comments about workaround and feature requests above.
The 1.15 manual released not even a week ago lists it under
APPENDIX C: MODULATION DESTINATIONS
…
SRC: Play Mode
It’s not an unintended debug destination that happened to be included by mistake. It should not require work arounds or be a feature request. If it’s not working properly it’s a bug, it may be a long standing bug, but it’s still a bug.
Edit: Again, I don’t know the intended usage, it could be working as expected but without a reply detailing how Elektron expects people to use it, on it’s surface it appears to be a bug,
Yeah, this is a bug/regression on previous behaviour. I reported it to Elektron in July ‘23, this was their response back then:
Thanks for reporting!
There’s definitely something strange going on there. Do you experience this with any Machine type, or only with the ONESHOT Machine?
Just in case you didn’t respond I’ve done a little write up with an example file.
Expected behavior from the MOD → Playmode would be to cycle between Rev.L and Fwd.L
As sample length needs to be quite high I’ve also included a link to a project (1.15 firmware) to save people finding/resampling their own.
6 patterns A1 to A6 Using the Oneshot, Werp, Stretch, Repitch, Slice and Grid machines respectively.
Settings are as follows, a long sample selected (the one included in the project is about 12 seconds)
Test setup:
Each pattern is 128 beats
Tempo = 80 BPM
With a single trig placed on the first step of track 1. playing note C5
SRC - Playmode = Rev.L
SRC - Samp = ‘a long sample’
AMP - Attack Time = 0
AMP - Hold Time = Note
AMP - Decay Time = Inf
MOD - Speed = 16.08
MOD - Mult = BPM2
MOD - Destination = SRC Play Mode
MOD - Waveform = Sqr
MOD - Start Phase = 0
MOD - Trig Mode = Trig
MOD - Depth = 1.0 (lower than this nothing happens)
Non default Per Machine SRC:
Stretch SRC Bars = 4
Grid SRC Slice = 4
Grid SRC Length = 4
Every machine with the above settings, plays through the source file forward then after 32 steps reverses the playhead direction, returns to the start and stops playing. Note *on the machines where* you can by moving the start point forward, begin playing a note and move it backwards to achieve the back and forth behavior going on infinitely, That is still going between Forward and Reverse, not the looping variants. (move the ‘start’ position into the play head and it stops)
Can someone from Elektron indicate if this is how the unit should function, or if this is a bug.
So from
plays through the source file forward then after 32 steps reverses the playhead direction, returns to the start and stops
it sounds like your setup is alternating between Fwd.L or Fwd on the high part of the square wave and Rev on the low part.
What difference does it make increasing the depth ?
EDIT: Hmmm no difference that I can tell.
When a sample PLAY MODE is set to FWD it will stop playing when it reaches the end. Similarly, if it set to REV and reaches the start it will also stop playing.
So what happens in the example is that the sample plays forward (FWD), then switches to reverse (REV), but the moment that it is supposed to switch to FWD again, the sample has already reached the start point and is thereby stopped. So this is normal.
What you could do, for example, is to “drag” the speed of MOD1 back a tiny bit on the start - thereby having a longer first forward time than the others, meaning that it will never reach the start point again. In the project, set MOD2 to the following for instance:
DEST: MOD1 SPD
WAVE: EXPO
MODE: ONESHOT
DEPTH: -0.01
SPD: 48
MULT: 2
FADE: 0
SPH: 0
…then it will cycle forwards and backwards
And if this depth was reduced internally, enabling DEP to be set to -3 to +3 to skip a number of playmodes in the list, other combinations become possible.
Yes it does, I needed to adjust the depth on LFO2 but that does it.
But that was not the setup. I specifically detailed starting on SRC - Playmode = Rev.L < the looping version.
Yes, I detailed that in my question as what happens now:
However, The expected behaviour is:
To make my question absolutely clear.
Is it possible/What are the setting to:
Cycle between Reverse Loop and Forward Loop
Yup, but also this:
So I was therefore using pattern A1 to try it out (which had a depth of about 4 thereby actually wanting FWD/REV non-looping), and that’s where my suggested fix came in. Checking the project I see that the 6 patterns mentioned (with Depth 1.0) actually resides on H01 to H06.
But either way, we are looking into the mentioned issue regarding RevL FwdL !