Can I see a video of all the new features?
That way, I can make up my mind if I would like to upgrade.
Thanks.
I imagine that would take an enormous amount of time from whoever put it together.
Version 10 has a trial period just like previous versions. It will allow you to revert to your previous version at the end if you don't like it.
I recommend just trying it out. The price is incredibly reasonable and there is bound to be at least a handful of features that you will find you can't live without. 
-Chris
3 Likes
That's right. And, you bet, future macro examples others upload will probably take advantage of the new features in v10. I'm waiting for them. 
2 Likes
As an intermediate user, the release notes are somewhat helpful, but it's often not clear what certain new features are.
It would be helpful if there were a video walkthrough of all significant new features, as I'm sure there are some I don't fully understand that would actually be quite useful!
Curious if someone has recorded something like this?
1 Like
Question was already asked here:
Unsurprisingly, the answer is “no” as it would involve considerable time and effort to create and anyway, a “big new feature” for me wouldn’t necessarily be one for you. Sometimes you just have to plough through the release notes I’m afraid!
2 Likes
I think this will be pretty much what you are looking for (sometime in the new year):
In the meantime, as @tiffle says, it's best just to try out things on the list and see if any are relevant to things you are trying to achieve. Also check out any posts on this Forum that reference "Km 10" or similar as we are all discussing the new features and helping each other get the hang of them. I learnt a few things that way.
2 Likes
You might keep an eye on MacSparky's Keyboard Maestro Field Guide page in the next few months. I read somewhere on the KM forum that he mentioned he will do a free video on the new features of KM10 around the new year.
-Chris
2 Likes
Thank you, all!
I must confesss, I hadn't heard of MacSparky before. Seems like a great blog. Now following, in part to keep an eye out for their upcoming video on KM10.
1 Like
Okay so not all the features but at least this one feature I would really love to see in a video with an example.
Does anyone know of videos that explain subroutines and the details found here on this Wikipage?
I am really having a difficult time wrapping my head around this with out seeing some examples but no doubt it is really handy.
https://wiki.keyboardmaestro.com/Subroutines
In Keyboard Maestro, traditionally subroutines were implemented with the Execute a Macro action, passing a single parameter to the %TriggerValue% token, and returning results in instance or global variables.
In version 10.0, Keyboard Maestro adds an explicit Subroutine trigger which lets you specify the parameters by name, and whether the macro returns a value via the Return from Subroutine action. Such subroutines are called with the Execute a Subroutine action.
I would love to understand the added benefit of the subroutine added in version 10 of Keyboard Maestro. I have always just referenced another macro when I want things that I need to change in one location that is referenced by several other macros. Perhaps this has something to do with ascyrconous executions or something.
I've been thinking of subroutines like functions.
So, basically, now you can define something that looks like this python pseudocode:
def my_macro_name(param1, param2):
# Some functionality
return some_variable
Then, when you call the subroutine, Keyboard Maestro's GUI will show you little boxes where you can pass values in for param1 and param2 and assign the return value to a variable localized in the macro that calls the subroutine.
Here is a quick example from something I've been building. I'm passing two parameters from the macro I'm working in into a subroutine that calculates an index for me. I'm saving the calculated index to local_cycle_index for later use.
The benefits are that you don't have to save variables globally anymore to pass information back and forth between macros. Also, it is explicitly clear that one macro depends on another, so the structure of everything is much easier to follow.
Oh thank you for the example and I think that answers my question. I thought that Instance Variables allowed you to do this but I might be wrong.
I am really trying to wrap my brain around variables, triggers, subroutines, and arrays. I have been using them for years but mostly a surface level of understanding I am really trying to understand at a much deeper level now so I can be wiser in the macros I write.
The purpose of a Subroutine, compared to a normal macro, is two-fold.
First feature:
First, it lets you define the parameters that the macro needs in order to do whatever it does. You can actually think of subroutine parameters like the values you specify in typical actions. For example, consider this built-in action:
It requires an X position, and a Y position. Those are parameters.
Suppose you wrote a macro with a Subroutine trigger, like this:
When you call it as a Subroutine in another macro, you get this:
Very similar to an action with parameters.
Yes, you could pass parameters to macros using other methods, but Subroutines make it obvious what they need in order to operate.
Second feature:
You can return a result. Consider this built-in action:
It reads a file, and returns the result to your variable.
You could do the same with your own Subroutine (not that you need your own version of this - it's just an example):
And when you call the subroutine, it would look like this:
Theat's a start.
TBH, I'm not exactly sure what instance variables are used for either. The docs do suggest that an instance variable is available to sub-macros. However, I think that would make the macros difficult to maintain since you would have to keep variable names in sync between different macros to not break anything, and fully understand what macros could be modifying variables for debugging. For example, if a sub-macro mutates an instance variable then it is really difficult to understand or even know about that behavior from the main macro.
I think that explicitly passing information is much easier to understand and more robust. If I decide to rename or otherwise modify a local_ variable I know I don't have to worry about refactoring my sub-macros as well.
There are other nice things about subroutines. For example, KM will warn you if you have deleted a subroutine that is being used by other macros. Also, the GUI provides shortcuts to jump into and out of subroutines:
These sorts of features make subroutines very convenient.
1 Like
Do you have an example macro where some clarity would help you write it better? I think the best way to learn is by doing! That said, here is how I think of those different things:
Variables: This is how you stash information you will want to use later or more than once. For example, I might need to check a condition at the beginning of my macro, modify/change some values, and then have an if/then statement at the end of my macro to do different actions based on the condition I saved at the beginning. Alternatively, I might need to use the same information repeatedly in different steps, using a variable ensures I'm referencing the same info in all those different places.
Triggers: How will a macro start running? Will you use a keyboard shortcut, or will you have KM automatically run the macro for you? Triggers are what determine this.
Arrays: A special type of variable where you have multiple pieces of information that should live together but might need to be used individually. For example, you could have a simple array, separated by commas that looks like first_name,last_name. Sometimes you will want to use one name by itself, sometime you will want to use both together. Also, they really should be stored together because they both refer to the same person.
Subroutines: Make custom functions that you can pass information into and get a response back from.
1 Like
Yes, Instance variables can be used to pass information to a sub-macro, and you can return information in instance variables.
The reason I use Subroutines instead of macros and Instance variables is because a subroutine makes it clear what parameters it expects. Otherwise, you just sort-of have to know what Instance variables are expected.
But there's nothing technically wrong with using Instance variables instead of Subroutine parameters. And one advantage of Instance variables is you can return more than one result value, whereas the "Return from Subroutine" action only returns one value (although there's ways to work around that, but let's leave that for another time).
Subroutines with parameters is a typical pattern used in almost all programming languages. For those of us who are programmers, it's what we're used to.
With that said, Subroutines were only added recently and before that, we did indeed use Instance variables to pass values and receive results.
Full disclosure here: There's another advantage of using Instance variables instead of Subroutine parameters.
With Subroutine parameters, if you no longer need, say, the second of three parameters, you can't just delete it. If you do, then you may need to change every place the subroutine is called.
If you used Instance variables instead, the sub-macro could just start ignoring them. So even if macros that call the sub-marco put something in an Instance variable, the sub-macro can just ignore it if it no longer needs it.
Assuming, of course, that it doesn'f affect the overall logic somehow.
3 Likes
I kind of figured there were things like this happening. When I teach DAWs there are things that I have seen evolve eneough over the years it makes me a little sad how difficult some things are to learn to not have seen the evolution of things over the past 25 years which makes some things harder to learn but there are so many other headaches they have never had to deal with so I get over my sadness haha.
Thank you @gaufde for the explantation of each and how you think of them. I have been reading the Wiki but some things without having someone hold my hand and say here is a better way to do this I get stuck in probably not the most efficient ways of doing things. @DanThomas macros with step by step explanations have been super helpful.
Also I meant Tokens not triggers that was my bad, I am actually not quite that incompetent but close 
.
That's helpful and very cool.
Thank you for those two expamples with pictures. I look through a glass darkly (1 Corinthians 13:12) and am slowly starting to see. I will continue to keep an eye out for subroutines and see how people use these veruses just referencing Instance Variables. To this point I have hundreds of macros that I label as [Referenced Macro] that are called upon but several other macros. I am sure at one point my eyes will be opened and I will see so much clearer!
Thank you for all your help getting me there!
I get it. For me, I find I keep doing that which I don't want to do, and end up declaring " Oh what a wretched programmer am I". Or something like that. 
It'll happen.
As the others have said, you can -- but you have to know, and always use, those names. Subroutines are more of a "black box", you just provide parameters and receive the return without worrying about how the subroutine is implemented.
One (underrated, IMO) feature of subroutines is that you can use meaningful names in your subroutine and different meaningful names in your macros. A silly example would be a subroutine called "Product Of Two Numbers":
A macro doing things with rectangles can use it to get an area:
...while one doing invoices can use it for a line item total:
That may seem trivial -- but such "self-documentation" tricks can save a lot of head scratching when you revisit a macro!
One thing I don't think's been mentioned -- while you don't have to return a value from a subroutine, the subroutine must complete before the calling macro can proceed. Subroutines are always "synchronous". Compare that with "Execute a Macro", which can be "asynchronous", going and doing something else while the calling macro continues its execution.
If you really want to bend your brain -- there's nothing stopping you from having a synchronous subroutine that contains asynchronous "Execute a Macro" actions!
And DO NOT use "Cancel Just This Macro" inside the Subroutine. Always use a "Return from Subroutine" action, even if it returns nothing.
If you use "Cancel Just This Macro", it will actually cancel the calling macro.
Confused yet?
2 Likes