With something like hiding stems (which I used in the GIF above mainly for it being an immediately tangible example), the benefits are not glaringly obvious. One advantage about this particular type of edit that I can see (putting aside, for the sake of simplicity, your filtering operation) is that you might have times where you want to return to Write Mode, and other times where you do not want that. With the classical approach, you can have two different scripts, one including the mode changes, and one not including them, but still, you will have to go to some extra lengths in your JSON hacking to make them apply at the right time. But with ConsoleTools, you can have a simple “Hide stems” tool, set up from the command string, like so:
addTool("Hide stems in EM",[[UI.InvokePropertyChangeValue?Type=kNoteHideStem&Value=true]],"hideStemsEM")
… and you can have another tool for the same thing from Write Mode, by simply hooking in the existing tool:
addTool("Hide stems in WM",{(fromLuaLibrary("switchBetweenTwoModes",,"_nl._lib.window.lua")),3,2,{"hideStemsEM"}},"hideStemsWM")
Then, instead of having these tools on fixed keycommands (although you can do that too with ConsoleTools), you load the appropriate tool ad hoc onto a tool slot of your choice.
As with the ConsoleTools framework itself, I tried to set up things in a way that allow for a variety of ways to use tools – that element of abstraction keeps thing nicely malleable, but also puts me in a tough spot when trying to point out what you can do with it. You can do a lot of cool things with it, which hopefully will be useful to a lot of users, but laying those things out comprehensively (including the different approaches that may be available to do the same task) is a bit Sisyphean.
But let’s consider this (still somewhat artificial) scenario, which also highlights a bit the general flexibility of ConsoleTools:
First of all, let’s assume that the “switchBetweenTwoModes” tool from the library is part of the user’s tool collection, with their tool setup file including this line:
addTool("Mode>...>Mode",{(fromLuaLibrary("switchBetweenTwoModes","_nl._lib.window.lua"))},"_sw2m")
Now that user is working (predominantly in Write Mode) on a score that contains a lot of glissando notations. They realise that they are coming across many cases where the start offset of a glissando line needs a bit of an adjustment, but the needed amount varies slightly from case to case. Since our imaginary user is somewhat savvy with Dorico’s macro recording, they know how to get to the appropriate command string, so they could make their life easier with some custom scripts. But still, they would need a single script for each needed offset value (including the mode switches), and if they wanted those available via keycommands, they would have to dive into their keycommands.json, which is probably the point at which they would decide that it’s not worth the effort.
But with the tool from the line above, after having figured out what the command string looks like, they just have to enter this into the console:
set(1,"_sw2m",{3,2,[[UI.InvokePropertyChangeValue?Type=kGlissandoLineStartDX&Value=string: "1/2"]]})
set(2,"_sw2m",{3,2,[[UI.InvokePropertyChangeValue?Type=kGlissandoLineStartDX&Value=string: "2/2"]]})
set(3,"_sw2m",{3,2,[[UI.InvokePropertyChangeValue?Type=kGlissandoLineStartDX&Value=string: "3/2"]]})
… and they would immediately have three different offsets at their fingertips (i.e., available on their first three ConsoleTools tool slots), with the mode switches handled automatically.
For anything other than mere one-off use, there are more elegant ways to set up something like this in ConsoleTools, which I won’t get into here, but hopefully this gives an impression of how the hooking functionality can be useful.
One thing that looking at your script brings to mind is that I probably should also allow for multiple hooks, so that one could set up a filter operation, like you did. I do believe that this kind of functionality should already be in there, it’s just not exposed; I’ll look into it and maybe update the library. Be that as it may (and coming full circle to the topic of ConsoleTools’s versatility), you could probably already build up something equivalent in various ways with the currently available functionality, for example by incorporating the Filter library, which allows for filtering from Engrave Mode.
