[JW Lua] Weird accidental behaviour

[Robert Patterson]

No, I found the issue. (See my other message.)

On Wed, Jul 8, 2020 at 12:39 PM Jan Angermüller <jan at angermueller.com>
wrote:

> 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>
> 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
>> http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu
>>
>
> _______________________________________________
> JWLua mailing listJWLua at jwmusic.nuhttp://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 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/20200708/dd07b494/attachment.htm>