Property Panel not Updating During Script Execution

In the automation of some mundane tasks pertinent to plainsong engraving, I scripted two steps that I have to do hundreds of times in my current project—hiding stems, and forcing slurs to be “up”. Before I explain the issue, here are the script steps that seem like they should work:

Edit.SelectAll
Filter.NotesAndChords
Window.SwitchMode?WindowMode=kEngraveMode
UI.InvokePropertyChangeValue?Type=kNoteHideStem&Value=string: "true"
Window.SwitchMode?WindowMode=kWriteMode
Edit.SelectAll
Filter.Slurs
UI.InvokePropertyChangeValue?Type=kSlurForcedDirection&Value=string: "kUp"

I always run this script right after entering notes and slurs, so I didn’t include an initial change to Write mode to enable Filtering. As it is shown above, the final command never is able to affect a change, as after the Filter.Slurs command runs, the property panel is still showing the options pertinent to the earlier Filter.NotesAndChords command. The kSlurForcedDirection is a UI command, and seems to be quite dependent on that option being visible in the UI at execution.

Is it an expected outcome for the properties panel to not update after the Filter.Slurs command? The kSlurForcedDirection option appears in both Write and Engrave mode, so the current mode (Engrave) shouldn’t affect what properties are displayed. If I follow these steps exactly (verified by following the application.log in the Console) by hand, the properties panel updates to show the pertinent options for slurs.

To get my script to work, I had to include a toggle to Write Mode and then back to Engrave Mode to get the panel to update right after I filter for slurs—at which point the final command works. So, on the one hand—yes, it works—but, I would prefer to avoid the flashing if possible, and do like my scripts to be as concise as possible. I look forward to a future version of scripting where setting such parameters might not require a control to be visible on screen—but am thrilled that so much is already available for automation. The very clear commands available to us now show that there was obviously a lot of thought given to this from the very beginning.

Any insights are quite welcome. All the best.

3 Likes

Marc, first of all, I’m interested in your project; I just realize we both also haunt another forum and you mentioned that you did the engraving for the Misal Romano! Very cool.

As for this thread, everything you’ve posted above seems to make sense… one question though: have you tried isolating just the last two steps to see if those commands function properly in isolation (ie- apart from the preceding chain of commands)?

1 Like

In isolation, the two halfs of the script work.

This project is for the same publisher.

Well, I tried to reenact your steps manually, to see what the application log would show, but for the life of me, I cannot find this file on my mac. It’s not the same as in @dan_kreider 's excellent video for windows, so I’m at a loss.

Any mac friends able to point me in the right direction? I went to /Library/Application Support/Steinberg/Dorico 4 and this last folder is empty, even when I have an option to display invisibles…

It’s in your home library… ~/Library/…

I tried this. Unless it would be in a different folder than “application support”

You didn’t write “~” before /Library/ in your post, so I want to be sure you’re going to the /Library/ in your home folder, not the one at the top level of the drive. The home one is hidden by default, so hold down Option and choose Go > Library.

Rather than opening and searching the application.log, I have had some small success just recording a macro and opening the resulting file (in the /⁨Script Plug-ins⁩/ folder).


As for the OP’s issue, I am guessing Dorico needs some sort of pause or refresh line of code so that Properties gets updated. No idea what that syntax might be.

1 Like

I think so? I should have put MacintoshHD/Library

addendum: I see what you’re talking about now. Found the folders. Thank you!

1 Like

Marc, I notice when I look at my logs that there are “notifypostcommand” strings. I wonder if adding one of these is necessary?

[info] Executing command: Edit.SelectAll
[info] notifyPostCommandExecute: Edit.SelectAll (148 ms)
[info] Executing command: Filter.Slurs
[info] notifyPostCommandExecute: Filter.Slurs (121 ms)
[info] Posting command (requested): UI.InvokePropertyChangeValue Type=kSlurForcedDirection, Value=string: "kUp", Post=true
[info] Executing command: UI.InvokePropertyChangeValue?Type=kSlurForcedDirection&Value=string: "kUp"
[info] notifyPostCommandExecute: UI.InvokePropertyChangeValue?Type=kSlurForcedDirection&Value=string: "kUp" (64 ms)

Perhaps Dorico is executing the string so fast that the panel isn’t being notified prior to executing the next line?

I haven’t had a chance to look at this yet, but I can say that you as a user can’t tell Dorico to handle notifications after running a command, so that’s not any kind of solution.

2 Likes