[JW Lua] Weird accidental behaviour

Jan Angermüller jan at angermueller.com
Wed Jul 8 19:37:34 CEST 2020


The file was originally created in Finale 2002a according to the file 
info (in Fin2014 it says 2002a.r1, in Fin26 it says 2002.1.1). I 
received a Finale 2014d imported version of the document from my client.

Thanks for your note detail flag suggestion. Yes, I had already tried it 
this morning, because I also noticed that the flag is not set. But 
without success. Even if I set the note detail flag it won't detect the 
(hidden) FCAccidentalMod.

 >Maybe the difference is that I am using F26.3 (Mac) to import the 
file, because I am seeing correct behavior from >LoadAt.
You mean you get a LoadAt() == true and a horizontal pos -54 EVPU 
directly after opening the file?
I only tested on Fin2014 and Fin26.2 (both MacOS and Windows), but both 
times it returned false and 0 EVPU.
I doubt that they would have fixed this in 26.3? Or have they?

To make sure that we are not at cross purposes, here is again a video of 
Finale 26.2 with the behaviour.
https://youtu.be/G7E9j9FGbI0
There you see that it returns false, and that changing the value from 0 
to 1 makes a 55 EVPU jump instead of a 1 EVPU jump.

Jan




Am 08.07.2020 um 19:05 schrieb Robert Patterson:
> Maybe the difference is that I am using F26.3 (Mac) to import the 
> file, because I am seeing correct behavior from LoadAt. But clearly 
> this is *not* a F02 file because it has a .musx extension. If you want 
> to send the original .mus I will be happy to try it.
>
> That said, the thing I would check before anything else is the note 
> detail flag on that entry. (You can check it with...the enigma text 
> dump plugin!) Loss of entry bits is common. Finale itself tends to 
> ignore them, but I notice the PDK Framework does not. (You can 
> download the PDK Framework source code for yourself at Jari's website. 
> It's a very old version, but LoadAt is in there.)
>
> So the first thing I would do to repair the file is set the note entry 
> bit and then see if LoadAt starts behaving properly again.
>
>
> On Wed, Jul 8, 2020 at 11:51 AM Jan Angermüller <jan at angermueller.com 
> <mailto:jan at angermueller.com>> wrote:
>
>     It doesn't work with the Finale test file from the first email (I
>     have attached it again).
>     That one was created with Finale 2002a and probably is not
>     compatible with current Finale versions.
>     See my two screenshot videos with these weird behaviours in the
>     first email.
>
>     1.) This file returns false with LoadAt.
>     2.) But it actually seems to have a hidden value -54 EVPU (which
>     can be seen in the Youtube videos)
>     3.) Through manual movement I can reproduce this -54 EVPU value.
>     4.) The anchor point of the accidental suddenly jumps when I click
>     it -> see video. It seems that the hidden FCAccidentalMod used in
>     this document had a different alignment option which is not
>     available in Finale anymore and causes this weird behaviour  (as
>     you said and as I guessed it probably has to do with a deprecated
>     Finale option which is not correctly imported into Finale 2014)
>     5.) But I cannot get this value automatically: i.e. when I load
>     the accidtest.musx document and run the script immediately, it
>     will always return 0 EVPU and not -54 EVPU. So the FCAccidentalMod
>     seems to be somehow hidden.
>     -> That's what my question is about.
>
>     As I said my Perfect Layout accidental placement script normally
>     works. This is the first document where the automatic
>     FCAccidentalMod reading doesn't work. The code snippet that I
>     posted is just for testing purposes. The Perfect Layout script is
>     much more complex, but it's not relevant here.
>
>     What I want is:
>     - Read the current horizontal position of the accidental (usually
>     0 EVPU as there is usually no FCAccidentalMod, if there is an
>     FCAccidentalMod read this value). He
>     - Change the current position by adding a small value (e.g. 10 EVPU)
>     - Accidtest returns the wrong horizontal position by default
>
>     If I add a value to this accidtest.musx document, it moves the
>     accidental to the wrong position.
>     Because 0 EVPU (which usually is the position before the notehead)
>     is in this case the wrong reference position.
>     When I save an accidental mod with HorizontalPos=1 EVPU to this
>     accidtest, it moves the accidental by 55 EVPU and not by 1 EVPU.
>
>     Jan
>
>
>
>
>
>
>     Am 08.07.2020 um 18:33 schrieb Robert Patterson:
>>     With your script, running on your file, FCAccidentalMod:LoadAt
>>     returns true if there is an acci mod and false if there isn't
>>     one. What's the issue?
>>
>>     If the question is, "where did that -54 come from?", the answer
>>     is Finale calculated it and put it there. I wouldn't worry about
>>     where it came from. Instead, I would set the value you want and
>>     save it. Don't forget to set the note detail flag on FCNoteEntry.
>>
>>     If you are not seeing the results you think you should see after
>>     running your script, use my plugin to compare the changes made by
>>     your script to those identical changes done manually. That will
>>     show you what your script is lacking.
>
>     _______________________________________________
>     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/3580bc92/attachment.html>


More information about the JWLua mailing list