Display sysex text

Hi,
I'm working on something similar.
I have a Mackie D8b I'm sending HUI sysex. For the 8 character time display.
For now, the task is to offset the positions of the read-out to match the D8b.
ie. without translation, the beats are where the bars should be, divisions where the beats should be.

In Presonus Studio One I've been able to get flawless translation.
Because Studio One sends 16 byte messages for every tick change in the counter.
So one translation with a few variables does the trick:

Incoming: F0 00 00 66 55 00 11 oo pp qq rr ss tt uu vv F7
Outgoing: F0 00 00 66 55 00 11 oo pp ss tt uu vv 00 00 F7

Now the numbers are in the right place on the display (giving up divisions, only bar-beat-tick, as Mackie designed).

In Nuendo however, it's a little trickier.
The format is the same:

Incoming: F0 00 00 66 55 00 11 oo pp qq rr ss tt uu vv F7

Except Nuendo will only send as many bytes as need changing:

Incoming: F0 00 00 66 55 00 11 oo pp qq rr ss tt uu vv F7
Incoming: F0 00 00 66 55 00 11 oo pp qq rr ss tt uu F7
Incoming: F0 00 00 66 55 00 11 oo pp qq rr ss F7
Incoming: F0 00 00 66 55 00 11 oo pp qq F7

ie. after you hit bar "20", the next bar "21", will only send the "1". The "2" is implied.

I have the 4 translators setup in one preset. One for the 16 byte, 15 byte, 13 byte and 11 byte changes.
And it works when I step through the song.

Problem: In normal speed (ie. playing the song) some of the translators don't fire.

Checking the log, there is evidence of many 15 byte messages, for instance, but it missed the 16 byte trigger. And the pattern is totally random.
Which translator it catches and which one it doesn't.

Troubleshooting:
1. tried MIDI Yoke port
2. tried Bome Virtual port

I'm frustrated because the physical MIDI port to the D8b is handling the throughput.
The display works without translation. (in the wrong places of course)

My theory is BMTP is not capable of finishing one translator fast enough to listen for the next.
Not when variable length sysex is the trigger.

Feedback?
Thanks,
Bobby

Hi Bobby

Can you attach your project so I can take a look through it? MT Should be able to process multiple sysex strings simultaneously.

Can you help me troubleshoot with you? Deactivate all of the translators other than the 16 byte one. When you watch the log window run does it pick up every 16 byte message that should be sent? Then activate the 15 byte message as well, etc. You should definitely be using the Bome Virtual Ports, while MIDI Yoke is fine they definitely are no longer optimized the way MT Pro ports are.

We'll get this figured out.
Thanks
Jared

Great, tomorrow I will grab the project and get it to you.

Tonight I will isolate the 16 byte messages. Those should be easy to confirm because they only come with bar changes in the display.

Thanks for getting me aboard here!

Bobby

No problem, looking forward to figuring this out. Just as a heads up I'm going to be traveling until Sunday and won't have access to MT, so I will get to it once I get home.

Good morning.

I have a version of the preset which is stripped down to only the 5 translators. (for each byte length)
I disabled all but the 16 byte translator.

In the log window I have seen proof of missed 16 byte translator firing. All on it's own.

The "capture MIDI" function shows every one of these 16 byte messages being sent.

So I have a file to send to you whenever you are ready. I just don't know how to send it...

Bobby

There has to be a reason it is missing the 16 byte signals. I'm out on the road for a few days, but let me put some thought into this and see what I can come up with.

Here's the file...

Just as a heads up, since this thread is taking on a life of its own, I split it into its own topic. Figured it would be easier to manage.

Just to be clear as possible, in the log window you are seeing the 16 byte translators come in to MT but nothing they are not being processed? Or are you seeing in the Log Window that individual 16 byte messages are being missed?

Jared

No, in the log window I'm seeing no reaction at all, intermittently, to the 16 byte messages.

Every time the bars in Nuendo hit 20, 30, 40 etc, there is a 16 byte message to handle the "2", "3", "4" etc.

I split the screen so I can see both Nuendo and BT.
Setting the play cursor at bar 19, I play.
Then back up.
And play.

Sometimes BT reacts to this trigger, sometimes not. We are talking the exact same 16 byte message into only ONE translator in the whole BT project.

Furthermore, all 16 byte messages are detected in the "Capture MIDI" window of the translator. On the BT virtual port. (though they are hard to see in that window with all the numbers flying by)

As far as I can see, I have proven the 16 byte messages are in the port consistently. No easy way to monitor BT virtual ports at the same time but I get the same behavior with MIDI-Yoke, where I can watch the messages easier.

Okay, I get it. Let me send this over to Florian (lead guy for MT) and see if he has any ideas. If Capture MIDI is seeing it then the Virtual Port is carrying it, so the translator should be triggering. Something is definitely not right. AND you're having the same interaction with MIDI-Yoke, which means it isn't a virtual driver issue.

J

Thanks, yeah it looks buggy.

I'm too new with BT to call it yet. Appreciate the backup.

For now, I am stepping back from projects involving streaming sysex. I have no problem translating MMC sysex (single-shot) or temporary bursts.

Hi,

I tried almost the same thing, but gave up on the approach because of the amount of text truncation. I then bought a 10 inch tablet and use it as a 2 PC monitor located against the d8b meter bridge, right above the last eight faders of d8 b. It runs a MCU display emulator at the bottom of its screen. Then I used the mackies vfd for other info

I did the worlds crappiest video demoing it....

http://m.youtube.com/watch?v=KZ-CLG2O2-U

Guido

Guido, nice solution!

Bobby, I believe the problem is that MT does partial matching, i.e. if only the first part of a message has arrived, it'll wait for the next part of the message, which might arrive separately (Sys Ex messages can arrive in chunks).

Here is an example:

Given those two incoming triggers in MIDI Translator: The first trigger has 16 bytes, the second has 15 bytes.
Now, say, the following MIDI message comes in: It has 15 bytes. It tries to match the first translator, and it finds that it DOES MATCH the first 15 bytes of the first translator: vv will be set to F7! It marks it as a partial match and waits for the next MIDI message(s) if it provides the remaining F7. I'm quite sure that this partial matching causes the problems you're seeing, in particular if the "stop processing" checkbox is checked.

Now to fix this, you should order the translators by length of the incoming sys ex message, e.g.: You must check "stop processing" to prevent that a 15-byte message will partially match a 16-byte message.

Of course, partial matching of the sort above is nonsense (MIDI does not allow two F7's to come one after another), but there are many legitimate use cases for partial/combined MIDI message matching. I will look into the matching algorithm to see if it can be improved to detect unintentional matching as above.

Let me know when you have the chance to check that out!
Florian