What you are doing here is exactly why KM has a thing called "Dictionaries." If you knew about dictionaries, you would be using them here. I don't want to force you to use them, but I still want to tell you how they work. You can set up dictionaries similar to saying this:
Notice how we are saving data into a dictionary named "MyDictionary" using strings as the index. Also notice that we can assign "newlines" as characters in that string. We would assign newlines only if the string is too long to fit on a single line of text on a SD button.
I won't force you to change your approach, but at least I want you to be aware that your approach is complicating matters. But if you don't want to learn about dictionaries, we can certainly solve your problem by using the first six characters of your strings as an "index" instead of using a proper dictionary index. If you decide you want to stick with your approach, I'm willing to help you with that.
The Mackie MCU protocol is an adapted type of MIDI control language. It is fundamentally MIDI at its core, but the individual MIDI notes mean different things to the MCU controller than they would coming from a digital piano, synth, or other instrument using standard MIDI.
MCU uses Sysex to update hardware controllers on the state of things within the software being controlled by said hardware controllers. So, in this case, I'm using KM to catch the Sysex coming out of my DAW, manipulating it to do what I want with it, and then manually translating the manipulated Sysex (using a different lookup table I'm using in KM that is working great) to the standard 6 character ASCII display name that MCU uses to report back to hardware controllers.
So, if I can harness these 6 character identifiers (which are just heavily abbreviated versions of the full name) to then apply my own more readable naming convention, based on what I've entered into that lookup table, I should be able to present my SD buttons with anything I want.
I understand what you're saying. I've seen reference made to the KM Dictionary, but never realized exactly what it was or how it could be used for something like this.
What is the advantage to using Dictionary to using the Regex approach? They both are using an index to look up one or more words associated with that index identifier. It seems like the only real benefit is that you could go ahead and define some of the formatting constraints, such as the use of "\n" within the words themselves, Or am I missing other benefits here?
That said, another wrinkle to my situation is that my ultimate intent here is to be able to make this available for someone else other than myself to use. They won't necessarily have any knowledge of any of this stuff at all, so it would need to be a very simple process for them to add lines to either my lookup table or a dictionary. Most people can add words in a line to a text file without too much trouble, but they might get lost trying to figure out how to navigate KM to edit dictionaries.
I'm starting the table off with some variables I'm already identifying/translating, but the other users will also have new entries they will also want to make on their own. With Regex, I'm taking care of the formatting, and line spacing for them, whereas with the Dictionary, they would have to know the syntax to add things like "\n" for a line break. At least that's what I'm gathering from your description of dictionaries.
When you have a built-in language construct that separates indexes from the data that they refer to, I think the code no longer has to handle their separation. Your case may be very simple, but as you progress to more complex examples, the time saved increases.
Fair point. If your users are experts at regex already, but don't know about dictionaries, then maybe regex wins. But c'mon not even griffman was able to solve your problem without using ChatGPT, so how simple do you think this approach is? EDIT: you probably meant the user will maintain the data file, not the code. I realized this further down.
That's one of the advantages of using Dictioanries. The data is separated from the index. All you have to do is write the content of the dictionary for that key, you don't have to worry about separating the key from the data.
I think you mean you want users to be able to edit the data, not your code. Well, that's easy, even trivial. You can just create a macro that lets your user view and edit the dictionary's contents. I do this all the time in my macros. It's trivial, and it's more idiot-proof because you don't have to teach your users about certain things that might break your file structure.
With regex, you are making the user manually learn the format of a line in your structure. If they break the format rules, they might break the macro. In my solution it's almost trivial. I'll write up a macro for you right now, which you can test out. It will be fun for me to do that. (I do this all the time.) I'll try to make my macro work like your macro will work, so you can copy my code more easily. (If you want to. You may sitll not like my code.)
Okay, I just wrote a macro for you that lets you manage a dictionary such as you seem to need. I had fun doing it, so even if it doesn't work for you, or you hate it, that's okay.
Show, Edit, Add or Delete items in an Inventory Dictionary Macro (v11.0.1)
You may like the code, and it may convince you to switch to using a dictionary. If you don't like it, use your own method. I think this macro demonstrates that it's very easy for any user to edit your required data in a foolproof way.
Correct. I'm only talking about users manipulating the data, not the underlying code itself. The idea is to keep them away from the underlying code as much as possible.
I've actually made a separate macro myself, similar to what you describe, for the purposes ot putting all of the user definable variables into simple entry fields in one macro. Otherwise, the intent is that they leave the rest of the macros in KM alone.
So I'll give the dictionary thing a try. I haven't used it before, but I see some of the benefits you describe. If it's going to have a dedicated macro for user data entry, that also makes it more palatable.
Dictionaries are quite useful for a lot of things. They make my life easier now that I know the syntax. The syntax can be a roadblock for some people. But if you can get past that roadblock, you will be very happy.
In a few days I'll be going on a trip and I'm not sure how long I'll be gone. It could be quite a while. You may not be able to use me to finish your project. There are others here who can help you.
