Hello, I am working with 84 html prompts in 84 different macros, they all of the exact same position on screen and size. What I would like is a mutually exclusive feature, meaning I want to see only 1 at a time, which I achieve currently by cheating because they all stack on top of each other so each new html prompt hide the previous one.
The issue is that when the first prompts start to time out, I want all of them to time out and
dissapear.
I have no issue setting the timeout to 99 hours for all of them, but will that affect the computer performances when there will be hundreds of them stacked ?
this is one of the 84 macros, basically there is a midi cc trigger and an html prompt with a basic color and some text
edit : maybe it would be wise to merge everything in one macro, have some sort of lookup table that match 84 values of the same midi CC to 84 text/color combo and then have one html prompt that uses a variable for text and color. I have no idea how to do that
I would like to use Channel 2, CC0 and value 0 to 83 on port "BMT to KM" to trigger conditionally the 84 different text and color
I am not the sharpest tack on this website, but I want to try to answer your question.
In your code, each window is created by a separate macro, and until the window closes the macro is still running. In the current version of KM, you are limited to 50 macros running simultaneously. As soon as you hit 51, I believe all running macros terminate. So in your case, you can't have "hundreds of windows stacked," because that would require hundreds of asynchronous KM macros, which is impossible.
That depends what you mean. As long as the Custom HTML window is created within the same macro, you will have the same problem, because multiple copies of the same macro still counts towards the limit of 50.
But if you change your approach, and have a separate macro that is NOT triggered by a MIDI event, which is SOLELY responsible for the Custom HTML windows, this should be possible. But you can never CALL that macro from your triggered macros. It has to run asynchronously and permanently. It would receive its data through some data structure that your MIDI-triggered macro creates. Perhaps a dictionary seems optimal in this case. This way your 84 macros simply queue up a request and terminate immediately. This separate macro would have access to all the requests for windows queued up, and in its simplest design, it would not display more than one window at a time. (Why would you actually want more than one window displayed at the same time on top of one another? That sounds like a bad design to me.)
I do things like this all the time. I have macros that trigger on events, not MIDI events but other events, and these macros simply record the event in a data structure, and terminate quickly. A separate macro is responsible for taking action based on the recorded data. It works fine for me.
Thank you. I am still trying to make sens of the second half of your comment as I am just a beginner.
To answear your question my goal was never to stack windows on top of each other, that is merely a cheap workaround I found to only see one window at a time
Thanks. Take a little time to ponder my comment. Ask any questions that you have.
I tested your macro just now. Is the goal to display the name of the chord/note? Personally, I wouldn't use a timeout to close the window, I would just have the next MIDI event close the old window and open a new window.
Actually, I may have another idea. Instead of using Custom HTML action, you could use this action:
Notice the option to display "Large Text".
There are several ways to "close" the "Large Text Display" window, but I won't mention any of them since I'm guessing you don't want to use this feature. But it's what I would use, because I love its simplicity.
It sounds like you are unaware that you can change the colour of the Large Text window. But I won't try to force you to use that method.
I didn't realize that. Perhaps I didn't realize it because they were all in the same location.
Using my alternative method, the macro that's dedicated to creating your windows would know how to close its window, and that would probably work like this:
The variable "floatingvariables" is the name of the variable I use to save the location of the Custom HTML window, which you can obtain by placing this in your CustomHTML code:
That's exactly what I did this week, which placed the location of my Custom HTML window at the specified location, and saved the name of the window in the KM variable "floating variables", which I could then close using the action above.
I'm not trying to force you to change your entire macro design, except for the fact that your design won't meet your requirement of supporting hundreds of windows at the same time (because the KM Engine will abort if you try doing that.) If you want a solution that meets your requirement, you probably need to consider my approach. But there are probably other approaches that other people can come up with too.
I also like the look of the html prompt. Borderless and some colors also have a shaded look. I am unaware that this can be achieved with the "large text window"
That's fine. You can use Custom HTML windows for your needs then. Large Text windows can't use "stripes" as you have in your screenshot.
My variable name, "floatingvariable" was just the variable name that I chose because my Custom HTML window displayed a bunch of variables in a floating window. You are free to change the name to something more appropriate, like "ChordNameWindow".
I'm pretty sure you only need one macro to handle the trigger, and perhaps another subroutine for your custom prompt (that you can call from other macros).
And yeah, that lookup table would be a good solution. If you could share your macro(s) and the table with your text/color pairings, it would help everyone.
The subroutine,called "Reuse Custom HTML Prompt", takes 4 parameters:
Call it from from the second macro named, "Call Resuse CHP Window".
The subroutine will check for the existence of a CHP window with the id: "MIDITranslated"
On first run, after checking if an existing Prompt window is already open, it displays your uploaded CHP.
Call it second time and it should identify the previously opened CHP window. Instead of opening a second window, an "Execute a JavaScript in Custom Prompt" action sets the open CHP window's "translation" element and background color to the new text, color and background color of the parameters received.
As a result, only one CHP window per id should ever be open.
If you prefer to have an AppleScript create and run the dynamic script in-memory, comment out Option A and uncomment Option B. Option A plugs the subroutine parameters into a variable containing the javascript that sets the window elements and then writes it to a file in your Mac's temporary directory. The Execute a Javascript action uses the contents of that file. Option B is a lot more of a hassle to modify because characters need to be escaped.
Put your triggers and logic into the "Call Reuse CHP Window" macro.
