Update notes_cross_staff.lua

[cv-on-hub]

Having conclusively failed to solve accurate beam-height adjustment, have revised this script extensively: introduced Modeless option (though the track selection confirmation seemed unnecessary); simplified and improved core cross-staff routine including the cleaning of note settings; greatly improved dialog layout and visual separation of horizontal-shifting utility; added invisible rest option; removed reverse-stem but no shifting option; inverted logic of other checkbox items; added cross x notes out of y option; consequently simplified the main() calling routine; updated documentation.

[rpatters1]

What proved to be the final straw on autopositioning?

FWIW: I found autopositioning of beams to be quite a challenge without considering cross-staff, so I'm not say your assessment is wrong.

[cv-on-hub]

What proved to be the final straw on autopositioning?

Changing beam angle has to be the last element in the chain, after freezing and reversing stems. (Otherwise you can't gauge the default, "real" beam height with freeze/reverse in effect to make suitable adjustments). So RebuildMetrics after the freeze is vital, but then Rebuilding again after stem reversal, which also seems crucial, would only work if the first member of the group was not crossing staves.

I tried a million different variations of order and options, with and without MetricRebuilding. Sometimes Rebuilding provided "correct" measurements of "default" beam angle, sometimes not. Sometimes you need to avoid Rebuilding so that beam angle remained adjustable. And in some circumstances a weird hybrid BeamMod ("devil" beam) was created that was readable in Lua but seemingly invisible to Finale's beam positioning. (i.e. the beam vertical offset set by Lua would "read" in Lua while Finale's manual beam adjustment would give a different value - both in evidence but only the manual one affecting actual beam on-screen position).

I could find a combination of options that would work with "first-member-of-beam-group" crossing staves but then that combination would break some other combination that worked when it wasn't. But I think the final nail-in-coffin was the devil beam, that led to my ultimate conclusion that there's something not linking correctly between reverse/frozen stems, beam mods and what seems to be some other stem/beam adjustments that aren't accessible to Lua. Maybe!

BTW: once a devil beam was created it would persist outside the current script, and required a "delete all beam/note alteration" action to set it back to a normally adjustable note entry. Consistently listing every available Property of beam/stem/entry failed to show any parameter to account for that behaviour. (Thankyou for dumpproperties()!)

[rpatters1]

I think you could save a lot of time if you would learn to use my Enigma Text Dump plugin to do A/B comparisons of what you want to achieve in the script vs. what happens when you do it manually with the Finale UI. That said, for automatic beam editing I'm guessing you'll need to freeze the leading stem(s) in one direction or the other, then rebuild metrics, then do whatever you need to do. That seems like it would provide the most consistent results and not require such mucking around with building/rebuilding etc. It might be necessary also to do the reverse stems in a second pass.

[cv-on-hub]

I'm sure you're right about Enigma Text Dump. Will examine. A second rebuild is absolutely required to get an accurate read on beam placement after stem reversal. The closest I got was with four or five "passes" through the material: (1) freeze stems within user selection then rebuild; (2) scan whole measure to track start/end of every affected beam group, reverse stems, rebuild; (3) cross staff, optional (but probably critical) rebuild; (4) calculate stem adjustment using metrics of "real" new beam position.

In some scenarios only three passes were needed, but crossing the first note in beam groups remained the stumbling block. In some scenarios combining (2) and (3) would work, others not. It was ultimately the most frustrating thing I've ever done in Fin/Lua and I think my interest in flogging that particular horse is now dead.

[rpatters1]

All of these problems are caused because you can't explicitly specify which direction of stem you want to create the FCBeamMod for. I'll look into adding that in the next release.

[cv-on-hub]

specify which direction of stem you want to create the FCBeamMod for

That finally explains why Lua would read (and retain) a different LeftVertical value on BeamMods than Finale uses for beam display. The devil, as usual, in the detail.

[cv-on-hub]

@rpatters1: hoping that you get notifications from closed PRs!

You probably know all this but I thought I'd share anyway. EnigmaDump reveals, as you suggested, that changing beam LeftVertical on an entry at the start of a beam crossing staves UPWARDS (and with stem frozen up) produces FCBeamMod[primary downstem] on that entry. Same conditions with stem reversed (still with stem frozen up) produces FCBeamMod[primary upstem].

[rpatters1]

Sometimes the mystery of Finale is a mystery. One must accept what is. I've added the ability to specify the one you wish to apply in 0.74. (In fact, it is possible to add both, and depending on context Finale uses one or the other, e.g., transposed part vs. C score.)