I got mails from few users that MIDI Automator takes too much CPU resources when using the screen automation. As I use the framework SikuliX for that, I do not have any influence on the efficiency of that implementation. But if we think about how it works, we can figure out several useful parameters to play with.
So the screen automation has to repeatedly search for the given screenshot on the whole screen. Depending on the screen resolution this needs more or less time. So I added the following options shown in the video.
I got independent e-mails from Sander and Tim who had some problems running MIDI Automator on Windows. I was astonished as I test every release on Mac and Windows before publishing them. I changed some very detailed and technical mails with Tim from Germany who contacted me on last Friday evening. Sharing the same native language made it easier for both sides. At the end of the weekend it was clear that testing the deployment on a development machine did not make any sense. The Windows installer missed a few things to configure which lead to missing icons and crashes on the users system. I just did never realize it as I deployed on my development machine wich is somehow over-configured in any way. Tim and me could fix all issues in the version 1.5.2.
So I am very sorry for all Windows users who suffered from this. I will test my releases on a fresh mashine in the future. Many thanks to Tim who provided some very useful information to the issues.
When searching for ways to decrease the CPU load when using mouse automations I found the possibility to configure the scan rate of the automation. Per default the mouse automation searches 3 times per second for the given screenshot. Especially if you have a big display resolution this takes lots of CPU power. But maybe searching that often is not necessary. So if you only need to search the screen once per second or every two seconds (scan rate 0.5) it is possible to reduce the CPU load.
When experimenting with the scan rate I realized that the screenshot similarity can only be set once for all automations. This due to the design of the underlaying automation framework SikuliX. So I had to remove the similarity configuration for each automation and provide a global configuration for all automations instead.
I got new feature requests from users of MIDI Automator. I feel very honored to see that the tool is used by creative heads for use cases beyond my own imagination.
So Laimis uses the mouse automation of MIDIAutomator to automate sound changes and configurations instantly from a midi controller. He noticed that the mouse automation consumes much CPU resources and asked me if I could implement a time out option. So the looped search for screenshots would just time out after a predefined time and the CPU will be freed. He sent me some videos and source code snippets with ideas about using less CPU resources in general (Thank you very much for your work). Due to that I was able to find a CPU resource leak and fixed it in version 1.3.1. There are other ideas to reduce the CPU hunger of the mouse automation and I will implement them in the next version. With v1.4.0 comes the possibility to set a time out for each mouse automation.
Another user called Doug uses Reaper as DAW. Unfortunately MIDI Automator was not able to open Reaper files on Windows (on OSX it worked as expected). It turned out that Windows did not know which program to use when using Java API to open reaper *.rpp files. To my own surprise Windows opened the *.rpp file with reaper when I double clicked on the file. Luckily a programmatic opening of the Reaper files worked when starting reaper from the command line with the desired file as argument. So I implemented the possibility to configure the opening program for each file in MIDI Automator. With this you have the control which program will be opened for each file. If no program is provided, the operating systems default program for the file extension will be used.
I found some time to implement two new features during my holidays. MIDI Automator is now able to import and export the set-lists and preferences to so called *.midauto files. This is just a ZIP file format that contains the file_list.mido and the midiautomator.properties files.
The second feature is the ability to order the set list by drag & dropping the list items.
My band Nano Kid was asked to play at the opening of the Wear It Festival Berlin. We should present the Little Black Midi, a wearable midi controller our singer invented. As a result the Midi Automator got some new featrues we needed for that gig (Yes you are right, this is a lame try of search engine optimization for my other projects).
With the previous versions it was already possible to trigger mouse automations by midi messages, but theses used the midi device configured for "MIDI Remote IN". The new release can now set a listening midi trigger device for each automation individually.
We also noticed that the image recognition for the automation did not work well on every computer. So the similarity (or recoginition tolerance) can now be set for every automation individually all automations globally (edited s. http://www.midi-automator.com/?q=node/17). 0,99 is the highest possible similarity and 0,5 the lowest possible. So whenever the mouse automation is not able to find your screenshot, you may now lower the similarity until it works.
!ATTENTION MAC RETINA USERS!: If you are taking a screenshot on a retina display, MacOS somehow saves it with the doubled resolution. MIDI Automator will not find this image on the screen unless you decrease its size to 50% with an image tool. Another way is to take the screenshot on a non retina display i.e. an external mmonitor.
The use of mouse automation needs much CPU resources, Midi Automator has to search your complete screen for the given screenshot multiple times per second. The bigger the resoultion of your screen, the more CPU power is needed. This demand gets even higher the more automations you have configured. However in most situations the click targets are always at the same place on your monitor. So MIDI Automator now remembers the area when it has found a screenshot the first time. This decreases the needed CPU power. On the other side it will not find the screenshot if it has moved to another place while MIDI Automator is open. As a solution you can now decide for each automation if MIDI Automator shall search for a movable or a non-movable target.