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.”
2 Likes
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.
Example:
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.
2 Likes
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!
2 Likes
@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:
XoXoooooXoooooXoXooooooo
(6 repeats)
You convert this to an 8 step sequence, and as the trigs are duplicated it will end up like this:
XoXoooooXoXooooooooooooo
(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.
I’m going to say that with the new Sequencer module and all its embedded functionality, that it wouldn’t take long at all to do it “manually” as it were.
Actually developing separate functions to do conversions? More hassle then it is worth.
2 Likes
I’m having a bug, but don’t know if it is something with 1.40 that may have been addressed. I try and set the crossfader for the rate to be -64 on the A and +64 on the B but it sets the same value for both A and B and not just the one, so I end up with both A and B being the same of which ever value I recently set?
Are you really sure A and B are set to different scenes? What OS version are you on?
4 Likes
I haven’t ever done anything with scenes, and from what I’m guessing with the fader icon at the bottom right side of the screen, yep, it looks like they are both set to 09. So I guess I just have to set them to be on different scenes then. Thank you for your helpful reply tnussb.
2 Likes
Yes. With both A and B set to the same scene it’s no wonder they get set in sync, isn’t it? 
Just hold one of the buttons (A or B) and press one of the trigs (1-16) to select a different scene.
2 Likes
That was quick! I just got done going through the manual and doing just that. Thanks again! 
1 Like
By the way I am so happy about this update! It seems to have fixed what I (+ @Elektron) thought to be a hardware issue with the LED of one button (wrong colors …like there was a shortage in one). All good now!!
1 Like