[JW Lua] Measure width in score changes when measure width in a part is changed after Undo/Redo - Workaround
Robert Patterson
robert at robertgpatterson.com
Thu Apr 4 16:51:56 CEST 2024
The problem is, it isn't just SetWidth. In fact, *anything* that changes
the width of the bar in the part causes the problem. This includes Finale's
built-in note spacing, whether executed by a plugin or the user. A reminder
on SetWidth is not a bad idea, but it is not the whole story.
On Thu, Apr 4, 2024 at 9:11 AM Jan Angermüller <jan at angermueller.com> wrote:
> >Jan, describe the direct support in RGP Lua you are imagining.
> Maybe a static RGP Lua function with the content below that one can add to
> the end of a Lua script?
>
> Then you don't have to add this function below to your own code.
>
> Finally, add a reminder to the SetWidth documentation. Something like:
> "When using SetWidth in linked parts, make sure to add the static ...
> function to the end of your Lua script.
> It will maintain the correct measure width in the score when calling undo
> and then redo after applying the plug-in."
>
> Jan
>
> Am 04.04.2024 um 13:47 schrieb Robert Patterson:
>
> ViewInDocument should not be necessary. (When I was working with your test
> case, I removed it to see if it made any difference: it did not.) In fact,
> ViewInDocument is a significant performance hit, and it may cause visual
> artifacts as well.
>
> Steve, I believe you have my plugins. I always make a copy of my score
> before beginning the parts layout. I can then copy the measure widths and
> spacing from my score copy back to the score using Mass Copy as needed. (I
> tend to need it.) But I am going to add Jan's workaround to the Note
> Spacing plugin, and that could possibly eliminate the need to do this,
> provided I always use the Note Spacing plugin for spacing (which I do).
>
> Jan, describe the direct support in RGP Lua you are imagining. I am not
> eager to add it to "SetWidth" on FCMeasure, because who knows what it might
> do in future Finale release. Plus, Jari seems to have kept the properties
> pretty clean as straight pass-thrus to PDK structs. (I have been a little
> lax in that, but mostly I try to follow the pattern.)
>
>
> On Thu, Apr 4, 2024 at 1:42 AM Jan Angermüller <jan at angermueller.com>
> wrote:
>
>> I can now confirm that the workaround seems to solve the measure width
>> undo/redo problem in Perfect Layout. I have also added the code to another
>> plug-in and it fixed the problem too.
>>
>> Probably it makes sense to add this code to all plug-ins that change the
>> measure width in parts.
>> Maybe it makes sense to even support this directly through RGP Lua?
>>
>> Below is the full code that I used.
>>
>> Robert, I was wondering about one thing:
>> according to my notes changing the FCMeasure object works best when the
>> part has the focus with part:ViewInDocument().
>> In a first attempt I had also added p:ViewInDocument() to my code below
>> when the plug-in was applied to the part only and the measure width had to
>> be corrected in the invisible score (see commented line below).
>> However, the workaround also worked fine when I removed ViewInDocument.
>> Is FCMeasure safe without ViewInDocument?
>> Or is it because of the Finale bug that this weird workaround even works
>> without ViewInDocument?
>>
>> Jan
>>
>>
>> -- add to the beginning of the code
>> local parts=finale.FCParts()
>> parts:LoadAll()
>> local NumParts=parts.Count
>> local part=finale.FCPart(finale.PARTID_CURRENT)
>> local CurrentPartIsScore=part:IsScore()
>>
>> function FixMeasureWidthInScore(region)
>> if NumParts>1 then
>> local p
>> if not CurrentPartIsScore then
>> p=finale.FCPart(0)
>> p:SwitchTo()
>> --p:ViewInDocument() --seems to be not necessary
>> end
>> if region==nil then
>> region=finale.FCMusicRegion()
>> region:SetFullDocument()
>> end
>> local i
>> for i=region.StartMeasure, region.EndMeasure do
>> local meas=finale.FCMeasure()
>> meas:Load(i)
>> meas.Width=meas.Width+1
>> meas:Save()
>> meas.Width=meas.Width-1
>> meas:Save()
>> end
>> if not CurrentPartIsScore then
>> p:SwitchBack()
>> --add code for ViewInDocument of original part -> but seems
>> to be not necessary
>> end
>> end
>> end
>>
>> ...
>>
>> FixMeasureWidthInScore(region) --add this line at the very end of the
>> script
>>
>>
>>
>>
>>
>>
>> Am 03.04.2024 um 16:34 schrieb Robert Patterson:
>>
>> I saw an additional issue, which is that the Undo does not undo the part
>> width setting. I found some notes about this in my Patterson Plugins code,
>> so the problem has been around a while.
>>
>> Glad you found a workaround.
>>
>> On Wed, Apr 3, 2024 at 9:29 AM Jan Angermüller <jan at angermueller.com>
>> wrote:
>>
>>> Thank you for the quick response, Robert!
>>> I found a workaround which at least works in the test case below:
>>> When I (re-)save the measure width in the score afterwards, it is still
>>> the same bug.
>>> BUT:
>>> When I slightly change the measure width in the score, save it, then
>>> restore the original value and save it again, both the measure width in the
>>> score and in the parts seem to have the correct value.
>>> It seems to set a flag in Finale that the measure width in the score has
>>> indeed changed.
>>>
>>> I will have to check if this also solves the problem in Perfect Layout.
>>>
>>> Here is the new test code with the additional lines in bold:
>>>
>>> --Show measure 1 width from score
>>> local meas=finale.FCMeasure(1)
>>> meas:Load(1)
>>> print("Measure Width in Score",meas.Width)
>>>
>>> --Load Part 3 and change
>>> local p=finale.FCPart(3)
>>> p:SwitchTo();
>>> p:ViewInDocument()
>>> meas=finale.FCMeasure(1)
>>> meas:Load(1)
>>> print("Measure Width in Part ",p.ID,meas.Width)
>>> meas.Width=360
>>> meas:Save()
>>> print("Measure Width after change",meas.Width)
>>> p:SwitchBack();
>>>
>>> --Go back to score and show measure 1 width
>>> p=finale.FCPart(0)
>>> p:ViewInDocument()
>>> meas=finale.FCMeasure(1)
>>> meas:Load(1)
>>>
>>>
>>>
>>> *meas.Width=meas.Width+1 meas:Save() meas.Width=meas.Width-1 meas:Save()*
>>> print("Measure Width in Score",meas.Width)
>>>
>>> Jan
>>>
>>>
>>>
>>> Am 03.04.2024 um 15:34 schrieb Robert Patterson:
>>>
>>> This is a bug in Finale. I doubt it will be fixed. But you could send it
>>> to them if you wish.
>>>
>>> On Wed, Apr 3, 2024 at 7:53 AM Jan Angermüller <jan at angermueller.com>
>>> wrote:
>>>
>>>> Robert,
>>>>
>>>> I have noticed several times that undo-ing and re-doing a JW Lua
>>>> plug-in can change the measure width.
>>>> Finally, I have created a short reproduceable demo that I can't explain.
>>>>
>>>> The script is below.
>>>> When applied to the score of the attached Finale file, it switches to
>>>> linked part 3, loads measure 1 and changes its measure width to 360 and
>>>> then returns to the score.
>>>> The measure width in the score remains unchanged. So far, everything ok.
>>>> Then I undo the plug-in in Finale and click on Edit->Redo ...
>>>> Now the width in measure 1 also changes in the score!
>>>>
>>>> Here is a video that shows the effect (with a slightly different
>>>> version of the score):
>>>> https://www.youtube.com/watch?v=lPJd3sq9zQg
>>>>
>>>> In Perfect Layout it makes Finale's Undo-/Redo feature unusuable,
>>>> because it (nearly) always changes the measure widths in the score for an
>>>> unknown reason.
>>>> Do you have an idea how I can prevent this?
>>>>
>>>> Jan
>>>>
>>>> --Show measure 1 width from score
>>>> local meas=finale.FCMeasure(1)
>>>> meas:Load(1)
>>>> print("Measure Width in Score",meas.Width)
>>>>
>>>> --Load Part 3 and change
>>>> local p=finale.FCPart(3)
>>>> p:SwitchTo();
>>>> p:ViewInDocument()
>>>> meas=finale.FCMeasure(1)
>>>> meas:Load(1)
>>>> print("Measure Width in Part ",p.ID,meas.Width)
>>>> meas.Width=360
>>>> meas:Save()
>>>> print("Measure Width after change",meas.Width)
>>>> p:SwitchBack();
>>>>
>>>> --Go back to score and show measure 1 width
>>>> p=finale.FCPart(0)
>>>> p:ViewInDocument()
>>>> meas=finale.FCMeasure(1)
>>>> meas:Load(1)
>>>> print("Measure Width in Score",meas.Width)
>>>> _______________________________________________
>>>> JWLua mailing list
>>>> JWLua at jwmusic.nu
>>>> http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu
>>>>
>>>
>>> _______________________________________________
>>> JWLua mailing listJWLua at jwmusic.nuhttp://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu
>>>
>>>
>>> --
>>> Jan Angermüller
>>> Orchideenstieg 13
>>> 22297 Hamburg
>>> Tel. 040 - 28 94 84 82
>>> Mobil 0173 - 99 33 904www.elbsound.studio
>>>
>>> _______________________________________________
>>> JWLua mailing list
>>> JWLua at jwmusic.nu
>>> http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu
>>>
>>
>> _______________________________________________
>> JWLua mailing listJWLua at jwmusic.nuhttp://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu
>>
>>
>> --
>> Jan Angermüller
>> Orchideenstieg 13
>> 22297 Hamburg
>> Tel. 040 - 28 94 84 82
>> Mobil 0173 - 99 33 904www.elbsound.studio
>>
>> _______________________________________________
>> JWLua mailing list
>> JWLua at jwmusic.nu
>> http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu
>>
>
> _______________________________________________
> JWLua mailing listJWLua at jwmusic.nuhttp://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu
>
>
> --
> Jan Angermüller
> Orchideenstieg 13
> 22297 Hamburg
> Tel. 040 - 28 94 84 82
> Mobil 0173 - 99 33 904www.elbsound.studio
>
> _______________________________________________
> JWLua mailing list
> JWLua at jwmusic.nu
> http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jwmusic.nu/pipermail/jwlua_jwmusic.nu/attachments/20240404/24a08d4d/attachment-0001.html>
More information about the JWLua
mailing list