Euclidean rhythms problem when set via I2C and Mapping

[SynthBu]

I setup a Michigan Synth Works F8R faderbank to talk with my Nerdseq using I2C. I even made a video about it. But today I realized there is a problem when use a fader to set a Euclidean rhythm. 

The problem is that the Euclidean beats are not set unless the associated fader is moved while in the Pattern window. This also means that the Euclidean beat values at bootup are not set correctly since at bootup one is not in the Pattern window. 

I was careful to try different scenarios and am confident about the nature of the problem (at first I thought it was just a bootup problem).

Using the F8R via I2C and mappings to control BPM works just fine. And I know that the Nerdseq is getting the proper settings of the faders via I2C since in the Mapping Settings window I can see that all of the values are correct both at bootup and when I move any of the faders (a great feature of the Mapping Settings window!). Therefore I don't think this is an IC2 issue.

The problem is only that Euclidean beats are not updated at bootup or when moving a slider, unless one happens to be in the Pattern window for the appropriate track. It is not just the visual representation of the Euclidean beats in the Pattern window. When I play the pattern it corresponds to the incorrect beats that are displayed.

There might be additional track related params that exhibit the same problem. I don't know since I have not tried setting other track params via a mapping. 

Video showing the problem: https://youtu.be/jRWph2hVVWQ

[XORadmin]

Oh thanks I got to test that.
It does work here…but: I always use an I2C/Multi track (also for trigger16 outputs) and there it works fine also outside of a pattern.
Might be the trigger16 track in your case which I‘m gonna try.

Generally the rules are that it should work from every screen. Another rule is that it affects the current or last playing pattern or the selected pattern if you are in the pattern screen. One quirk is there which is being updated with the next firmware (and I think already discussed here) and that is if you are in a pattern then the faders for another pattern are indeed not working. But that is not your issue currently.

Another thing is when you load your project then it loads the last ‚beats‘ from the pattern and these change only with the first change of the faders.
I do rely here on what the faderbank is sending out. There is no way that I can request an update of all faders.
There is also a 10 second delay with the 16n faderbanks where they start to detect any I2C followers and from then it works which might be your delayed bpm change that you mention.

[SynthBu]

Your response helped me better understand the problem. The problem is indeed just for a pattern for a Trigger16 track. When I tried using I2C/Multi track the Euclidean beats are correctly set. But having to use a I2C/Multi track complicated things because it was really obscure figuring out how to send the drum outputs to the Trigger16 outputs.

I think the problem I ran into might have to do with the rule that for a Trigger16 track that the mapping might just affect the “last playing pattern”, as you mentioned. For example, at boot up the F8R values are definitely successfully read in after about 8 seconds. I can see this via the Mapping Settings window. But at boot up I expect there is no last playing pattern. Therefore that rule could prevent the Euclidean beats from getting set at startup for a Trigger16 track.

But when I play the Trigger16 track so that it is the last track played, the Euclidean beats are still not set correctly (when not in the Pattern window for that track). I don’t know if the new firmware addresses this issue but I am certainly willing to try it out when a test version is available.

[beep.et.cetera]

I'm experiencing not being able to change the euclidian beats while I'm in a CV16 pattern, but this seems to be the issue Thomas is referring to (I guess?). I'm using a Faderfox MX12 to send CC to control the amount of beats.

[XORadmin]

I'm experiencing not being able to change the euclidian beats while I'm in a CV16 pattern, but this seems to be the issue Thomas is referring to (I guess?). I'm using a Faderfox MX12 to send CC to control the amount of beats.

Yes described before and is not related to the input type.