[JW Lua] Weird accidental behaviour

Jan Angermüller jan at angermueller.com
Wed Jul 8 18:21:45 CEST 2020


Robert, thanks for your suggestions, but I still don't get it.
Is there a way to detect this behaviour automatically in JW Lua or not?
Your suggestion "Move one accidental" is a manual step - or did I 
misunderstand you?

I am looking for a way to automatically detect that this FCAccidentalMod 
behaves differently or that there is a hidden FCAccidentalMod. Both 
doesn't happen at the moment.
FCAccidentalMod:LoadAt always returns false here in my scripts (unless I 
do some manual steps as in my Youtube video).
So I don't get this hidden default value -54 EVPU automatically, but 
always 0 EVPU.
Manual steps are not possible here as this is part of my Perfect Layout 
plug-in.

In Perfect Layout there is a comprehensive accidental placement function 
which improves Finale's default placement of accidentals (e.g. move 
closer together in some cases, allow slightly overlapping if there is an 
accidental with parentheses, look at the shapes of the accidentals and 
see if this allows for better placement (double sharps need less 
vertical space than flats), etc.).
This works fine on all documents - except for this one.

Best,
Jan



Am 08.07.2020 um 15:57 schrieb Robert Patterson:
> I just tried running your script without modifications and it detected 
> the FCAccidentalMod just fine. Steps:
>
> 1. Open accidtest.musx
> 2. Open JW Lua and paste in your script.
> 3. Run it . (Nothing detected.)
> 4. Move one of the accidentals.
> 5. Run it. (Detected.)
>
> I then modified your script slightly to use a separate accmod2 for the 
> 2nd note. This works better. It looks like FCAccidentalMod doesn't 
> work quite right if you LoadAt for one note then reuse the same 
> instance to LoadAt another note.
>
> I'm wondering if your basic problem is that after saving the accimod 
> you are not setting the entry's note flag. (There is a function to do 
> this.) Generally speaking, you can find out what your code is not 
> doing by using the text dump plugin to compare a manual change in 
> Finale with your script's changes. If you make the exact same manual 
> change as you want from your script, you can find out any discrepancies.
>
>
> On Wed, Jul 8, 2020 at 8:31 AM Jan Angermüller <jan at angermueller.com 
> <mailto:jan at angermueller.com>> wrote:
>
>     Thanks a lot, Robert, for you super quick replies!
>
>     But can I detect this automatically in JW Lua? Maybe you use other
>     functions/flags in your plug-in?
>
>     When I run this JW Lua code, it always return false when trying to
>     load an accidental mod.
>     So I haven't been able to detect an existing accidental mod here.
>
>     for e in eachentry(finenv.Region()) do
>         if not e:IsRest() then
>             local accmod=finale.FCAccidentalMod()
>             accmod:SetNoteEntry(e)
>             local note=e:GetItemAt(0)
>             print(accmod:LoadAt(note))
>             print(accmod.HorizontalPos)
>             note=e:GetItemAt(1)
>             print(accmod:LoadAt(note))
>             print(accmod.HorizontalPos)
>         end
>     end
>
>     Best,
>     Jan
>
>
>
>     Am 08.07.2020 um 15:21 schrieb Robert Patterson:
>>     This is a perfect use case for the Enigma Text Dump plugin I sent
>>     out a couple of days ago.
>>
>>     1. Dump your accidtest.musx file using the plugin.
>>     2. Nudge an accidental right then left, so its position is unchanged.
>>     3. Dump the file again using the plugin.
>>     4. Compare.
>>
>>     I just did it, to make sure it works, but I already knew the
>>     answer. This behavior of accidentals had a subtle change around
>>     2000. I don't remember the exact date. If the handle is on the
>>     left, it means there is no FCAccidentalMod detail for that note.
>>     If it is on the right, it means there is.
>>
>>     You can use the same process as above to determine what your
>>     offsets need to be.
>>
>>     1. Dump your original accidtest.musx file using the plugin.
>>     2. Place the accidental where you want it to be.
>>     3. Dump the file again using the plugin.
>>     4. Compare
>>
>>     I hope this helps.
>>
>>
>>
>>     On Wed, Jul 8, 2020 at 8:05 AM Jan Angermüller
>>     <jan at angermueller.com <mailto:jan at angermueller.com>> wrote:
>>
>>         Jari et al.,
>>
>>         here is a weird accidental movement behaviour.
>>
>>         When I use the Accidental Mover tool (or FCAccidentalMod ->
>>         HorizontalPos) and change the horizontal position to a new
>>         value, the accidental jumps onto the notehead (!) and takes
>>         the notehead as a new reference position.
>>         This Finale document was created with Fin2002a.
>>         The normal behaviour is that the change of the horizontal
>>         position keeps the reference position (i.e. far before the
>>         notehead) and moves only according to the new value.
>>
>>         See this video:
>>         First the weird behaviour, then the normal behaviour (in the
>>         Fin2014 default document):
>>         https://www.youtube.com/watch?v=wRLsU40Kog8
>>
>>         While making this video I also noticed, that sometimes the
>>         anchor point changed (!).
>>         So maybe there used to be a flag in Finale (<=2002) which
>>         changed the alignment point of the accidental.
>>         Have a look at the 23. second in this video: I click on the
>>         anchor point and it suddenly jumps from the right of the
>>         accidental to the left of the accidental.
>>         https://www.youtube.com/watch?v=6EjOfAlhwMM#t=20s
>>         When the anchor point jumps (but this only happens very
>>         seldom, and I can't reproduce it) and I check the
>>         FCAccidentalMod it suddenly returns a -54 EVPU value for
>>         HorizontalPos. While by default (when the anchor point hasn't
>>         jump before) it returns no existing accidental mod and thus a
>>         0 EVPU value.
>>
>>         I haven't found a way to detect or to remove this behaviour
>>         yet. Probably it's not even possible.
>>         Attached is the document with the measure from the video
>>         where this weird thing happens.
>>
>>         Any ideas?
>>         The only thing that came to mind: it was created with Fin2002a.
>>         Maybe this was a bug in Fin2002a which they fixed in 2002b?
>>         Or this was something available before 2002, but not
>>         supported anymore.
>>
>>         Best,
>>         Jan
>>         _______________________________________________
>>         JWLua mailing list
>>         JWLua at jwmusic.nu <mailto:JWLua at jwmusic.nu>
>>         http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu
>>
>>
>>     _______________________________________________
>>     JWLua mailing list
>>     JWLua at jwmusic.nu  <mailto:JWLua at jwmusic.nu>
>>     http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu
>
>     -- 
>     Jan Angermüller
>     Dipl.-Ing.(FH) Dipl.-Jur.
>     Orchideenstieg 13
>     22297 Hamburg
>     Tel. 040 - 28 94 84 82
>     Mobil 0173 - 99 33 904
>     www.elbsound.studio  <http://www.elbsound.studio>
>
>     _______________________________________________
>     JWLua mailing list
>     JWLua at jwmusic.nu <mailto:JWLua at jwmusic.nu>
>     http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu
>
>
> _______________________________________________
> JWLua mailing list
> JWLua at jwmusic.nu
> http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu

-- 
Jan Angermüller
Dipl.-Ing.(FH) Dipl.-Jur.
Orchideenstieg 13
22297 Hamburg
Tel. 040 - 28 94 84 82
Mobil 0173 - 99 33 904
www.elbsound.studio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jwmusic.nu/pipermail/jwlua_jwmusic.nu/attachments/20200708/80310afc/attachment.html>


More information about the JWLua mailing list