<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Thanks for the info, Jari!<br>
    <br>
    <div class="moz-cite-prefix">Am 19.03.2017 um 16:12 schrieb Jari
      Williamsson:<br>
    </div>
    <blockquote
      cite="mid:0d4df08c-6f06-f106-f96a-e1b8c01013e1@mailbox.swipnet.se"
      type="cite">Jan,
      <br>
      <br>
      The JW Lua scripts should be expected to work the same, from the
      script developers POV.
      <br>
      <br>
      I try to keep the same Lua version (5.2.3) on both 32 and 64-bit.
      That seems to work.
      <br>
      <br>
      There's a bit of a struggle on the Mac side to get all 3rd part
      open source components to work together in 64-bit, but I hope to
      solve those issues without workarounds.
      <br>
      <br>
      Internally, the Finale PDK has been pretty good on specifying the
      exact bit widths for data, so Finale data should generally be
      compatible.
      <br>
      <br>
      The exception seems to be that 64-bit Finale seems to have dropped
      support for non-Unicode PDK API data (earlier there were both
      8-bit and UTF16 versions). I think that's the cause to the issue
      that you reported about the font names not being correctly
      reported in FCFontInfo etc. I need to find all those occurences.
      <br>
      <br>
      <br>
      Best regards,
      <br>
      <br>
      Jari Williamsson
      <br>
      <br>
      On 2017-03-19 12:58, Jan Angermüller wrote:
      <br>
      <blockquote type="cite">Hi Jari,
        <br>
        <br>
        are there any things we need to be aware of when running the
        "old"
        <br>
        plugins in 64bit?
        <br>
        Any known bit incompatibilites or other hard-coded values that
        have
        <br>
        changed ?
        <br>
        <br>
        I noticed for example that the old "full measure pos right"
        value
        <br>
        (->FCMusicRegion:SetEndMeasurePosRight()) is still the max
        32bit signed
        <br>
        value 2147483647. And the "bit32."-functions also still seem to
        work.
        <br>
        This looks like great backwards compatibility!
        <br>
        <br>
        Best,
        <br>
        Jan
        <br>
        <br>
        <br>
        <br>
        _______________________________________________
        <br>
        JWLua mailing list
        <br>
        <a class="moz-txt-link-abbreviated" href="mailto:JWLua@jwmusic.nu">JWLua@jwmusic.nu</a>
        <br>
        <a class="moz-txt-link-freetext" href="http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu">http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu</a>
        <br>
        <br>
      </blockquote>
      <br>
      <br>
      <br>
      _______________________________________________
      <br>
      JWLua mailing list
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:JWLua@jwmusic.nu">JWLua@jwmusic.nu</a>
      <br>
      <a class="moz-txt-link-freetext" href="http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu">http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu</a>
      <br>
      <br>
    </blockquote>
    <br>
  </body>
</html>