I’m seeing some weird behaviour with TRCs while using a workaround.
I want the final 4 trigs of a sequence to play 3 times out of 4 so I set the final 4 trigs like this:
( 4:4 ),( /pre ),( pre ),( pre ),( pre )
I think this should work but doesn’t (unless the negative pre on 2nd trig doesn’t count as an evaluated TRC).
Instead I have to set it like this:
( 4:4 ),( /pre ),( /pre ),( /pre ),( /pre )
Now this does give the desired result but really, is this normal? The logic seems wrong!
Well, I totally see where you’re coming from, but I think (whilst the manual is NOT at all clear on this and @eangman may chose to address this omission after checking with the developers) that we need a little clarification on this
I can see a usage scenario where it could be more natural to do it the second way listed
In formulating a long explanation for this I uncovered two more issues (one of which seems like a definite bug, but it further strengthens the need for clarification on the rules - and in this regard the manual is lacking in completeness imho)
Here’s my Bug
Clear Track, simple short sound, Two TRC trigs on first two steps
Trig 1 [1:2] Trig 2 [Pre]
So, you should only hear two notes together or none on any pass
But on the first pass you only hear the first Trig - thereafter it’s as anticipated
Same issue if you go with /PRE too (just for first pass)
Here’s my issue
Whilst playing the above pattern remove trig1
now there’s no TRC to evaluate, but the PRE on Trig2 still plays indefinitely until you stop/start
I say an issue because it’s unfair to class it as a bug - but even after the pattern(or more appropriately the)master length of the pattern has elapsed there’s no re-evaluation of the pattern to correct for the missing TRC … it’s left hanging (needs restart or another TRC)
There are a few little (be aware) issues so I think it’s really important to avoid second guessing and be briefed on the rules
Let’s look at an arbitrary test case like yours above (also, ignore use of /Fill to test the point)
Trig1 [FILL] Trig5,6,7,8 [/PRE]
Note [/PRE] in an otherwise empty pattern will play (whereas [PRE] wouldn’t)
Would it really be obvious to a user to do as you have to string a few consecutive ‘when not’ trigs together to do /PRE PRE PRE PRE or is it more intuitive to cluster them together with the same TRC type - I think this may point to the thinking behind the undisclosed rules
It may be that the PRE condition isn’t considered as an evaluated one as you suggest, but we need clarity
how about T1,T2 = /PRE, PRE … should it (by original assumption) go Y Y , N N , Y Y or … ??
I understand your point, but we need to know the rules for evaluation to know what’s a bug/quirk/issue … there’s certainly scope for a bug (or two) imho
FWIW - I started looking on the OT but switched to the A4/R to compare (same) and to make tests quicker — so these points are applicable to all devices
Thanks for checking it out!
To make things even more confusing, I tested your bug and it works fine for me. I think you’re right about clarification, we need to know the exact rules at play. At the moment it seems like the ‘pre’ and ‘/pre’ follow a slightly different logic.
I’ll put in a ticket and see if anyone can clear up the confusion.
If i remember things right (at NAMM and cant check it now) the PRE and -PRE conditions ignore evaluating any earlier PRE and -PRE on the same track. NEI and -NEI will also ignore any earlier PRE and -PRE on the neighbor track. Check the Digitakt manual for reference. Will check it out when i get back.
Not clarified in the DT manual afaict
Look fwd to any insights then
need to try that on the OT next - after the first look I jumped to the analogs
So my ‘bug’ was for A4R - any independent confirmation welcome peeps
This is a helpful insight and I can envisage there could be a good reason for it, but there’s certainly a stronger case to make it clear in all the manuals 
Aha! So thats the way it works, makes perfect sense now!
What looked like a bug is just the way it is designed. Its very confusing as the OT manual doesn’t describe this, its automatically assumed that the pre TRCs work the same way as the others.
From the Digitakt manual:
"PRE is true if the most recently evaluated trig condition on the same track was true. “(PRE and PRE conditions are ignored and not evaluated.)”
Thanks for helping clarify this! 
I read that but didn’t read it - at least it sheds some light on it
It doesn’t account for my bug/issue on the analogs whereby the PRE condition is ignored on the first pass after having evaluated an X:Y or % e.g.
I can confirm that this [1:2] [Pre] bug is only (and now clearly a bug) for the Analogs, it works as expected on my OT too
Just replicated this on my A4 too. I can also confirm that theres clearly an issue, I tried with longer gaps between the trigs and it makes no difference, the first pass of ‘pre’ trig doesn’t work.
Back at the office again. The fact that PRE and -PRE conditions are ignored by PRE and NEI conditions is described in the manuals from OT MKII and onwards. I can also confirm the bug that avantronica describes. WIll investigate a bit more and report. Thanks for bringing it to our attention.
Reviving this old topic as I’ve just run into a bug which is pretty much described in this conversation.
The bug is with modulo TRCs when using independent track scale. I’ve replicated it in an empty project so I don’t think it’s just a project that has freaked out.
If I have master as 64x1/2 and have a ‘nested’ track set at 64x1, the nested track will obviously play twice for each pass of a regular track (running at 64x1/2).
Now i want to make the nested track mute the last 2 bars on the 4th pass. I set a 4:4 trigless lock at the end of the second page, then set all the following trigs to notPRE. When played back, the pattern works fine, cycles twice (4 times for the nested track) and has a 2 bar mute at the end of the second pass.
BUT, if I switch to that pattern during playback then it plays back wrong. The 2 bar mute occurs on the 3rd pass instead of the 4th. This happens when switching to that pattern manually and also when the arranger automatically switches to that pattern. Downer! 
Not sure if I’m maybe missing some setting but I never change the trig modes, I always work with standard settings. If anyone could verify this issue, I’ll contact support as this is a serious problem for complex patterns.