Cool. Unfortunately that code means nothing to me cuz I don’t fuck with grid ops OR the 301, BUT I’d say 1) try to avoid relying on the faderbank as a source of continuous values. It’s less processor-intensive to poll it infrequently and set up a slew than it is to have it check it every 25 ms (this will begin to blossom issues when you are running more ambitious scenes with more going on, so try not to patch in a way that relies on these hyper-speed metro times). The I2C ecosystem really isn’t optimized for this kind of continuous control, and it’s probably better to just use the actual CV outs of the faderbank for that sort of scenario.
With that in mind, I’d recommend setting FB values as they become relevant, so the script that calls an action from the ER-301 also includes an update for the FB value. If the ER-301 event is currently triggered by a trigger into the ER-301, then just put it into a teletype scene and run something like:
tr.p 4
[send 301 that fb data]
and plug that trigger into the 301 (which just sidesteps needing a mult).
If you’re looking for true continuous control of the 301 I think you want something like:
8
DEL 25: $ 8
[send fb data to 301]
but this second thing will almost certainly create a buggy mess for you eventually if it becomes a habit.
Again: No 301 or GRIDOPS experience, but LOTS of time asking my faderbank nicely to send continuous values over I2C (and lots of completely system-breaking bug experiences!).
