As far as I can tell this is due to KM attempting to parse the macro master list. I have roughly 360 macros I've built, most of which use some kind of image recognition. These aren't light macros per se, and I get that... However if KM's editor weren't written in such a way where every single macro is tangled up with every other macro this wouldn't be an issue.
Macros that were heavy on their own would be more resource hungry, this is something I deal with day to day in Logic. Some projects require you to scale things back by temporarily rendering things to audio. KM Editor's approach however would be equivalent to me being required to open every other Logic project and temporarily rendering everything to audio before I could resume working on the current project. I'd wind up spending more time trying to stabilize Logic than actually creating something with it...
I've found my master macro list, the single plist is 200 MB. Just attempting to preview the plist causes finder to pause for about 3-5 seconds before it can display it. Because KM lumps all macros into a single file the editor is having a hard time parsing any one macro because it's attempting to parse an insanely large file that even finder has a difficult time displaying.
This approach of wrapping everything up as one massive file would be like Premiere, Davinci, or an equivalent video editor storing each discrete project inside one single master file; and the ability to edit each discrete project hinged on the sum total of events inside that master file. The moment you had a project where scrubbing the timeline became an issue, scrubbing the timeline in every other project would also become an issue. Essentially it'd be the equivalent of that application requiring you to work on all projects at the same time.
The same could be said about any other application... Imagine if every time you edited or created a unique image photoshop's overall performance started to degrade.
As far as the (apparently intentional?) limits (<1000 macros, <20 actions, etc)... Sure, you probably wouldn't want to write a novel using notes. However notes doesn't limit you to the number of notes or characters you can write, and the user is free to write as little or as much in it as they'd like. Frankly this is like saying that an email client whose inbox can't handle more than 1000 emails, and whose replies cannot contain more than 20 unique words would be a well designed email client.
This is the developer's choice and I respect that, that said, I hit its ceiling in only a month. I personally find this to be an incredibly inefficient way to design an editor.
I wish that were possible. I am using coordinates wherever possible, I'm even using 'enter text' wherever possible. Unfortunately with the mission critical stuff, (instruments and audio processing plugins), they're only available as floating windows and don't display in a fixed location. Given that you typically have a lot of moving parts while editing and arranging it's pretty much impossible to pick coordinates that will work.
And unfortunately the vast majority of plugins have either no shortcuts, or very few. I really have tried to streamline things as much as is possible but given the nature of working with plugins KM is pretty much the only option because it can do image recognition...
Appreciate your input though. I'll certainly look and see if there's anything I may be overlooking, but being that I'm only looking at streamlining the 'daily dirvers' I know these very well and am more or less positive click at found image is the only action that'll do the job... Cheers...
They don't. Logic (even though developed by Apple) has essentially no support for Applescript. At most you may be able to do some text entry to rename tracks.
And I definitely understand that image recognition is CPU intensive. I wouldn't expect otherwise. I don't see this as any different then me pushing a particular project to the CPUs edge and having to scale it back via rendering things to audio...
But the editor being developed in such a way where all macros are inter-twined with the edit-ability of all other macros strikes me as an odd choice. And don't get me wrong - If a macros calls on a function that's part of of another macro I completely understand why there would be a necessity for those two macros to be intertwined.
My frustration is that I can't even create a rudimentary macro that just sends a series of keystrokes without experiencing persistent lagging and beach balls. This wasn't the case for the 1st few weeks using KM, and over the past 2 weeks I've watched KM's editor grow increasingly slower as I've created additional macros. At this point I'm genuinely looking at a lag time of about 5 seconds, and this lag happens about every 10-15 seconds, constantly, even if working with a brand new macros with nothing in it...
For the user to be expected to go back through and evaluate 360 macros just to get a simple one to work? I can't recall any other application I've used over the years where the developer's attitude was it can't be improved and you're more or less on your own...
Anyway I really didn't intend to hijack this thread... I've gotten the answer I need which appears to be that I'm essentially stuck living with things as they are, and now have to go back and look at all previous macros. If people have any other suggestions that would be great, but in terms of critiquing this I've said what I feel was necessary.
That plist file is huge. Are you storing your found image screenshots (in the found image bin) within your macros? If so, remove them and save the screenshot/images in a folder, then select the file dropdown selection, within that found image action, and point to the file in the directory selection . When I had a 60 MB plist file, I went on a mission to use the file selection instead of dropping the image in the bin. Now my plist is about 3 MBs and I have about 1600 macros. Sped up my KM tremendously. Try it.
Most if not all floating windows can be located if you know how, albeit not necessarily with ease.
Take a look at UI Browser – but grit your teeth; it's not easy to learn how to use – nor is it inexpensive to buy.
Also – I have a number of macros on the forum designed to explore windows for UI-Scripting. Unfortunately I don't have a neatly organized list at hand presently.
If you have Macro Groups, you may want to disable them. Once done, re-enabling them individually with a lag before the next Group is re-enabled may help you isolate if it's particular macros causing the lags you describe. Point being, it may be a small number of macros causing the issues rather than the total number of macros you have.
Just checked and my Keyboard Maestro Macros.kmsync file is 10.1MB and I have 1310 Macros and counting with no lag in the Editor. I have many Macros that use Found Image as well as other methods.
So, your 200MB Keyboard Maestro Macros.kmsync is quite enormous I think.
But @kcwhat has suggested a solution for your use case which sounds like it might solve your problem in this post, in this current thread:
Ah! Thanks KC. I have been using drag and drop. When I 1st demoed KM everything I searched/watched/read used drag and drop examples (probably for ease of explanation purposes.)
So it sounds like what you're saying is that by dragging the image in, KM is actually converting every pixel of the image into code, vs referencing a link, yeah?
If so it sounds like this may be the culprit of the performance drop I've been experiencing... I'll try this method and post back...
For clarification: You're suggesting I click the menu next to the thumbnail box and choose "File" under the dropdown list. This then replaces the thumbnail box with a text field which is the path to the screenshot originally used, yeah?
Thanks a bunch for posting this... Lets see how it goes...
Yes - exactly. Try that. If you need a video or gif, for a better understanding, just reach out. It’s made a huge difference for my Keyboard Maestro speed. It took a while to to redo but with the performance, but it’s worth it.
Please note: I gave some bad information earlier. I, currently, have 2278 macros and my plist file is 5.4 MB. Sorry, I hadn’t checked in a while.
I'd recommend AppleScript where possible, then System Events and GUI scripting, only then - "Found Image". And as your very specific case - the suggestion of @kcwhat and @JMichaelTX.
And also a little bit more respect to the developer.
Though I think KM is a brilliant piece of software (as I'm sure many people here with months of time saved - see the cool feature in the menu "About KM"), it is not absolutely universal for any possible needs. It does what it designed for at 150% and thanks to @peternlewis it is constantly improving. It may happen that KM will not cover your case, but it says nothing about the quality of this software, just about your case and your expectations, sorry. Hope you'll solve your problem and interested to see your report on that.
Didn't know this trick before. I had only a few small found image actions. I did what you suggested. It reduced the .plist file from 2.7MB to 2.6MB. I'm happy about it. Thanks!
If the image will always show up in a certain area of the screen, we can also limit the search area. I did not notice that until now. I could limit some of my found image action to a 40*35px area.
Fair enough, and 100%... I'm going to revamp my macros with KC's method. If it solves the issue (which it sounds like it will) than absolutely, I'll update and acknowledge that the issue was me not understanding KM well enough yet.
And I don't disagree, I've put a month of hard labor into automating what I can. While it's been frustrating watching KM come to a grinding halt, I'm sure I projected some of that frustration toward Peter without understanding that there are multiple ways to use the found image action...
Appreciate everyone's suggestions so far as well. If things go as scheduled I'll be updating this thread some time over the weekend once I've had time to tear through a good 1/3 of the macros I've created. Considerings things only got really rough in the last week/week and a half, it seems like I should see a big drop in the plist size, and some recovered snappiness by then...
Thanks again @kcwhat. Really appreciate you setting things straight. As I've said this seems to explain the enormous plist size. Cheers!
Thanks as well cc... I'll definitely give this a look. One of the more challenging issues I've had to work with so far is plugin windows being at different locations. Appreciate the tip. Best...
IMO, it would be best if KM would do this automatically, and cache each found image image in a file instead of storing it in the master monolith file of all macros.
There are many ways Keyboard Maestro could work such that a larger database of macros could be supported. It could be an actual database instead of a plist for example.
But there are also consequences of these changes, and not just in my development time. Cache coherency is one of the hardest problems in computing. In fact there is a standard software developer quote “It’s often said that only two things are hard in computer science: cache coherency, naming things, and off by one errors.”
If the images are stored separately, then that will have a flow on effect on how syncing works. And what happens when the image goes missing, or is changed underneath Keyboard Maestro, and so on.
Yes, the monolithic plist has draw backs when folks start pushing Keyboard Maestro well past what it was designed for, but it also has advantages in other directions.
Thanks!