[JW Lua] SMuFL constants in JW Lua

[Thomas Weber]

Dear Jari,

incidentally, I've put implementing SMuFL handling on my issue tracker two days ago.  Great you're bringing this up here for discussion.  I hope the following somewhat long winded suggestions make sense to you.

I'd suggest avoiding "global" constants (by which I mean constants in the finale.* namespace).  To me, it feels more Lua-ish to put them into a separate table that only contains constants of one type.  Recently, I created a dropdown list of all available smart shape types.  I copied them from the PDK documentation.  It would have been more elegant if the constants were stored in a dedicated table, e.g. finale.smartshapes with keys SLURDOWN, SLURUP etc.  This way, all available smart shape types would be easily iteratable.  If more became available in a newer version of Finale/JW Lua, the the script could automatically list them in the table without any manual update.  (One could also filter all keys in the finale.* namespace for prefix "SMARTSHAPE_", but why do it hackishly if one could do it elegantly?)

I understand those "global" constants are so to say inherited from C++, but as you're explicitly saying you'd like to include SMuFL support in JW Lua, I'd suggest doing it the Lua way.

SMuFL is a moving target and most fonts in use are non-SMuFL legacy fonts where simple constants won't work because SMuFL's name to codepoint mapping obviously would lead to wrong results.  What I had in mind is functionality that can parse SMuFL metadata files in JSON format (JSON parsing/writing modules for Lua are available).  I see some advantages here:


1) JW Lua doesn't have to be updated with every new SMuFL version.  The user can just download the new glyphnames.json and put it in the right place.

2) For non-SMuFL legacy fonts, glyphnames.json files can be created following the same scheme, but with non-standard codepoints.  E.g. the glyphnames.json file for Opus Special Std would have an entry

    "tremolo1": {
        "codepoint": "U+01C7"
    }

wich in SMuFL terms is wrong, but it would allow us to use SMuFL names for non-SMuFL fonts.  Maybe users can contribute to a collection of metadata.json files for different fonts that could be made available on the JW Lua page.

3) Imagine a distant future where SMuFL becomes a Unicode standard and all glyphs are moved from the private use area to proper codepoints.  Just update glyphnames.json and Bob's your uncle.


How could this be organized so that the SMuFL handler can find the data?  My plan was to create a fontinfo folder with sub-folders named after the fonts.  E.g. a folder "fontinfo/Opus Special Std" with a file "fontinfo/Opus Special Std/glyphnames.json".  (The metadata.json files with info about bounding boxes could be provided as well, which would slightly mitigate the problem with not being able to center articulations because the metrics are unknown.)

Here's some dummy code that could be implemented as a standalone module without even having to modify core JW Lua.


  local smufl = require "lib.smufl"

  for entry in eachentry(finenv.Region()) do
    local articulations = entry:createArticulations()
    for articulation in each(articulations) do
      if smufl.getGlyphName(articulation) == "articAccentStaccatoAbove" then
        -- do something
      end
    end
  end


I'd almost suggest moving functionality like this out of the core jwlua.fxt file into standalone Lua modules.  Like this, the restrictions you mentioned concerning the core code won't apply and people could actively contribute.  You're already supplying the Scintilla DLL as a separate file - more resources could be supplied in the form of Lua code (and in the case of SMuFL also JSON data).

By the way, I think with some metatable magic, one should in theory be able to create Lua modules that add functionality directly to the native classes.  However, I can crash Finale with the following script:


    local articulation = finale.FCArticulation()
    local articulationMetatable = getmetatable(articulation)
    local old__index = articulationMetatable.__index
    articulationMetatable.__index = setmetatable({
        someCustomProperty = "foo"
    },{
        __index = old__index
    })

    print(articulation.someCustomProperty)
    print(articulation.ID)


I guess ideally, a Lua script shouldn't be able to crash the entire application.


So, 'nough said.  Hope this is constructive.
Thomas Weber



Am 22.08.2015 um 12:40 schrieb Jari Williamsson:
> Hello All!
>
> I'm planning to include SMuFL support in JW Lua on multiple levels, since that's clearly where Finale and music notation are heading right now. On the most generic level, I want to add the SMuFL symbol constants and use them as mapping for musical characters (even for the old legacy fonts), so the scripts becomes easier to maintain. Scripts will then be able to reference a symbol constant instead of just a slot number for a font.
>
> My question to you is how the SMuFL symbols should be mapped to JW Lua constants:
>
> For example, the "4-string tab clef" glyph has the SMuFL symbol name "4stringTabClef". How would you like this to be represented in JW Lua:
> * finale.SMUFLSYM_4stringTabClef
> or
> * finale.SMUFLSYM_4STRINGTABCLEF
> or
> * finale.SMUFLSYM_4STRING_TAB_CLEF
>
> Personally, I can see the usefulness of using an exception to the all-upper-case rule here (and use the "finale.SMUFLSYM_4stringTabClef" naming convention), since that would make it easy to use the SMuFL documentation directly.
>
> What are your thoughts?
>
>
> Best regards,
>
> Jari Williamsson
>
>
> _______________________________________________
> JWLua mailing list
> JWLua at jwmusic.nu
> http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu
>
>