[JW Lua] Weird accidental behaviour

[Robert Patterson]

P.P.S. By "compare" I mean use a grep tool. I use KDiff3.

On Wed, Jul 8, 2020 at 8:23 AM Robert Patterson <robert at robertgpatterson.com>
wrote:

> P.S. You'll have to infer which is the horizontal offset position. I'm
> pretty sure it's the 2nd-to-last number.
>
> On Wed, Jul 8, 2020 at 8:21 AM Robert Patterson <
> robert at robertgpatterson.com> wrote:
>
>> 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>
>> 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
>>> 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/b42a7182/attachment-0001.html>