Keyboard Maestro’s built-in actions are impressively FAST and efficient. This macro translated your text in just 0.148 seconds.
My code worked in 0.038 seconds.
For context, if you go to page 17 at the link below, it will explain what Mackie is.
I can't try your solution because it doesn't reference the lookup table I have, and it is a necessity to use the lookup table. I don't know anything about xxd but xxd isn't going to understand what Mackie code is, or how to translate those Mackie values to ASCII characters.
So I'm still interested in a shell script type solution, if that will work, but it does need to reference the lookup table, or something similar. I'm also going to give Juan's solution a try, once I've finished reading thru it.
Good to hear.
That's what my code does. The lookup table that you created is built-in to the xxd command. My code works. You need to test it now. Or you can ignore it.
Just make sure you add a 0 as your first number. And remember to have an even number of characters, until I can figure out how how avoid those requirements.
Further testing shows me that you don't need an even number of characters, but you still need the zero at the front.
Are you saying that those values in the Mackie table are some sort of ASCII standard or something? It's not that I'm trying to ignore it, but maybe that's where the confusion lies. Are you saying that 46 = F is some kind of standard, regardless of whether it's in a Mackie context or not?
Shell scripts that use highly optimized functions and commands are hard to beat. That’s why I suspected my custom solution might not be the most efficient for a task that already has well-established solutions.
Still, I suggested it in case he wants or needs to decode using a custom lookup table.
YES!! It's been a standard since 1963.
1 Like
Ok. I see now where the confusion lies. I just looked into this a little more, and didn't realize until now that what Mackie uses is just hex to ASCII conversion. I never realized that until now. So now I see how it works in your shell script. I thought Mackie was using their own custom translation structure, hence why I thought I needed a lookup table.
Let me plug in your script and see if that works. I'm still not sure about the zero at front thing, but maybe that will make more sense once I give it a shot. I just sat down in front of my computer to have access to KM to give your script a try. I'll reply back once I've had a chance to try it out.
Thanks you. I apologize if I sounded frustrated. I'm 80% sure my solution will work (if you use my zero tip), but if I'm wrong, I'll try to fix it.
No worries. It turns out that I was the one confused by the hex to ASCII thing. I thought the Mackie thing was proprietary, but it turns out it is not. So I should apologize for that! ;). And, as always, thanks for your help!
In any case, I tried your script out, and it is working, kind of, when I put a zero, followed by a space, in front of the string. However, it seems to be cutting off the last few characters of the string. I'm not sure what that is about. Thoughts?
I haven't seen that problem myself. You should show an example to demonstrate the problem.
0 55 41 44 78 31 37 35 2D 42 20 43 6F 6D 70 72 65 73 73 6F 72
gives
UADx175-B Compre
When it should give
UADx175-B Compressor
It's cutting off the "ssor" at the end,
Since I don't have the value of your variable Insert1Char, there's no way for me to replicate and troubleshoot your problem. But start with a much simpler example. Since you are just starting to use xxd for the first time, pass it some constant first. Once you get the hang of it, then start passing variables. And you don't need to pass 28 variables separately like that. I'm sure there's a way to simplify that enormously.
Ok let me test that and see if I can figure out what's wrong.
I confirm it's cutting it short. I have no idea why. I'm looking into it. There's probably a fix.
I edited to add some info above, to my previous post, for further context. That said, this is how the values come out from my DAW, so I don't really have a choice otherwise. Also, I'm already reducing the full 63 character string from my DAW, to just include the characters I care about, so there's that to contend with too, hence all of the variables.
In any case, it's spitting that out as a final variable (Insert1MCUName), and that final variable is what I'm sending to the shell script, which is what ultimatley matters for this discussion. So, to be clear, I'm not sending 28 variables to the shell script. I'm only sending it one variable, that single variable being the summation of all of those other variables you're seeing in that image I posted.
Glad you're seeing that on your end too. I don't know why it would do that. Thanks again for looking into this.
Apparently the default output length of the xxd command is 16 characters. That can be increased to 32 with the following syntax:
xxd -r -c 32
I'm flabbergasted that there is a 16 character default. I'm still trying to understand it better.
You certainly have a choice of how you pass the values. Right now you are enumerating 28 variables with 28 separate tokens. You don't have to do it that way. But I don't want to distract from the problem at hand. So you may continue doing it the wrong way until we fix your primary problem.
Adding that extra syntax took care of the truncation on my end. So it's working pretty well, at least so far. I'm going to do some additional testing though. Now I'm just going to add in a regex action or something, to get rid of all of the spaces, unless there is a way to do that as well, in the xxd script?
Edit: I'm also noticing now that it's adding in a "÷" symbol at the end of each returned line, for some reason. Any idea what that is about? It is possible that it's something on my end causing that.