Followup on Very jumpy reaction to midi encoders · Issue #15 · bitfocus/companion-module-generic-midi · GitHub
@Andy where would you like me to put the support packs?
BR
Rune
Welcome!
You can attach them to this thread, or DM them to me if you like.
Thanks, much appreciated!
Unfortunately, new users cannot upload files.
Any idea how that block works? Timebased? number of posts?
You should be good now. I upgraded your account.
Ok, if I understand the issue correctly, it’s that Companion is receiving all the messages as fast as you’re sending them from your controller, but the trigger isn’t responding quickly enough to react to every message.
Is that correct?
If so, then that’s an unfortunate limitation of the trigger and variable handling within Companion. Basically, I’ve been told that companion can only update variables and check them about once a second. Their reasoning for this (which is totally valid) is that with the possibility of many triggers and hundreds of variables, Companion could grind to a halt because it’s spending all its resources checking variables.
What’s really needed, and several people have suggested/asked is to include MIDI as a protocol to control Companion, the same way that HTTP. TCP and OSC can currently. Until then, MIDI control will be only useful for slower actions.
Well, there’s definitely something weird going on.
In this test, I’ve kept the midi commands several seconds apart.
Although 7 commands were sent, the counter increased to 14. On at least one message I could visibly see the variable increase by one and then by one more.
(forgot to clear log before restarting the module/connection, ignore the top)
.
Is that the 3.5.3 or 4.0 config?
In the 3.5 config, your trigger is looking for CC 1_16_0 to increment the variable. I’m not sure what the OR will do with a disabled comparison, so you should get rid of it.
I see the issue however, if you follow the logic carefully.
You have the trigger event being “on variable change”. The “is Message incoming” will change twice. It will change to true when the message comes in, and then false when there is no longer a message coming in. It’s not “when this variable is true”, but “when this variable changes”.
So… Simply add another condition (when the variable is true) and you should be good.
I BELIEVE that one of my videos has this done incorrectly (the way you show it), so I should correct that!
Try this trigger:
D’oh! Of course it triggers on transition, not value. Thanks!
I have the inc/dec working correctly now (the 1_16_0 bug sneaked in when I tried moving to the lastvalue chech from a “Kontrol_X1: CC” check type to see if that would fix anything).
It’s still missing trigger activation when they come fast (more than once/sec) though.
Given the trigger shortcomings, what would be the best way to design midi handling:
- one trigger pr. message type/button with a vey specific condition and a short Action section?
- one trigger for any midi incoming, and a shedload of if-then-else actions for different messages?
- trigger on change to lastmessage for all buttens that cannot cause repeated actions (sends e.g. noteon/noteoff) rather than midireceived?
- look into midi-osc bridges and use companion’s builtin osc support for fast message handling?
If you need very fast MIDI message recognition, you will need to use a translation layer like MIDI-OSC as you say.
While working with MIDI messages directly, anything with absolute values (like faders) should be set up to be a feedback with “Auto-Create” variable for the control’s value. Then you can use a trigger to watch for that variable to change and act accordingly.
How you handle it would depend on what you want the triggers to do.