Bug in the Rotating Rhythm Generator's Euclidean mode?

[Matt_Quinn]

I think there is some kind of bug in the Rotating Rhythm Generator's Euclidean mode where the number of fills listed on the display of a macro knob controlling the fill parameter does not always match what the device is generating. Easiest way to hear it is to use a single channel on the RRG, group it to an instrument rack, then map the Fills to Macro 1. Set the Steps to 16, send the signal to a drum, and move the Fills macro up one increment at a time with the computer keyboard keys. The Fills display will read 1 but no Fills will be happening. Press up again & you'll get 1 fill. Press it again, and you'll still have 1 fill, but the display changes to 2. So it seems like there is a ~50% chance that the displayed Fills if off by 1 at any given time. Can anyone confirm this behavior?

[[jur]]

I might be wrong, but that sounds like a typical issue with knobs resolution when macro-mapped, not anything specific to RRG.

[Matt_Quinn]

What is the 'typical issue'? I have not noticed this in any other context, but in this case, exact values on the dials are more important than in many other situations IMO. I wouldn't think it would be a resolution issue, there's plenty of resolution to account for 16 values in a macro knob. If the underlying control has 16 discrete values, seems like the macro knob should reflect those (which it does, but they are wrong!).

[[jur]]

I wouldn't think it would be a resolution issue

Well, it kind of is. Maybe you didn't notice it until now because you're usually controlling continuous parameters where you don't notice the lack of precision with e.g a filter freq at 205 vs 207 Hz. Once you're controlling any kind of stepped parameter, you're more likely to experience the phenomenon.
If you try a drum rack like the Selector Kit clean/warm that's part of the Core Library, where each drum pad is racked and the 1st macro knob is used to navigate samples in Sampler, you'll easily face the issue you're describing.

[madlab]

I already noticed this which I thought was due to rounding of values, seems to confirm this idea. And now I understand a problem I had when designing a m4l device used to drive a x0x style sequencer. Are Ableton devs looking for a solution to solve those cases ?

[[jur]]

I thought was due to rounding of values,

That might be a more accurate way to name what I tried to described (my english isn't always fantastic).

As for an improvement... let's make sure Support doesn't forget that it's bothering users