Having one translator send a MIDI message to another

Kulu Orr

2015-08-04 00:45:20

Hi
For some reason I can't seem to have a translator intercept a MIDI message created by another translator.
I checked both through the log window as well as with an external program, and the anticipated message is indeed sent out by MT on all ports (e.g. "Bome's MIDI Translator 1 Virtual Port" and "Bome Virtual Port 1" etc.).
However the translator down the line awaiting this message ("listening" for it on all ports) never seems to get it.
I tried delaying the generation of the message (by the translator generating it) but nothing seems to help.
Any ideas please?
Thanks!
Kulu

DvlsAdvct

2015-08-04 02:30:41

Hi Kulu

What, exactly, are you trying to accomplish? I might be able to better help if I understand what the end result is.

Thanks
Jared

Kulu Orr

2015-08-04 13:48:35

I have several cases, so I'll give one example:
Suppose I have an incoming MIDI signal that when it arrives I need to send out a different keystroke combination depending on the value of some global variable (le's call it "gi"), and there are say 50 different options, and after I send out the appropriate keystroke I also need to send out a MIDI message to a different program and perform another task.
Today I do this using one-shot zero-delay timers: I have 50 different translators all waiting for that MIDI signal, and in each one there is a condition for that "gi" global variable. If the condition is False, then I exit without executing the timer, if it's True, I execute the timer. Down the line there are a few more translators triggered by each of the timers, executing the appropriate keystrokes and MIDI messaging.
What I wanted instead (and maybe it's not as efficient, I don't know, but I wanted to try) was to have just one very simple translator for processing that incoming MIDI message, which simply sends out a new MIDI message on a dedicated channel and note combination, with the velocity equal the value of that "gi" global variable. Each of the execution translators down the line will then be triggered by only by the relevant channel-note-velocity combination appropriate for it.
No condition checking, with 49 translators less, and with each of the translators being an efficient "stop processing with this translator" flag ON.
All sounded great on paper (at least to me) with the small problem that the MIDI message was indeed sent by the first translator, however it never triggered the translators down the line waiting for it.
I hope I managed to clarify and not to confuse?
Thanks,
Kulu

DvlsAdvct

2015-08-04 16:40:41

Hi Kulu

Unfortunately, you can't loop MT Virtual Ports back to MT Pro. Only one end can be connected to MT Pro at a time, but this is something we are working on for a future update.

for MIDI messages, you could wrap everything into one translator using rules, and use that same incoming message to trigger keystrokes separately. What you'd do is something like:

Code: Select all

Translator 1: Knob Position
Incoming Message: B0 30 pp
Rules: if pp==1 then Goto "1"
if pp==2 then Goto "2"
if pp==3 then Goto "3" [i]continue this on for however many signals you need[/i]
Label "1'
pp=0x90
qq=0x30
rr=0x7F
Exit rules, execute outgoing action
[i]Continue on for however many signals you need[/i]
Outgoing Message: pp qq rr
Does that make sense?

Kulu Orr

2015-08-04 18:26:48

Hi
Thanks for the reply. I am very familiar with the rules logic however I'm afraid I didn't quite follow the keystroke output syntax. I understand how to output different MIDI messages with local parameters, but how do I make the translator execute the chain of keystrokes "Return, Left Arrow, Down Arrow, P, X, Q" then output MIDI message 90 01 02 for one value of my global parameter and "Return, Left Arrow, Down Arrow, D, X, P" then output MIDI message 90 01 04 for another value of the parameter?
(And so on ad so forth for 50 different values of the global parameter)
Right now I am implementing it as I said before, using 50 translators all working the same incoming message (which is always identical - it's the global parameter that's changing), checking the global parameter's value and initiating one of the 50 the respective zero-delay one-shot timer appropriate for the current specific value of the parameter. These timers are then processed by translators down the line triggered by them (every 3 translators triggered by one timer) carrying out the tasks of executing the appropriate keystrokes and MIDI message outputs. It works just fine, just quite cumbersome ad I thought it might be streamlined.
I'm afraid didn't yet understand how to...
Thanks,
Kulu

DvlsAdvct

2015-08-04 19:43:55

If everything is linked to a single variable, you can tie it all to one timer.

So incoming message, which is always the same, dictates the value of the global variable. This triggers the timer. The timer goes off, and you have your 50 scenarios, in groups of three, that trigger on that initial timer only what the global variable matches. You'd cut out the 50 individual timers, so instead of 201 translators you have 151. It's harder to manage in the log window, but it should work exactly the same.

Or you can remove the timer message and have 150 translators that trigger on the same incoming message, but only respond when the values match up (something like

if pp!=47 then exit rules, skip outgoing action)

Does that make sense?
J

Kulu Orr

2015-08-05 14:18:06

Hi J
Your second suggestion (having 150 translators all responding to the incoming message) was in fact the original setup. Indeed it is 49 translators less than what I have now, but much less efficient (if I understand the flow correctly) because each and every one of the 150 had to be entered and checked, whereas now only the 50 translators respond to the incoming message, and after that onky the 3 that are triggered by the timer. That's why I changed it around.
As for your first suggestion - sorry I didn't understand at all. What do you mean by "the incoming message, which is always the same, dictates the value of the global variable"? The incoming message is always the same and the global is different every time (it is changed internally by processes inside the translators according to various events), how can that work with 1 timer? How will the one timer know to trigger these 3 translators and not the others?
K

SPndstorm

2015-08-27 19:28:32

Hi guys, I have an important question about the capability of my FC-300 to send out midi notes,
Ive read the previous topic about this matter and what I understood is that the FC-300 sends midi note on/off message by using the CTL 1 & 2 in Patch Mode,right?
But, my purpose and question here is another: I want to send more than 2 midi notes,to have my FC-300 behaves like a short midi keyboard,
how can I do it?

Let me know,

thanks

Kulu Orr

2015-08-27 20:30:59

Hi
Well, I'm no forum moderator or anything, so I guess I might not be qualified to answer your question, but since you did post it here on a thread I initiated... I'll take a shot and hope it doesn't miss the mark.
I don't have any experience with the FC-300 but it appears to be pretty similar to the Behringer FCB1010 and others I've used, so if I'm not mistaken what you are trying for appears to be (IMHO) the "bread and butter" of BMT - just assign each pedal a unique MIDI out using the FC-300's interface, then intercept these MIDI out messages (probably cc ones) from the FC-300 using BMT and translate them into the MIDI message you want (probably key-down ones if I understand you correctly).
If you want short notes you can transmit a key-up message automatically after a set delay, or you can have each key-down trigger a key-up for the previous note (currently still playing).
Helps at all?
Kulu