Hi,
I'm using the Mackie monitor of BC Manager in the REAPER DAW (https://www.reaper.fm/) together with the REAPER-only ReaLearn plugin (https://www.helgoboss.org/projects/realearn/).
In short, ReaLearn greatly enhances REAPER's MIDI/OSC control functionality and I use it in a MCU like way (e.g. doing track banking) and for this I use BC Manager's Mackie monitor to display the names of the tracks I'm currently in, controlled by a BCR2000.
While setting this up I came across a track names display issue on the Mackie monitor.
Initial report in the ReaLearn thread on REAPER forum: https://forum.cockos.com/showpost.php?p=2497306&postcount=1674
The Realearn dev (helgoboss) could reproduce this and here are his thoughts:
https://forum.cockos.com/showpost.php?p=2500314&postcount=1722
@Mark van den Berg
Would appreciate hearing the thoughts about it from your side (maybe post directly in that thread if you like, helgoboss suggested that I should contact you).
Thanks.
The Realearn developer has
The Realearn developer has "the slight suspicion" that BC Manager's Mackie monitor is "a bit wrong / not complete", in that it "seems to only accept changes starting at the beginning of that long line, not partial changes that start somewhere within the line."
I don't have Reaper, so I've tried to test this suspicion by sending Mackie messages from the "MIDI System Exclusive messages" window of MIDI Tools to BC Manager via loopMIDI.
Result: I couldn't find any problem: BC Manager's Mackie monitor immediately displays any message of any length at any position.
And I can't see any problem in BC Manager's source code either.
To establish definitively whether your issue is BC Manager's fault, you can try this:
Open BC Manager's "MIDI input messages" window, press Record, then repeat your tests.
If any message appears in the "MIDI input messages" window but not in the Mackie monitor, there may indeed be a bug in BC Manager's Mackie message handling.
On the other hand, if BC Manager simply doesn't receive a message in certain cases, the problem lies elsewhere.
Hope this helps,
Mark.
Thanks for the reply and
Thanks for the reply and sorry for the late follow up.
As I don't have knowledge in Mackie messages, could you give me example messages I could forward to the ReaLearn developer?
particularly demonstrating this case working correctly:
As I don't have knowledge in
Never mind.
I think I've found the cause of the problem:
Upon re-examination of the example mentioned by the ReaLearn developer, I noticed that it contains two so-called "null characters" (00 00) at the end:
F0 00 20 32 00 14 78 00 74 7A 66 74 7A 00 00 F7
These null characters are problematic for BC Manager:
When a Mackie monitor window in BC Manager receives a Mackie display message, it refreshes the whole affected 56-character line(s).
However, I've now discovered that the operating system's underlying display routine always applies null-terminated string logic: it cuts off any characters after the first null character.
So, for instance, after ReaLearn has sent a track 1 name containing a null character, any subsequent messages for tracks 2 etc. will not show up in BC Manager, because the 56-character line will only be displayed up to the (still present) first null character in track 1.
I don't know whether there's any official documentation of Mackie's display messages, and if so, whether control characters 00-1F and 7F are allowed, let alone how a real Mackie would display these characters.
In any case there is no standard way of displaying these "non-printable" control characters on a computer screen.
See for instance https://en.wikipedia.org/wiki/ASCII and https://en.wikipedia.org/wiki/Control_character.
I've tested how a few of the text editors I use treat a null character present in a file being opened:
On the other hand, most debuggers and hexadecimal editors (e.g. HxD) show a null character as a dot rather than as a space. In fact, this is the method I tend to use in my own applications: in my experience it's usually more important to distinguish a null character from a space than from a dot.
I think I've also seen applications showing all control characters as question marks.
I can't change the way the programming language used by BC Manager writes text lines to the screen, because the underlying routine always applies null-terminated string logic.
I gather that ReaLearn splits each Mackie display line into eight 7-character segments. However, for several reasons this method is not an option for BC Manager. For one thing, there are also applications (like Propellerhead Reason, IIRC) that don't always output these 7-character segments, but e.g. send longer segments containing general status messages. In other words: BC Manager must sanitize null characters in any position.
So here's BC Manager 4.1.3 Alpha 1, which converts any incoming control character (00-1F and 7F) to a dot:
If there is no specific reason why ReaLearn needs to send null characters (and I can't think of any such reason), it would be good if ReaLearn switched to spaces.
Hi, thanks for the reply.
Hi, thanks for the reply.
I just gave BC Manager 4.1.3 Alpha 1 a try, and let me say it looks like it works, wow. [emoticon:smiley]
All the cases I reported initially on the Reaper forum (e.g. display not refreshed when reordering/renaming tracks) seem to work fine now.
Ok, there are now these dots, as you mentioned, and I'll forward your reply to the ReaLearn dev to see if he can do something about it, but even if not, it's absolutely useable now even with the dots.
https://i.imgur.com/jlYvPOm.jpg
So thanks again for looking into this, much appreciated and I wish you nice holidays.
I just gave BC Manager 4.1.3
Great news!
After some thought I've decided not to publish the corresponding Release version of BC Manager 4.1.3 immediately.
It's only a few weeks after I published 4.1.2, and I don't want to pester everybody with a new version just fixing this peripheral issue.
The same to you, and to anybody else reading this!
Hi Mark,
Hi Mark,
ReaLearn developer here. Thanks for looking into that. I will change the zero byte to a space, that should make no difference. Not sure if it's even necessary for you to make this change in that case? I used the zero byte because it worked for the control surface I tested it with and the spec that I have doesn't say anything detailed about that.
Have a good Christmas!
Benjamin
I will change the zero byte
About a month ago, while debugging some other display problems in the Mackie monitors (see this topic), I noticed that even in a (supposedly!) fixed pitch font like Fixedsys the width of character 7Fh was less than the width of all the "normal" (ASCII) characters. So 7Fh messes up the alignment of the two Mackie display lines.
But I hadn't made up my mind what to do about this.
But I've now realized that the 01h-1Fh control characters are even messier: some are displayed as weird graphical characters, others not at all.
And of course, even worse: 00h prevents the display of any further characters in the same line.
So it's totally clear that for robustness the Mackie monitors must sanitize all non-printable control characters (00h-1Fh and 7Fh).
In fact, implementing the sanitization of Mackie characters was very easy: I only had to insert a call of my pre-existing "PrintableAsciiChar" function. And since my (Delphi) applications are compiled to machine code, the extra processing time is negligable.
But thanks for switching ReaLearn to spaces:
This means that there is no reason for me to rush out the Release version of BC Manager 4.1.3, or a version of MIDI Tools containing the same fix.
I've been working on a new feature in the MIDI Keyboard window of both these applications (and some others), which I'll hopefully be able to release early next year, so I can simply incorporate the Mackie character sanitization in those versions.
Merry Christmas to you too!
Mark.