[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.htm>
More information about the JWLua
mailing list