Trigger E0 Minor Bug

[ipassenger]

I noticed that when you set the gate time in a pattern on a standard track to E0 (one whole step) it seems to be intermittent as to whether or not it actually stays on for the entirety of the step or sometimes ever so slightly less than a whole step.  If you compare this behavior to say D5 (6 ticks), in standard pattern tick length etc it always stays on for the full 6 ticks. 

I only noticed this when stringing together several whole steps (E0s) versus doing the same with stringing together 6 tick gates (D5s), a rounding error somewhere maybe? Could well be tempo related, as when i set the tempo to 120bpm the E0s stay on for the full step but other tempos result in different behaviour (try 124 for example). Also whole steps I think is assuming the step is 6 ticks, rather than basing it on the step length of the sequence.

[XORadmin]

I can understand that E0 and D5 might behave slightly different even they (theoretically) shouldn't. But here is whats happening:
For E0, there is only one iteration needed and the next timestamp is calculated for when the gate should release again.
For D5, a timestamp is calculated for each tick and everytime it reaches the timestamp a counter is decreased until it is zero = release the gate.
Because of the scanning of the timestamps it might be that these times are not 100% the same. It might indeed be different with different BPM. The scanning (like sampling) rate is lose from the sequencer timing. (Just FYI, increasing the scanning time = less CPU power for all other future stuff, less smooth UI etc... And we are already talking about microseconds here)
If you want to hold a gate, then use a FE which is the only 100% trustable function that you would use for this usecase (keeping the gate on for X steps).

A step is indeed assumed to be 6 ticks (track clock divider/multiplers are included in this), but that is mainly because the triggers can be fired from everywhere at any time, even not step related. So this is the best assumption I can do.

I won't change anything here since I think it works well within the possibilities.

[ipassenger]

I can understand that E0 and D5 might behave slightly different even they (theoretically) shouldn't. But here is whats happening:
For E0, there is only one iteration needed and the next timestamp is calculated for when the gate should release again.
For D5, a timestamp is calculated for each tick and everytime it reaches the timestamp a counter is decreased until it is zero = release the gate.
Because of the scanning of the timestamps it might be that these times are not 100% the same. It might indeed be different with different BPM. The scanning (like sampling) rate is lose from the sequencer timing.  (Just FYI, increasing the scanning time = less CPU power for all other future stuff, less smooth UI etc... And we are already talking about microseconds here)
If you want to hold a gate, then use a FE which is the only 100% trustable function that you would use for this usecase (keeping the gate on for X steps).

A step is indeed assumed to be 6 ticks (track clock divider/multiplers are included in this), but that is mainly because the triggers can be fired from everywhere at any time, even not step related. So this is the best assumption I can do.

I won't change anything here since I think it works well within the possibilities.

Agreed, that all makes sense, I do use FE and FD for this kind of thing but wanted to point it out if it was fixable.  

Like you say I can see the difference, one is setting the gate end at the start, the other is analysing the state.