Octatrack 1.40A

Damn, how great is that!!

Amazing, quick fix.

Thank you Elektron!


Nice, I love checking Elektronauts way after bedtime :smiley:


Hmm, I updated to 1.40A and since then, my crossfader is not working anymore. on 1.40 it worked. I can now switch between Sceens by selecting a different one for A, but the Fader does nothing.
Any setting that might have been reset, that I miss?

Ouch! Anywaywho is using crossfader on the OT? :smirk:

1 Like

Did you set AUDIO CC OUT to INT or INT + EXT?


The crossfader can be calibrated. It might help. Does the screen show the fader movement still?


Just to be sure, did you try loading a new project?


It is working on all other projects. Seems that I somehow turned that INT/EXT thing while testing. Thanks for the quick help!


I updated from 1.31 to 1.40A and an arrangement I was working on is playing back conditional trigs totally differently (counting of cycles seems very different). I actually can’t figure out exactly what’s going on. I know they fixed a bug regarding conditional trigs, but apparently my arrangement depended on the buggy way! Oh well.

Which is?

For information it’s also possible to mute scenes (Func + Scene A/B).

According to the 1.40 release notes bug fixes “Trig Conditions did not function correctly under some circumstances when using SCALE PER TRACK.”


I missed that one and indeed, i’m encountering some issues with that as i’m always using Scale per Track.

1 Like

In what way is it playing the conditional trigs back differently?

I’ll spend some more time on it tonight to see if I can answer more scientifically. I use a lot of the A:B type of trigs and they’re playing back at different times across a long arrangement than they did before the upgrade. I’m not completely sure what’s going on yet. Was interested to see blasted_pingin noticed something though.

Before the update, I believe using scale per track with A:B conditions meant that, if the master length resets a pattern before it is complete, the pattern cycle used for conditions is not incremented. I haven’t checked all my patterns, but if they swapped this round it will have affected a bunch of them. I can see the logic in changing the behaviour, though.

master length: 32
pattern length: 15

trig 1, trig condition 1:2

Trig plays first time round, then it will play the third time round (step 31 on master), and then it will play again two steps after that when the pattern is reset on step 33. So, because the pattern was reset before it completed it’s cycle of 15 steps, the trig condition counts everything before and after the reset as the same pattern cycle.

Pretty sure that was how it worked. I’ll investigate what my patterns are up to now.

What was cool about this is that you could get more funky with your conditions, like in this example, with regards to the trig itself the condition would actually be 1, 3, 4, 6, 7, 9, 10, etc… So like a 2:3 followed by a /pre but in one condition.


Confirmed on a fresh project, trig conditions now have their own trig specific cycle that is no longer connected to the pattern as described above. This does make more sense imo. But it will not be fun if you want to get some of those patterns back! Some might be impossible to recreate exactly if you have multiple trigs next to each other stopping you from using A:B trigless locks with /pre.

Could’ve had more attention drawn to this? It has the potential to drastically change the way pre-existing patterns sound, and that wasn’t made clear in the 1.40 release notes.

@Rusty any chance of a trig:condition converter somewhere in the future?! More trouble than it’s worth most likely, though I did previously think such a thing could be used to multiply a short condition heavy pattern whilst keeping the actual rhythm intact instead of the conditions…

Probably the easiest solution though, if you want to keep something you made, sample it first!


@Merv easy way to test your theory is to go back to 1.31, should be possible to downgrade then test, but of course back up your stuff first.

Thanks for doing this Merv. I wasn’t sure if it was something the arranger was doing differently to trig cycles or if it was the master length handling changed. Seems like the latter based on your findings.

Edit: The arranger behavior is also different (even before master length runs out). If you put a 1:2 trig on the first step of a 16 step pattern with a really long master length, it plays as expected on an arranger row without offset. But if you put any offset on the arranger row, the first time it comes around to the trig it skips it even though the trig hasn’t played once yet. While that might make some sense, it’s different from what used to happen in 1.31 (the trig would play in accordance with the number of times it was passed regardless of the offset).

1 Like

What do you mean by a Trig Condition converter?

Well, in the above example, a process that would convert the 1:2 condition in the old OS, to a trigless lock with 2:3 followed by the trig with /pre; this would be an identical pattern under the way trig conditions now operate in the new OS.

Another use case; you have a 4 step sequence with trigs 1 and 3 using conditions 1:2 and 1:3 respectively:
(6 repeats)

You convert this to an 8 step sequence, and as the trigs are duplicated it will end up like this:
(3 repeats)

To maintain the order of trigs from the original sequence, it would have to become:
trig 1 no condition
trig 3 1:3
trig 7 2:3

Extremely likely that it’s more trouble than it’s worth.