Translator output as a trigger for another translator

How to do it? I intend to transform an expression pedal into virtual four buttons, dividing its 0-127 range into four different regions like 0-15, 16-63, 64-111, 112-127. This translator stores 0 to 3 values to a global variable according to the current expression pedal position (value). Until then everything is ok. The problem is that my project has dozens of other translators that not only depends on that variable value but should be triggered by its value changing. I do not know how to do this. The only way I managed to work was to put the expression pedal to trigger all the translators and the secondary translators use the global variable changed by the first translator. But this costs a lot of CPU and MIDI bandwidth, as every single "+1/-1" step of pedal movement would trigger all translators, their rules and MIDI output data. So, back to the topic question. How to make a translator output (I could turn the global variable into a triggering MIDI message) work as a trigger to other translators? Is it possible?

Note: I thought in two workarounds but none of them would be satisfactory. One possibility is: the first translator outputs a keystroke which would be the input trigger of the remaining translators. But this might be not laggy free nor safe to do it, as the computer is used for other purposes (with eventual keyboard usage) while running as a MIDI box. Another workaround I thought is to repeat the first translator rules (that one that transforms the pedal subranges into 4 discrete values) into every other translators and exit their rules and outputs when there's no variable changing (subrange changing). This would save the MIDI traffic but not all the CPU usage.

Hmm looks like you are doing close to what I would do. Currently BMT does not allow output of one translator to trigger input of another translator. Indeed with multiple expression pedals outputting concurrently, you will see lots of midi traffic. One thought is to put a delay on triggering  the output timer to cut down on midi traffic. The translators would then only trigger after the induced delay (when you stop moving the expression pedal). This delay might have side affects however.

 

First of all, thanks a lot for your prompt reply. That (of BMT not being currenlty able to link translator\’s output to the triggering input of another one) is what I would not want to read. If it\’s really so, it could be a good feature for a next release… As for your suggestion, are the translators\’ rules delayed until the right moment of delay expiration? Or those delayed outgoing messages are generated as soon as trigger message comes and backlogged? Depends on how this works, the MIDI traffic would not be alliviated as the secondary translators\’ output are much more numerous than the expression pedal input. As I write this comment, another possible solution came to my mind. Would it be feasible to create a secondary Virtual MIDI port, processing the pedal data into its domain and link its simplified output to the input of the main virtual MIDI port?

From what I experience, the new input value re-starts the timer so the timer doesn’t trigger until incoming activity stops.
I also thought of your idea of creating a new virtual midi port and routing output of BMT through that port to another virtual input port.
I have not played with that idea but unless virtual ports have limitations around this, it seems doable to me. Just beware of infinite loops.

I would recommend to use a different project to experiment with the idea before incorporating into your current project.

Nice. I’ll give it a try. Another possibility came now. Maybe, for the first translator (that one that translates 0-127 pedal data into 4 discrete output values), I could store not only the current value but also de previous one. For the secondary translators, they could be headed by the condition of previous and current variable values not being the same, otherwise the translator would exit without outgoing message (and without processing all those complex rules). This would avoid both the CPU hog of all those complex and numerous rules and the massive MIDI traffic generated by them. And thanks for the tip of safe work on this project. Not only I do save backup projects but also Google Drive stores different versions of them. Also, I use to duplicate presets for backup purpose.

Might work. Note I tried routing Bome Virtual Midi out to Bome Virtal midi in and it didn’t seem to work, but it worked with Midi Yoke virtual ports. However Midi Yoke installation was a bit buggy for windows 10 machine. I suppose it would work for CopperLAN virtual ports as well which would probably be easier to install.

Looks like CopperLAN virtual ports don’t work either. Maybe like bome, they have protection against midi loops.

Actually it works with CopperLAN – I just had to add a virtual loop back cable to the config with CopperLAN manager. 1: MIDI OUT [VMidi 1]: 90 3C 7F 2: OUT 0.0 Note On on ch. 1 with note:60 (0x3C) and velocity:127 (0x7F) 3: MIDI IN [VMidi 1]: 90 3C 7F 4: MIDI OUT [VMidi 2]: 90 3D 7F 5: OUT 0.1 Note On on ch. 1 with note:61 (0x3D) and velocity:127 (0x7F)