Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use neume names instead of font's chars #4

Open
7 of 16 tasks
anaskaejdar opened this issue Apr 30, 2020 · 4 comments
Open
7 of 16 tasks

Use neume names instead of font's chars #4

anaskaejdar opened this issue Apr 30, 2020 · 4 comments

Comments

@anaskaejdar
Copy link
Collaborator

anaskaejdar commented Apr 30, 2020

This will make Kassia BNML files much more human-readable and human-writable, and will also provide the amount of abstraction necessary to be able to incorporate other people's fonts, which aren't structured the same way that Kassia's own fonts are.

PHASE 0: Starting point
  • Finalize KA New Stathis so we have a stable starting point
    • Consider using "Byzantine Musical Symbols" Unicode block
PHASE 1: Implement the shorthand
  • Create abstractneume class
  • Replace the chars in neume_dict.py with the shorthand neume names
  • Translation layer to convert shorthand abstract neumes into font's chars
    • Read a font's fontconfig.yaml file for char assignments
    • For every neume, replace it with its char counterpart and rebuild the neumes_list
PHASE 2: KA New Stathis-based char shorthand
  • Translation layer to convert KA New Stathis chars to shorthand abstract neumes
PHASE 3: Proper syntax
  • Translation layer to convert shorthand abstract neumes into proper abstract neumes
    • For everything in the shorthand form, translate to proper
    • For everything in proper, translate to proper+positioning info
  • Translation layer from proper abstract to concrete (font chars)
    • Read fontconfig.yaml for char assignments
    • For every neume combination, substitute it with the chars specified in fontconfig (if the given combination is defined therein)
    • For every neume, replace it with the chars specified in fontconfig
    • Create a stacking engine to spatially-align combinations that weren't defined in fontconfig
@anaskaejdar
Copy link
Collaborator Author

Is phase 2 necessary if we're breaking backwards compatibility anyway?

@ilizol
Copy link
Collaborator

ilizol commented May 5, 2020

Is phase 2 necessary if we're breaking backwards compatibility anyway?

This will be helpful only for someone, I suppose @t-bullock, who has written many scores with the old format.

@anaskaejdar
Copy link
Collaborator Author

We're already going to break compatibility with existing scores once we implement issue #2 .

@t-bullock
Copy link
Owner

I don't think it's necessary, as long as we keep development in a separate branch for a while. I could always write a little script to convert old scores.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants