Re: GSoC 2020 update: (hopefully) final commits made; testing time

[Werner LEMBERG]

 
> Here's another stab at glyphnames.json.txt, given all this new information:
> 
>   glyphnames.json is a part of the Standard Music Font Layout
>   (SMuFL) specification, version 1.3.  It was retrieved from
>   https://github.com/w3c/smufl on 29 Aug 2020, and is licensed under
>   the W3C Final Specification Agreement, found at
>   https://www.w3.org/community/about/process/final/.
> 
> What do you think?

Again, this looks fine :-)


Werner

Re: GSoC 2020 update: (hopefully) final commits made; testing time

[Owen Lamb]

On Sat, Aug 29, 2020 at 3:09 AM Werner LEMBERG  wrote:

>
> > So, glyphnames.json.txt would look like this?
> >
> >   glyphnames.json, created by Daniel Spreadbury, was retrieved from
> >   https://github.com/w3c/smufl on DD Mon . It is licensed under
> >   the W3C Community Contributor License Agreement and the W3C Final
> >   Specification Agreement.
>
> Looks good, yes.
>

A couple more things. While it does appear likely--based on git
history--that Daniel Spreadbury created this particular file, he has not
placed a particular copyright on it. The specification as a whole, on the
other hand, is copyright "the Contributors to the Standard Music Font
Layout Specification" (see
https://w3c.github.io/smufl/gitbook/preamble/license.html).

On top of that, the W3C Final Specification Agreement (FSA) at
https://www.w3.org/community/about/process/final/, section 2, seems to say
that an author attribution is unnecessary, only requiring we mention the
standard's name and version (i.e. Standard Music Font Layout version 1.3).
My legalese isn't that great, though, so I'd appreciate a second pair of
eyes to make sure.

> It seems that the SMuFL specification (including its helper files)
> > are under two licenses which complement each other, the W3C
> > Community Contributor License Agreement and the W3C Final
> > Specification Agreement.  I don't quite understand their
> > relationship to each other, though.  Does only one need to be
> > mentioned, or both?
>
> You should mention whatever is mentioned for SMuFL.
>

Ah! I looked more closely and it looks like the current version is only
under the W3C Final Specification Agreement. Sorry for the bother.

Here's another stab at glyphnames.json.txt, given all this new information:

glyphnames.json is a part of the Standard Music Font Layout (SMuFL)
specification, version 1.3. It was retrieved from
https://github.com/w3c/smufl on 29 Aug 2020, and is licensed under the
W3C Final Specification Agreement, found at
https://www.w3.org/community/about/process/final/.

What do you think?

Re: GSoC 2020 update: (hopefully) final commits made; testing time

[Werner LEMBERG]

> So, glyphnames.json.txt would look like this?
> 
>   glyphnames.json, created by Daniel Spreadbury, was retrieved from
>   https://github.com/w3c/smufl on DD Mon . It is licensed under
>   the W3C Community Contributor License Agreement and the W3C Final
>   Specification Agreement.

Looks good, yes.

> It seems that the SMuFL specification (including its helper files)
> are under two licenses which complement each other, the W3C
> Community Contributor License Agreement and the W3C Final
> Specification Agreement.  I don't quite understand their
> relationship to each other, though.  Does only one need to be
> mentioned, or both?

You should mention whatever is mentioned for SMuFL.

>> * You also have to mention the non-LilyPond JSON file license in the
>>   `LICENSE` file since it is not GPL.
> 
> All right. Should I also include a copy of the license(s) in the
> same manner as LICENSE.OFL and LICENSE.DOCUMENTATION?

No.  A link is sufficient, I think.

> Currently, scm/name-conversion.scm and scm/smufl-map.scm are
> generated by gen-emmentaler.fontforge.py. I take it, then, that that
> script should also generate the headers?

Ideally yes.  In particular it should have something like

  THIS IS A GENERATED FILE.  DO NOT EDIT!

  Creator: gen-emmentaler.fontforge.ly

  ...


Werner

Re: GSoC 2020 update: (hopefully) final commits made; testing time

[Owen Lamb]

On Mon, Aug 24, 2020 at 1:07 AM Werner LEMBERG  wrote:

> * Who has written the file `glyphnames.json`?  It lacks a copyright
>   header.  If this is a non-lilypond file copied verbatim, please add
>   a separate file (say, `glyphnames.json.txt`) that gives all the
>   details: author, origin, license, retrieving date, etc.  If
>   necessary, a comment should be added to LilyPond's `LICENSE` file.


So, glyphnames.json.txt would look like this?

glyphnames.json, created by Daniel Spreadbury, was retrieved from
https://github.com/w3c/smufl on DD Mon . It is licensed under the
W3C Community Contributor License Agreement and the W3C Final
Specification Agreement.

It seems that the SMuFL specification (including its helper files) are
under two licenses which complement each other, the W3C Community
Contributor License Agreement and the W3C Final Specification Agreement. I
don't quite understand their relationship to each other, though. Does only
one need to be mentioned, or both?


> * You also have to mention the non-LilyPond JSON file license in the
>   `LICENSE` file since it is not GPL.
>

All right. Should I also include a copy of the license(s) in the same
manner as LICENSE.OFL and LICENSE.DOCUMENTATION?

* In general, all new files like `scm/name-conversion.scm` need a
>   copyright header similar to other files.  Exception are very small,
>   auxiliary files with, say, less then 10 (not too long) lines of
>   data.
>

Gotcha. Currently, scm/name-conversion.scm and scm/smufl-map.scm are
generated by gen-emmentaler.fontforge.py. I take it, then, that that script
should also generate the headers?

Thanks,
Owen

Re: GSoC 2020 update: (hopefully) final commits made; testing time

[Werner LEMBERG]

> I've reordered and rebased my code, and it is now up to date with
> the current master. I've just published the new branch to GitLab as
> dev/lamb/GSoC-2020-final if you'd like to give it a look. It's only
> nine commits now, instead of over a hundred, and they're ordered in
> a way that's hopefully easy to follow.

Some more comments.

* Who has written the file `glyphnames.json`?  It lacks a copyright
  header.  If this is a non-lilypond file copied verbatim, please add
  a separate file (say, `glyphnames.json.txt`) that gives all the
  details: author, origin, license, retrieving date, etc.  If
  necessary, a comment should be added to LilyPond's `LICENSE` file.

* You also have to mention the non-LilyPond JSON file license in the
  `LICENSE` file since it is not GPL.

* In general, all new files like `scm/name-conversion.scm` need a
  copyright header similar to other files.  Exception are very small,
  auxiliary files with, say, less then 10 (not too long) lines of
  data.


Werner

Re: GSoC 2020 update: (hopefully) final commits made; testing time

[Werner LEMBERG]

>> At the same time, I'll write docs for my work.  I figure I'll make
>> nine documentation commits, one for each code change commit.

Hmm.  Maybe I've misunderstood you.  What's actually missing are
documentation strings *within* the commits.  For example, the commit

  Add smufl data to feta glyphs & METAFONT logs

lacks any further description.

In other words, I see a necessity that you amend all of your commits,
enriching each of them with detailed documentation that enables a
reader to understand what's really going on, then doing a force-push
of your branch.

This doesn't replace real user documentation, of course, which should
be added, too.


Werner

Re: GSoC 2020 update: (hopefully) final commits made; testing time

[Urs Liska]

Am Montag, den 24.08.2020, 09:06 +0200 schrieb Werner LEMBERG:
> > I've reordered and rebased my code, and it is now up to date with
> > the current master.  I've just published the new branch to GitLab
> as
> > dev/lamb/GSoC-2020-final if you'd like to give it a look.  It's
> only
> > nine commits now, instead of over a hundred, and they're ordered in
> > a way that's hopefully easy to follow.
> 
> Thanks!
> 
> > At the same time, I'll write docs for my work.  I figure I'll make
> > nine documentation commits, one for each code change commit.  (Of
> > course, I may not need one for every commit, but we'll see.)  Does
> > that sound all right?  Would it be better to make yet another
> branch
> > with the documentation integrated into the main commits?
> 
> I don't see any reason to synchronize the documentation with commits;
> it looks like unnecessary work.  Maybe others disagree, but I think
> you should simply add all of the documentation in a single, separate
> commit.
> 

+1

But probably regtests should match the state of their commits. Except
if you can add all regtests at the end.

Urs
> 
> Werner
> 

Re: GSoC 2020 update: (hopefully) final commits made; testing time

[Werner LEMBERG]

> I've reordered and rebased my code, and it is now up to date with
> the current master.  I've just published the new branch to GitLab as
> dev/lamb/GSoC-2020-final if you'd like to give it a look.  It's only
> nine commits now, instead of over a hundred, and they're ordered in
> a way that's hopefully easy to follow.

Thanks!

> At the same time, I'll write docs for my work.  I figure I'll make
> nine documentation commits, one for each code change commit.  (Of
> course, I may not need one for every commit, but we'll see.)  Does
> that sound all right?  Would it be better to make yet another branch
> with the documentation integrated into the main commits?

I don't see any reason to synchronize the documentation with commits;
it looks like unnecessary work.  Maybe others disagree, but I think
you should simply add all of the documentation in a single, separate
commit.


Werner

GSoC 2020 update: (hopefully) final commits made; testing time

[Owen Lamb]

Hi all!

First, an apology--I thought the project was due today, the 23rd, but it's
actually due next week, on the 31st. Tomorrow is just the first day I can
submit the project. Well, better to err on the side of caution! I'd like to
finish things up at least three days before the Monday deadline--i.e.
Friday--if possible.

I've reordered and rebased my code, and it is now up to date with the
current master. I've just published the new branch to GitLab as
dev/lamb/GSoC-2020-final if you'd like to give it a look. It's only nine
commits now, instead of over a hundred, and they're ordered in a way that's
hopefully easy to follow.

(I made a few changes to the code as I reordered it--removing the vestiges
of abandoned ideas, backtracking on a few things I'm unsure of, and
ensuring LilyPond compiles correctly at every commit. This means the latest
GSoC-2020-final snapshot doesn't match the latest GSoC-2020 snapshot
exactly.)

I suppose this last week, then, is for testing and docs. I'll figure out
how to run the regtests, ensuring I didn't break anything from commit to
commit, and write new regtests as necessary, involving the new
features, like /smuflglyph.

At the same time, I'll write docs for my work. I figure I'll make nine
documentation commits, one for each code change commit. (Of course, I may
not need one for every commit, but we'll see.) Does that sound all right?
Would it be better to make yet another branch with the documentation
integrated into the main commits?

And, of course, I'll also be working on my blog post, which I've already
started writing! I'll let you guys know when it's finished, which will
hopefully be in a couple days.

Questions, comments, and concerns are welcome as always.

Thanks,
Owen

Re: GSoC 2020 update, Aug 15 (the final stretch!)

[Owen Lamb]

On Mon, Aug 17, 2020 at 12:13 AM Werner LEMBERG  wrote:

>
> I wonder whether it is possible to improve legibility: Could you
> modify the code so that whitespace in the strings gets ignored?  I
> consider
>
>  "accidentalFlat & accidentalKucukMucennebFlat & accidentalFlatArabic"
>
> much more readable than
>
>  "accidentalFlat"
>

Great idea! I just pushed a commit for this, so the strings should be more
readable now.

Thanks,
Owen

Re: GSoC 2020 update, Aug 15 (the final stretch!)

[Werner LEMBERG]

Hello Owen,


great progress, as usual!

> This week, I encoded the rest of the Feta glyphs, giving them SMuFL
> names and alternate/ligature information. Only Parmesan is left
> without SMuFL names for the time being.

I wonder whether it is possible to improve legibility: Could you
modify the code so that whitespace in the strings gets ignored?  I
consider

 "accidentalFlat & accidentalKucukMucennebFlat & accidentalFlatArabic"

much more readable than

 "accidentalFlat"

> I believe now is the time for a "feature freeze," if that's the
> right term for it. I don't plan to add any new code to the official
> GSoC project; instead, I'll be focusing on making my code easily
> reviewable, updating docs, and summarizing my work.

OK.

> That said, summarizing looks like it'll be a beast. I suppose if I'm going
> to start from scratch with a new commit history, I'll try to put what I've
> done in this order: [...]

This looks fine to me.


Werner

GSoC 2020 update, Aug 15 (the final stretch!)

[Owen Lamb]

Hi all!

This week, I encoded the rest of the Feta glyphs, giving them SMuFL names
and alternate/ligature information. Only Parmesan is left without SMuFL
names for the time being.

Some of our glyphs, I noticed, needed to be encoded in more than one spot
in the specs, so I added a new separator, &, to my
SMuFL-name/alternate/ligature definition strings. If a string has any ,
each string between them counts as a new character entry as far as SMuFL is
concerned. A glyph receives alternate codepoints as needed to fill in these
values. (This caused a bit of a problem for LilyPond trying to figure out
which of these charcodes a particular glyph index should map to and vice
versa, but I fixed that today.)

I also found that many name entries were of the form
glyphNameStyle;glyphName, which could get verbose pretty fast, so I added a
little syntactic sugar. Now all you have to say is glyphName+Style for the
generation script to recognize that the glyph's name is glyphNameStyle and
it's a stylistic alternate of glyphName.

(I removed the whole note variants of our shape notes, which should result
in the only change to regular LilyPond functionality: Walker whole notes
may vary in direction. If we need to discuss this more, I can revert/skip
that commit.)

Finally, I added a /smuflglyph markup command, usable in the same way
/musicglyph is used.

(I brought back the LILF table, because I wasn't able to find out in time
where it's really used. It now resides in the "lily" metadata object as a
string.)

I cleaned up my TODO's, removing any that have become moot because of later
commits/knowledge. I guess this is as good a time as any to open them up to
input. If you'd like to suggest any solutions or ask any questions about
them, you'll find them in my branch--just search for GSoC-2020 TODO.

I believe now is the time for a "feature freeze," if that's the right term
for it. I don't plan to add any new code to the official GSoC project;
instead, I'll be focusing on making my code easily reviewable, updating
docs, and summarizing my work.

That said, summarizing looks like it'll be a beast. I suppose if I'm going
to start from scratch with a new commit history, I'll try to put what I've
done in this order:

   1. Emmentaler
  - Add SMuFL names & corresponding codepoints to Emmentaler (well,
  just Feta for now)
  - Generate .json metadata file from .mf logs and place in LilyPond
  font directory
  - Make stylistic alternates actual stylistic alternates
   2. LilyPond
  - Locate glyphs by SMuFL name instead of LilyPond name when possible
  - Use new .json metadata file instead of old metadata tables for stem
  attachment, etc.
  - Stop requiring old metadata tables
  - (Back to Emmentaler for a sec) Remove old metadata tables
   3. Miscellaneous
   - Remove whole shape noteheads from Emmentaler; update LilyPond
  accordingly to use half noteheads when applicable. (Again, this
is the only
  commit that should change anything about regular LP usage. Maybe it's
  better to leave this one out for now?)

This order of operations should make my work easy to follow and keep
LilyPond fully functional after each commit. Does it look good to you guys?

I'll be unavoidably out of commission for a few days next week. During that
time, I'd appreciate it if any of you has time to give my TODO's a look.

Thank you all for the help you've given me so far! Here's hoping I can make
the deadline. :)

Thanks,
Owen

Re: GSoC 2020 update: July 25

[Kieren MacMillan]

Hi Owen,

>> Well, of all the new things I'm experiencing in this job, I'm starting to
>> experience burnout.

As someone who experienced almost-complete (i.e., Stage 11 of 12) burnout 
syndrome in 2016, I want to bring your attention to this 
(https://www.inc.com/jessica-stillman/the-12-stages-of-burnout-according-to-psychologist.html),
 which I wish I knew at least forty years before I finally burned out.

For me, the most important takeaway was that the first stage of burnout 
syndrome is "The compulsion to prove oneself".
It doesn’t *lead* to the first stage of burnout syndrome — it *IS* the first 
stage.

Just finding that out (albeit, at 46, far later in life than I wish I had) has 
made a huge positive difference in my life and work.

I am — indeed, I think we all are — very impressed with your work, your work 
ethic, and your communication on this project.
You should be justifiably proud of those things!

But also remember: You are enough.  =)

Best,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: GSoC 2020 update: Aug 7

[Werner LEMBERG]

Hello Owen,


> That said, once I begin finalizing, what would that entail?  I'd
> imagine something like the following:
> 
>- First, I'd look at all the TODO's I've left myself and try to
>  resolve them as best I can.

It depends.  Some TODOs certainly need a very large amount of time and
don't gain much.  You have to judge whether it is worth the time
*right now*, or whether to delay.

>- Then, I'd rebase my commits onto the latest master and make the
>  history a little nicer.  For instance, I'd combine some commits
>  that were incremental changes towards a particular goal, so
>  it'll be easier to judge each facet of my work at a glance.

Maybe it makes sense to create a new branch from scratch instead of
fiddling with existing commits.  As mentioned in another e-mail, it is
in general not necessary to provide a series of commits for a new
file.  Simply commit the new file as a whole instead.  Incremental
commits in logical units only make sense (in most cases) for already
existing files that you have to modify.

>- Then, I'd make changes to LilyPond's docs. This includes any
>  internal comments that may have become outdated.

Yep.

>- Then, I'd take all your feedback regarding my commits, to make
>  sure there aren't any last-minute typos.

Please tell us when you have something we should look at.

>- Then, I'd run tests to make sure everything works as intended
>  and can be added to LilyPond.  I believe we have a suite of
>  regression tests for this, so I guess I'll learn how to run
>  that.

You probably have to write some regression tests by yourself.  The
idea is to get as much code coverage as possible for your changes, and
each test should test as little as possible to make debugging easier.

>- Once everything checks out, as Jean suggested, I'll write a
>  blog post on lilypondblog.org, summarizing my work, what I
>  learned on the way, and where things need to head next for
>  SMuFL on LilyPond.

Yes...

>- ...and it looks like that post can double as my required GSoC
>  summary, as long as I get it in by the 23rd!

...and yes.


Werner

Re: GSoC 2020 update: Aug 7

[Owen Lamb]

On Fri, Aug 7, 2020 at 10:06 PM Urs Liska  wrote:

> Hi Owen,
>
> it's always a pleasure seeing your project evolve and proceed. I'd like
> to throw in a comment, although I'm rather sure it isn't actually
> needed.


> I don't recall reading anything about it but probably you have thought
> about it right from the start, so please take this as just a friendly
> reminder.
>

On the contrary! I'm pretty forgetful, and this reminder is just what I
needed to get my ducks in a row.

Now that the deadline of the project starts coming into view you should
> keep in mind that the priority is to have your work properly tested,
> cleaned-up and merged. This is much more important than getting one or
> more further features implemented - even if they should be your pet
> features or seem crucial.
> As far as I can see your work so far has been extremely useful, and it
> will remain so even if at the end of GSoC it's not in a state that
> every user can use it out-of-the-box.
> OTOH if I understood the recent discussion about merging and rebasing
> correctly your code itself has not been reviewed at all so far? In that
> case you should definitely expect the review process to take longer
> than you initially expect... Even without serious issues the review
> process for getting anything into LilyPond is somewhat time-consuming.
>
> So I encourage you to plan from the end backwards and don't push the
> possibly tedious and boring tasks of finalizing your work too much away
> .
>

That's a good point. Considering, too, that school is starting for me soon,
I probably should start finalizing things soon--a couple days from
now, even.

That said, once I begin finalizing, what would that entail? I'd imagine
something like the following:

   - First, I'd look at all the TODO's I've left myself and try to resolve
   them as best I can.
   - Then, I'd rebase my commits onto the latest master and make the
   history a little nicer. For instance, I'd combine some commits that were
   incremental changes towards a particular goal, so it'll be easier to judge
   each facet of my work at a glance.
   - Then, I'd make changes to LilyPond's docs. This includes any internal
   comments that may have become outdated.
   - Then, I'd take all your feedback regarding my commits, to make sure
   there aren't any last-minute typos.
   - Then, I'd run tests to make sure everything works as intended and can
   be added to LilyPond. I believe we have a suite of regression tests for
   this, so I guess I'll learn how to run that.
   - Once everything checks out, as Jean suggested, I'll write a blog post
   on lilypondblog.org, summarizing my work, what I learned on the way, and
   where things need to head next for SMuFL on LilyPond.
   - ...and it looks like that post can double as my required GSoC summary,
   as long as I get it in by the 23rd!

That's the best process I can think of, but let me know if I'm missing
anything.

Thanks,
Owen

Re: GSoC 2020 update: Aug 7

[Jean Abou Samra]

   Now that the deadline of the project starts coming into view you should
   keep in mind that the priority is to have your work properly tested,
   cleaned-up and merged. This is much more important than getting one or
   more further features implemented - even if they should be your pet
   features or seem crucial. As far as I can see your work so far has been
   extremely useful, and it will remain so even if at the end of GSoC it's
   not in a state that every user can use it out-of-the-box. OTOH if I
   understood the recent discussion about merging and rebasing correctly
   your code itself has not been reviewed at all so far? In that case you
   should definitely expect the review process to take longer than you
   initially expect... Even without serious issues the review process for
   getting anything into LilyPond is somewhat time-consuming. So I
   encourage you to plan from the end backwards and don't push the
   possibly tedious and boring tasks of finalizing your work too much
   away.

   ———-

   Owen,

   Additionally (and sorry if this is obvious), I think would be great if
   you could keep half a day for writing a blog post on
   [1]http://lilypondblog.org/. This will help communication about your
   project in the community.

   Best,

   Jean

References

   1. http://lilypondblog.org/

Re: GSoC 2020 update: Aug 7

[Urs Liska]

Hi Owen,

it's always a pleasure seeing your project evolve and proceed. I'd like
to throw in a comment, although I'm rather sure it isn't actually
needed.

Am Freitag, den 07.08.2020, 21:49 -0700 schrieb Owen Lamb:
> Hi all!
> 
> ...
>
> --turned out to be a major point of difference between
> LilyPond's and SMuFL's treatment of flags.
> 
> I've slightly modified my general project approach, 
>
> ...
>
> The school year is almost upon us here in AZ, and, as I mentioned at
> the
> beginning of summer, there'll be some overlap with GSoC. I'll be out
> for
> the count for a couple weekdays next week, so I'll pick up Saturday
> to make
> up for it. After that, I expect to be doing more night/weekend hours
> as
> classes start up the following week on the 20th.
> 
> My plan is largely the same as it was last week. If you have any
> questions/concerns, as always, feel free to ask away!

I don't recall reading anything about it but probably you have thought
about it right from the start, so please take this as just a friendly
reminder.

Now that the deadline of the project starts coming into view you should
keep in mind that the priority is to have your work properly tested,
cleaned-up and merged. This is much more important than getting one or
more further features implemented - even if they should be your pet
features or seem crucial.
As far as I can see your work so far has been extremely useful, and it
will remain so even if at the end of GSoC it's not in a state that
every user can use it out-of-the-box.
OTOH if I understood the recent discussion about merging and rebasing
correctly your code itself has not been reviewed at all so far? In that
case you should definitely expect the review process to take longer
than you initially expect... Even without serious issues the review
process for getting anything into LilyPond is somewhat time-consuming.

So I encourage you to plan from the end backwards and don't push the
possibly tedious and boring tasks of finalizing your work too much away
.

Best
Urs

> 
> Thanks,
> Owen

GSoC 2020 update: Aug 7

[Owen Lamb]

Hi all!

I've been pretty active on the mailing list this week, so you can see what
I've been up to by checking out the archive.

Essentially, what first seemed to be a minor inconvenience--a grob
misplacement--turned out to be a major point of difference between
LilyPond's and SMuFL's treatment of flags.

I've slightly modified my general project approach, making room ahead of
time for anything SMuFL can't take care of. That way, I don't have to sit
around waiting for the standard to update to keep my work up.

I have not yet added SMuFL's engravingDefaults to Emmentaler, but I've
begun investigating where LilyPond gets its current metrics. Oddly, some
metrics seem to be hardcoded, despite being present in the old LIL* tables
as well. I'll continue that investigation next week.

The school year is almost upon us here in AZ, and, as I mentioned at the
beginning of summer, there'll be some overlap with GSoC. I'll be out for
the count for a couple weekdays next week, so I'll pick up Saturday to make
up for it. After that, I expect to be doing more night/weekend hours as
classes start up the following week on the 20th.

My plan is largely the same as it was last week. If you have any
questions/concerns, as always, feel free to ask away!

Thanks,
Owen

Re: GSoC-2020 update: Jul 31

[Jean Abou Samra]

   Hi Owen,

 Le 6 août 2020 à 03:19, Owen Lamb  a écrit :

   Wow!
   Thanks everyone... even if a lot of this went over my head. I've never
   rebased before, so I can't say what would be the better option.

   There are many tutorials on the Web about this, for instance

   [1]https://medium.com/datadriveninvestor/git-rebase-vs-merge-cc5199edd7
   7c#:~:text=git%20—%20Rebase%20vs%20Merge.%20Rebasing%20and%20merging,fr
   om%20the%20last%20commit%20of%20the%20master%20branch%3A

   At any rate, my understanding is that I'll organize my commits near the
   end of the project to make sure everything is reviewable, correct?

   Yes, you will squash certain commits (concatenate them into a single
   commit) so that reviewers find a logical progression in your work. It
   is also critical that, even if the intermediate commits do not contain
   the whole feature, they must compile and give a usable LilyPond. This
   is for bisecting bugs. (It’s mentioned somewhere in the Contributor’s
   Guide, I can’t find the link...) Sometimes, this even means squashing
   all of your commits together.

   If that's the case, it might just be good to wait until then before I
   rebase and/or merge anything.

   Indeed, that’s what Jonas meant. The only caveat is that if master
   changes too much in the meantime in the same area, conflicts will be
   harder to solve. That said, I don’t think this particular area is
   evolving fast, is it? So, in the end... do it the way you prefer.

   Best,
   Jean

References

   1. 
https://medium.com/datadriveninvestor/git-rebase-vs-merge-cc5199edd77c#:~:text=git
 — Rebase vs Merge. Rebasing and merging,from the last commit of the master 
branch:

Re: GSoC-2020 update: Jul 31

[Owen Lamb]

Wow!

Thanks everyone... even if a lot of this went over my head. I've never
rebased before, so I can't say what would be the better option.

At any rate, my understanding is that I'll organize my commits near the end
of the project to make sure everything is reviewable, correct? If that's
the case, it might just be good to wait until then before I rebase and/or
merge anything.

Thanks,
Owen

On Sat, Aug 1, 2020 at 11:21 PM Jonas Hahnfeld via Discussions on LilyPond
development  wrote:

> Am Samstag, den 01.08.2020, 23:31 +0200 schrieb Jean Abou Samra:
> > While I generally prefer merging over rebasing, since we enforce an
> > all-fast-forward policy for merging to master, I think we should rebase
> > here. My reasoning is that you put in more information when resolving
> > conflicts during a rebase: merging means you unify two diverging
> > histories, thus you get prompted once and for all, but rebasing forces
> > you to resolve conflicts for each intermediary commit.
>
> But only for conflicts that git detects. For example, it doesn't
> guarantee at all that every intermediate commit can be built afterwards
> (in fact, I rather find this unlikely for larger changes).
>
> > As far as my
> > understanding extends, if Owen merges now, there will still be work left
> > for rebasing at the end of the project, part of which will be
> > duplicated. By contrast, rebasing now means less error-prone work in the
> > future.
>
> I think we're not going to just merge (in whatever way) all commits
> from the branch to master at the end of the summer, are we? Eventually
> this means the changes need to be split into reviewable chunks, as is
> also a policy of the project.
> For now, I'd leave the branch where it is. At least this guarantees
> that all commits work the way Owen wrote them.
>
> Jonas
>

Re: GSoC-2020 update: Jul 31

[Owen Lamb]

On Fri, Jul 31, 2020 at 9:59 PM Werner LEMBERG  wrote:

> A question to commit d092b23276059c77e33cab9428b9a9753b5cd27a: Why do
> you change from the (IMHO preferable) `-` to `_` in the file name?  I
> consider `_` an abomination that is only necessary because `-` is not
> a valid character in identifiers of many programming languages.
>

I changed to _ because Bravura's metadata file is named
bravura_metadata.json in the GitHub repo, and I wanted to be consistent
with what I found there. However, I took a closer look at the SMuFL specs
,
and it looks like that naming scheme isn't specifically mentioned. I guess
I'll have to ask about it on the W3C mailing list.

--Owen

Re: GSoC-2020 update: Jul 31

[Owen Lamb]

Thanks for the tip! I just filed issue #4417 on their repo.

(I originally was going for the mailing list because I thought there might
be something wrong with our font files, not FontForge itself, and it'd be
premature to file a bug report. But I guess if FontForge can't fail
gracefully and tell you what went wrong in some case, that's enough reason
to ask about it.)

--Owen

On Fri, Jul 31, 2020 at 9:36 PM Daniel Benjamin Miller <
dbmil...@dbmiller.org> wrote:

> Also, the best way to get at the FF devs is by opening an issue on
> GitHub, where there are no issues with attachments.
>
> On 8/1/20 12:34 AM, Daniel Benjamin Miller wrote:
> > Great work, Owen, and I'll be happy to use your implementation of
> > smufl in LilyPond, instead of having to deal with my own manual
> > Bravura conversions.
> >
> > But the flags as they stand are not displaying at the same scale as
> > they do in Bravura when output by Dorico. See this file for a sample:
> > https://imslp.org/wiki/File:PMLP268812-Chanson_de_Printemps_(Ab).pdf
> >
> > Best,
> > DBM
> >
>

Re: GSoC-2020 update: Jul 31

[Owen Lamb]

(Forgot to reply-all, so sending this to the mailing list as well.)

Hi Daniel,

I see what you mean. Judging from the example you offered, however, I
believe the issue is not one of scaling, but of origin misplacement. When
zoomed in, my current reproduction of Bravura appears to be too far to the
right, yielding a greater whitespace than there should be between the stem
and the flag. The Y positions of the top and bottom of the glyph, however,
seem to be in the correct place, so the larger appearance is probably just
an artifact of the misplacement. I'll see what I can do about it this week.

Thanks,
Owen

On Fri, Jul 31, 2020 at 9:34 PM Daniel Benjamin Miller <
dbmil...@dbmiller.org> wrote:

> Great work, Owen, and I'll be happy to use your implementation of smufl
>
>> in LilyPond, instead of having to deal with my own manual Bravura
>
>> conversions.
>
>>
> But the flags as they stand are not displaying at the same scale as they
>
>> do in Bravura when output by Dorico. See this file for a sample:
>
>> https://imslp.org/wiki/File:PMLP268812-Chanson_de_Printemps_(Ab).pdf
>
>>
> Best,
>
>> DBM
>
>>
>>

Re: GSoC-2020 update: Jul 31

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Samstag, den 01.08.2020, 23:31 +0200 schrieb Jean Abou Samra:
> While I generally prefer merging over rebasing, since we enforce an 
> all-fast-forward policy for merging to master, I think we should rebase 
> here. My reasoning is that you put in more information when resolving 
> conflicts during a rebase: merging means you unify two diverging 
> histories, thus you get prompted once and for all, but rebasing forces 
> you to resolve conflicts for each intermediary commit.

But only for conflicts that git detects. For example, it doesn't
guarantee at all that every intermediate commit can be built afterwards
(in fact, I rather find this unlikely for larger changes).

> As far as my 
> understanding extends, if Owen merges now, there will still be work left 
> for rebasing at the end of the project, part of which will be 
> duplicated. By contrast, rebasing now means less error-prone work in the 
> future.

I think we're not going to just merge (in whatever way) all commits
from the branch to master at the end of the summer, are we? Eventually
this means the changes need to be split into reviewable chunks, as is
also a policy of the project.
For now, I'd leave the branch where it is. At least this guarantees
that all commits work the way Owen wrote them.

Jonas


signature.asc
Description: This is a digitally signed message part

Re: GSoC-2020 update: Jul 31

[Werner LEMBERG]

 Well, there's a good reason that gitlab has a big, fat 'rebase'
 button...
>>
>> Not sure about the meaning of your message: this button shows up
>> because we enabled it as a project-wide setting.  To my knowledge,
>> the default and most common strategy is merging.

Exactly!  It's our policy to prefer rebasing over merging.

>> [...] rebasing now means less error-prone work in the future.
> 
> That sounds reasonable.

Yes.

> However, it means everybody should expect commits to change after
> having looked at rhem.  So: always pull again (well, that's clear)
> and never add commits to Owen's branch wirhout clarifying the state
> directly with him.

Agreed.  Right now, it's Owen's private branch, and nobody should ever
do that.


Werner

Re: GSoC-2020 update: Jul 31

[Urs Liska]

Am 1. August 2020 23:31:32 MESZ schrieb Jean Abou Samra :
>Hi everyone,
>
>Le 01/08/2020 à 18:19, Urs Liska a écrit :
>> Am 1. August 2020 16:12:24 MESZ schrieb Werner LEMBERG :
> Another issue: Maybe it makes sense if you try to rebase your 
> branch from time to time. 
 Really rebase? 
>>> Yes, I favour rebasing over merging since the former causes a 
>>> `prettier' git commit tree.
 This would be a case where "general wisdom" argues against
>modifying 
 pushed commits. Typically you'd rather merge master into your 
 working branch here. 
>>> Well, there's a good reason that gitlab has a big, fat 'rebase' 
>>> button... 
>
>Not sure about the meaning of your message: this button shows up
>because 
>we enabled it as a project-wide setting. To my knowledge, the default 
>and most common strategy is merging.
>
>> Yes, but that is meant to deal with integrating the final result into
>
>> master. Rebasing during work means that Owen's commits don't match 
>> those pulled by others. I don't have a strong opinion here but it 
>> should be an agreed-upon procefure for all.
>
>While I generally prefer merging over rebasing, since we enforce an 
>all-fast-forward policy for merging to master, I think we should rebase
>
>here. My reasoning is that you put in more information when resolving 
>conflicts during a rebase: merging means you unify two diverging 
>histories, thus you get prompted once and for all, but rebasing forces 
>you to resolve conflicts for each intermediary commit. As far as my 
>understanding extends, if Owen merges now, there will still be work
>left 
>for rebasing at the end of the project, part of which will be 
>duplicated. By contrast, rebasing now means less error-prone work in
>the 
>future.

That sounds reasonable.

However, it means everybody should expect commits to change after having looked 
at rhem. So: always pull again (well, that's clear) and never add commits to 
Owen's branch wirhout clarifying the state directly with him.

Urs
>
>Best,
>Jean

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: GSoC-2020 update: Jul 31

[Jean Abou Samra]

Hi everyone,

Le 01/08/2020 à 18:19, Urs Liska a écrit :

Am 1. August 2020 16:12:24 MESZ schrieb Werner LEMBERG :
Another issue: Maybe it makes sense if you try to rebase your 
branch from time to time. 
Really rebase? 
Yes, I favour rebasing over merging since the former causes a 
`prettier' git commit tree.
This would be a case where "general wisdom" argues against modifying 
pushed commits. Typically you'd rather merge master into your 
working branch here. 
Well, there's a good reason that gitlab has a big, fat 'rebase' 
button... 


Not sure about the meaning of your message: this button shows up because 
we enabled it as a project-wide setting. To my knowledge, the default 
and most common strategy is merging.


Yes, but that is meant to deal with integrating the final result into 
master. Rebasing during work means that Owen's commits don't match 
those pulled by others. I don't have a strong opinion here but it 
should be an agreed-upon procefure for all.


While I generally prefer merging over rebasing, since we enforce an 
all-fast-forward policy for merging to master, I think we should rebase 
here. My reasoning is that you put in more information when resolving 
conflicts during a rebase: merging means you unify two diverging 
histories, thus you get prompted once and for all, but rebasing forces 
you to resolve conflicts for each intermediary commit. As far as my 
understanding extends, if Owen merges now, there will still be work left 
for rebasing at the end of the project, part of which will be 
duplicated. By contrast, rebasing now means less error-prone work in the 
future.


Best,
Jean

Re: GSoC-2020 update: Jul 31

[Urs Liska]

Am 1. August 2020 16:12:24 MESZ schrieb Werner LEMBERG :
>>> Another issue: Maybe it makes sense if you try to rebase your
>>> branch from time to time.
>> 
>> Really rebase?
>
>Yes, I favour rebasing over merging since the former causes a
>`prettier' git commit tree.
>
>> This would be a case where "general wisdom" argues against modifying
>> pushed commits.  Typically you'd rather merge master into your
>> working branch here.
>
>Well, there's a good reason that gitlab has a big, fat 'rebase'
>button...

Yes, but that is meant to deal with integrating the final result into master.
Rebasing during work means that Owen's commits don't match those pulled by 
others.

I don't have a strong opinion here but it should be an agreed-upon procefure 
for all.

Urs

>
>
>Werner

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: GSoC-2020 update: Jul 31

[Werner LEMBERG]

>> Another issue: Maybe it makes sense if you try to rebase your
>> branch from time to time.
> 
> Really rebase?

Yes, I favour rebasing over merging since the former causes a
`prettier' git commit tree.

> This would be a case where "general wisdom" argues against modifying
> pushed commits.  Typically you'd rather merge master into your
> working branch here.

Well, there's a good reason that gitlab has a big, fat 'rebase'
button...


Werner

Re: GSoC-2020 update: Jul 31

[Urs Liska]

Am 1. August 2020 06:59:16 MESZ schrieb Werner LEMBERG :
>
>> In the meantime, I've gotten Bravura glyphs to appear on the page!
>
>Congrats!
>
>A question to commit d092b23276059c77e33cab9428b9a9753b5cd27a: Why do
>you change from the (IMHO preferable) `-` to `_` in the file name?  I
>consider `_` an abomination that is only necessary because `-` is not
>a valid character in identifiers of many programming languages.
>
>Another issue: Maybe it makes sense if you try to rebase your branch
>from time to time.

Really rebase?
This would be a case where "general wisdom" argues against modifying pushed 
commits.
Typically you'd rather merge master into your working branch here.

I can see use in both ways, but I strongly suggest making an explicit decision 
with feedback from those who might occasuonally want to look at your code.

But trying not to let master get too far from your branch is surely a good 
suggestion.

Urs

>
>
>Werner

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: GSoC-2020 update: Jul 31

[Werner LEMBERG]

> In the meantime, I've gotten Bravura glyphs to appear on the page!

Congrats!

A question to commit d092b23276059c77e33cab9428b9a9753b5cd27a: Why do
you change from the (IMHO preferable) `-` to `_` in the file name?  I
consider `_` an abomination that is only necessary because `-` is not
a valid character in identifiers of many programming languages.

Another issue: Maybe it makes sense if you try to rebase your branch
from time to time.


Werner

Re: GSoC-2020 update: Jul 31

[Daniel Benjamin Miller]

Also, the best way to get at the FF devs is by opening an issue on 
GitHub, where there are no issues with attachments.


On 8/1/20 12:34 AM, Daniel Benjamin Miller wrote:
Great work, Owen, and I'll be happy to use your implementation of 
smufl in LilyPond, instead of having to deal with my own manual 
Bravura conversions.


But the flags as they stand are not displaying at the same scale as 
they do in Bravura when output by Dorico. See this file for a sample: 
https://imslp.org/wiki/File:PMLP268812-Chanson_de_Printemps_(Ab).pdf


Best,
DBM

Re: GSoC-2020 update: Jul 31

[Daniel Benjamin Miller]

Great work, Owen, and I'll be happy to use your implementation of smufl 
in LilyPond, instead of having to deal with my own manual Bravura 
conversions.


But the flags as they stand are not displaying at the same scale as they 
do in Bravura when output by Dorico. See this file for a sample: 
https://imslp.org/wiki/File:PMLP268812-Chanson_de_Printemps_(Ab).pdf


Best,
DBM

GSoC-2020 update: Jul 31

[Owen Lamb]

Hi all,

Thanks for your encouragement from last week! I took Monday off and made
sure not to overwork myself this week.

I tried posting to the public-music-notation-contrib mailing list with my
SMuFL proposals, but it turns out you have to be a member of the group to
do so. SMuFL's specs offered an alternative, namely, posting suggestions as
issues on GitHub. So, I opened issues #130 and #131 on the tracker there.
Hopefully they'll get somewhere.

I also attempted to send an email to FontForge's mailing list regarding the
failure to create a TTC, but ran into a file size limit because I attached
example .otf files. I could just link to a one-time-use GitHub/Lab repo,
but I was wondering--is there a better place to store once-and-done files
online?

In the meantime, I've gotten Bravura glyphs to appear on the page! After
much digging and a short foray into PostScript, I realized that LilyPond
was still asking fonts for glyphs with old-style LilyPond names, regardless
of the font's actual glyphnames. So I created a new function that returned
a font's actual glyphname for a particular index, and asked for that
instead.

The first time I ran LilyPond on Bravura successfully, it appeared
beautifully on the page (and, to my relief, already at the correct scale).
Everything worked, other than the braces, which are still expected to be
from a separate font, and the stems, which were appearing in the middle of
the notes. Luckily, the stem issue turned out to be a typo. I had LilyPond
generate and look for a "glyphsWithBBoxes" metadata object, but the
specification asked for "glyphBBoxes". With that taken care of, I was able
to get a pretty good-looking specimen of Bravura out there, at least with
some of the more common glyphs.

Attached are a .ly file and its results, both in Emmentaler and in Bravura
before/after the typo fix. (I had to rename Bravura.otf to bravura.otf, so
I'll probably have to deal with that in a better way.)

My plan for next week is as follows:

   - Get the FontForge bug report out
   - Continue encoding Emmentaler glyphs
   - Add all engravingDefaults to Emmentaler
   - Recognize engravingDefaults properly in LP

I do plan on getting around to changing the braces, but I think for now
engravingDefaults are more important to get right. If I don't make it to
the braces, that could still be a pretty self-contained project for me or
someone else to do later.

Again, any questions, comments, or concerns would be appreciated. In the
meantime, I'm going to stick to my resolution--no work on weekends if I can
help it!

Thanks,
Owen
\version "2.21.1"

music = \relative c' {
  %\aikenHeads
  c\breve %\fermata
  c1 d2 e4 f8 f8_"rit" |
  % \override NoteHead.style = #'triangle
  % \override Flag.stencil = #modern-straight-flag
  g8 a4. a16 r16 r8 r4 |
  \bar "|."
}

testScore = {
  \new GrandStaff <<
\new Staff \music
\new Staff {
  \clef bass
  \transpose a a, \music
}
  >>
}

\book {
  \bookOutputSuffix "Bravura"
  \score {
\testScore
  }
  \paper {
   #(define fonts
 (set-global-fonts
  #:music "bravura"
  #:has-sizes? #f
))
  }
}
\book {
  \score {
\testScore
  }
}

Re: GSoC 2020 update: July 25

[Jean Abou Samra]

Le 26/07/2020 à 10:23, Owen Lamb a écrit :


Well, of all the new things I'm experiencing in this job, I'm starting to
experience burnout. With just about a month left, though, I know I need to
keep at it. If you're the praying type, I wouldn't mind if you sent a few
my way! In the meantime, I'm going to try to get a healthy work/rest
schedule going.

Thanks,
Owen


Hi Owen,

This reminds me of the Python developer's guide:

  Burn-out is common in open source due to a misunderstanding of what 
users, contributors, and maintainers should expect from each other.


Having watched your project from the early days, I see that you are 
being extremely serious about it. While I do not understand what you 
talk about in your e-mails, the amount of details given as well as the 
discussions with developers clearly indicate you're working hard.


Working without seeing each other in real life isn't simple, because you 
get little feedback about how others perceive your work, so I figured I 
would send this message to tell you that your commitment in this project 
is patently impressive and very much appreciated.


I guess you need to set the expectations on yourself so as to lower the 
pressure; in fact, even when paid, working on a Free and open source 
software project is volunteering, which entails that the primary 
motivation for all this is and should remain pleasure.


My two cents now: take a real break. Set LilyPond aside for, say, three 
days. Go hiking with your friends, see you grand-parents, play bowling, 
whatever lets you talk with people you enjoy and have fun. The most 
important thing is: let your laptop sleep (if you're receiving 
lilypond-devel e-mail on your phone, go to your subscription page and 
turn off mail delivery while you're having a break; this feature is 
essential for my own rest at the very least).


The other thing is to reflect now about the end of your project. 
Wondering what you'll need to do next week is great, but puts you at 
risk of getting overwhelmed. What needs to be done in the end? Then keep 
planning, going back in time, and you'll probably find that overall, 
you're in a good schedule. I anticipate that six bullet points to tick 
is going to be too much for a single week, which could leave you 
frustrated. By setting such a schedule, you will do the same work, but 
you will work more peacefully-minded.


At the piano, when I have spent two months working on a piece, I find it 
useful to set it aside for two weeks, then come back to it for about 
four weeks. It's a surprising experience. The day you play it again, you 
got some distance with it and you start another round of maturing your 
perspective. What I mean is that taking a bit of rest is not only 
necessary for your well-being, but can also benefit to your project.


Well, hope I'm not being too nanny-ish, but I just felt like this could 
help.


Best regards,
Jean

GSoC 2020 update: July 25

[Owen Lamb]

Hi all,

I didn't make my goal of being able to drop Bravura in, but I made progress.

My research on shape-notes you can see on the list archive--thanks again
everyone for helping out! I'm fairly certain now what to propose to add to
SMuFL, and have written a draft proposal that I will send at the end of the
day Monday if no new input has come in since then.

Otherwise, my work has been on removing the old LILY, LILF, and LILC tables
from Emmentaler. I had to remove a couple of scheme functions to do it,
though, since they basically just returned some part of those tables' data
the same way it was originally packaged. As such, the code is in a messy
state right now--I haven't looked into where they're called yet.

Though it's not called for in the specs, I moved LILY's design_size
property to a temporary spot in the metadata.json file. I have written a
proposal to add it as an optional top-level expression, which I will send
with the shape-note glyph proposal. This will make differentiating size
variations of fonts (such as Emmentaler) much easier for programs that
don't have access to the OTF optical size feature (such as LilyPond).

Bravura is recognized as a font (at least, when I make eight of it,
labelling them with LilyPond's design sizes), and its metadata is
recognized (again, when duplicated). However, no glyphs appear on the
screen, and I haven't figured out why yet. But that's for next week.

Next week, I plan to do the following:

   - Figure out where the deleted scheme functions are used and work around
   them accordingly.
   - Contact the W3C Music Notation Community Group regarding the two
   proposals to SMuFL.
   - Contact the FontForge mailing list about the issues I've been
   experiencing--now that I'm reworking how LilyPond reads fonts, now is the
   best time to try to get Emmentaler into an OTC.
   - Allow single fonts, without size variations, to be imported into
   LilyPond. (At *this* point, Bravura needs to at least show some glyphs,
   however badly scaled.)
   - Fill out the engravingDefaults object with the other necessary values.
   - Have LilyPond read from these values.

Well, of all the new things I'm experiencing in this job, I'm starting to
experience burnout. With just about a month left, though, I know I need to
keep at it. If you're the praying type, I wouldn't mind if you sent a few
my way! In the meantime, I'm going to try to get a healthy work/rest
schedule going.

Thanks,
Owen

Re: GSoC 2020 update, July 18

[Owen Lamb]

Ah, I think I see what you mean. Yes, two properties may prove useful in
the future. But given the presence of a simple workaround for the cases
we're aware of at the moment, I don't see a need to change things until
such an evolution actually happens.

Thanks,
Owen

On Wed, Jul 22, 2020 at 2:35 AM Benkő Pál  wrote:

> I just raised it to show that SMuFL may evolve so (if musicology's
> interpretation of dragmae change so) that separate properties of up
> and down stem attachment points may come handy.  you may well have far
> stronger counterarguments, of course.
>
> Owen Lamb  ezt írta (időpont: 2020. júl. 22., Sze,
> 1:57):
> >
> > Thanks for the tip, Benkő!
> >
> > At the moment, I think these sort of double stems are outside of my
> project's scope. A two-stemmed black dragma is present in SMuFL as a
> pre-composed note (mensuralBlackDragma), but Emmentaler does not have a
> glyph for it and LilyPond does not specifically support double-stemming
> single notehead grobs. All I am in charge of at the moment is taking how
> LilyPond currently handles glyphs and adapting it to the SMuFL
> specification, and that's keeping my hands full enough at the moment.
> >
> > If you need it, I think the basic version of such a glyph can currently
> be simulated by using two notehead grobs, something like this:
> >
> > dragma =
> > #(define-music-function (music)
> >(ly:music?)
> >#{
> >  \override Staff.Stem.length = 4
> >  <<
> >\override NoteColumn.direction = #UP
> >#music
> >\\
> >\override NoteColumn.direction = #DOWN
> >#music
> >  >>
> >  \revert Staff.Stem.length
> >#})
> >
> > \score {
> >   \new Staff {
> > \override Staff.NoteHead.style = #'petrucci
> > \dragma { g'4 a'2 }
> > b'4 \dragma b' a' c''
> >   }
> > }
> >
> > I can't vouch for the flags looking right, but it's something.
> >
> > If you want to use the precomposed glyph as it is found in another SMuFL
> font, you should be able to find it via something like OLL's \smuflglyph
> command once I'm done with GSoC. Otherwise, this would probably be a good
> idea for a separate feature request.
> >
> > Hope this helps,
> > Owen
> >
> > On Tue, Jul 21, 2020 at 3:28 AM Benkő Pál  wrote:
> >>
> >> Thanks. Lukas, that's what I looked for!  On the next page there are
> >> dragmas with flags on both stem and ones with flags only on the down
> >> stem.
> >>
> >> Lukas-Fabian Moser  ezt írta (időpont: 2020. júl. 21., K,
> 11:32):
> >> >
> >> > Hi Pál,
> >> >
> >> > > in ancient (ars subtilior) notation there actually are noteheads
> with
> >> > > two stems (which may also be flagged differently), called "dragma".
> >> > > a picture search for "dragma ars subtilior" returned poor images;
> one
> >> > > not entirely useless is
> >> > >
> https://www.last.fm/music/Philippus+de+Caserta/+images/f82a66af9573ba3cf431b0b1986f07e8
> >> > > (staff three, the black block between two red block in the first
> half
> >> > > of the staff); or see the youtube video
> >> > > https://www.youtube.com/watch?v=wd3ouxA9p-o
> >> >
> >> > See also the examples given in Apel, the first of which being
> >> >
> >> >
> https://archive.org/details/notationofpolyph1953apel/page/392/mode/2up
> >> >
> >> > Best
> >> > Lukas
> >> >
>

Re: GSoC 2020 update, July 18

[Benkő Pál]

I just raised it to show that SMuFL may evolve so (if musicology's
interpretation of dragmae change so) that separate properties of up
and down stem attachment points may come handy.  you may well have far
stronger counterarguments, of course.

Owen Lamb  ezt írta (időpont: 2020. júl. 22., Sze, 1:57):
>
> Thanks for the tip, Benkő!
>
> At the moment, I think these sort of double stems are outside of my project's 
> scope. A two-stemmed black dragma is present in SMuFL as a pre-composed note 
> (mensuralBlackDragma), but Emmentaler does not have a glyph for it and 
> LilyPond does not specifically support double-stemming single notehead grobs. 
> All I am in charge of at the moment is taking how LilyPond currently handles 
> glyphs and adapting it to the SMuFL specification, and that's keeping my 
> hands full enough at the moment.
>
> If you need it, I think the basic version of such a glyph can currently be 
> simulated by using two notehead grobs, something like this:
>
> dragma =
> #(define-music-function (music)
>(ly:music?)
>#{
>  \override Staff.Stem.length = 4
>  <<
>\override NoteColumn.direction = #UP
>#music
>\\
>\override NoteColumn.direction = #DOWN
>#music
>  >>
>  \revert Staff.Stem.length
>#})
>
> \score {
>   \new Staff {
> \override Staff.NoteHead.style = #'petrucci
> \dragma { g'4 a'2 }
> b'4 \dragma b' a' c''
>   }
> }
>
> I can't vouch for the flags looking right, but it's something.
>
> If you want to use the precomposed glyph as it is found in another SMuFL 
> font, you should be able to find it via something like OLL's \smuflglyph 
> command once I'm done with GSoC. Otherwise, this would probably be a good 
> idea for a separate feature request.
>
> Hope this helps,
> Owen
>
> On Tue, Jul 21, 2020 at 3:28 AM Benkő Pál  wrote:
>>
>> Thanks. Lukas, that's what I looked for!  On the next page there are
>> dragmas with flags on both stem and ones with flags only on the down
>> stem.
>>
>> Lukas-Fabian Moser  ezt írta (időpont: 2020. júl. 21., K, 
>> 11:32):
>> >
>> > Hi Pál,
>> >
>> > > in ancient (ars subtilior) notation there actually are noteheads with
>> > > two stems (which may also be flagged differently), called "dragma".
>> > > a picture search for "dragma ars subtilior" returned poor images; one
>> > > not entirely useless is
>> > > https://www.last.fm/music/Philippus+de+Caserta/+images/f82a66af9573ba3cf431b0b1986f07e8
>> > > (staff three, the black block between two red block in the first half
>> > > of the staff); or see the youtube video
>> > > https://www.youtube.com/watch?v=wd3ouxA9p-o
>> >
>> > See also the examples given in Apel, the first of which being
>> >
>> > https://archive.org/details/notationofpolyph1953apel/page/392/mode/2up
>> >
>> > Best
>> > Lukas
>> >

Re: GSoC 2020 update, July 18

[Owen Lamb]

Thanks for the tip, Benkő!

At the moment, I think these sort of double stems are outside of my
project's scope. A two-stemmed black dragma is present in SMuFL as a
pre-composed note (mensuralBlackDragma), but Emmentaler does not have a
glyph for it and LilyPond does not specifically support double-stemming
single notehead grobs. All I am in charge of at the moment is taking how
LilyPond currently handles glyphs and adapting it to the SMuFL
specification, and that's keeping my hands full enough at the moment.

If you need it, I think the basic version of such a glyph can currently be
simulated by using two notehead grobs, something like this:

dragma =
#(define-music-function (music)
   (ly:music?)
   #{
 \override Staff.Stem.length = 4
 <<
   \override NoteColumn.direction = #UP
   #music
   \\
   \override NoteColumn.direction = #DOWN
   #music
 >>
 \revert Staff.Stem.length
   #})

\score {
  \new Staff {
\override Staff.NoteHead.style = #'petrucci
\dragma { g'4 a'2 }
b'4 \dragma b' a' c''
  }
}

I can't vouch for the flags looking right, but it's something.

If you want to use the precomposed glyph as it is found in another SMuFL
font, you should be able to find it via something like OLL's
\smuflglyph command once I'm done with GSoC. Otherwise, this would probably
be a good idea for a separate feature request.

Hope this helps,
Owen

On Tue, Jul 21, 2020 at 3:28 AM Benkő Pál  wrote:

> Thanks. Lukas, that's what I looked for!  On the next page there are
> dragmas with flags on both stem and ones with flags only on the down
> stem.
>
> Lukas-Fabian Moser  ezt írta (időpont: 2020. júl. 21., K,
> 11:32):
> >
> > Hi Pál,
> >
> > > in ancient (ars subtilior) notation there actually are noteheads with
> > > two stems (which may also be flagged differently), called "dragma".
> > > a picture search for "dragma ars subtilior" returned poor images; one
> > > not entirely useless is
> > >
> https://www.last.fm/music/Philippus+de+Caserta/+images/f82a66af9573ba3cf431b0b1986f07e8
> > > (staff three, the black block between two red block in the first half
> > > of the staff); or see the youtube video
> > > https://www.youtube.com/watch?v=wd3ouxA9p-o
> >
> > See also the examples given in Apel, the first of which being
> >
> > https://archive.org/details/notationofpolyph1953apel/page/392/mode/2up
> >
> > Best
> > Lukas
> >
>

Re: GSoC 2020 update, July 18

[Benkő Pál]

Thanks. Lukas, that's what I looked for!  On the next page there are
dragmas with flags on both stem and ones with flags only on the down
stem.

Lukas-Fabian Moser  ezt írta (időpont: 2020. júl. 21., K, 11:32):
>
> Hi Pál,
>
> > in ancient (ars subtilior) notation there actually are noteheads with
> > two stems (which may also be flagged differently), called "dragma".
> > a picture search for "dragma ars subtilior" returned poor images; one
> > not entirely useless is
> > https://www.last.fm/music/Philippus+de+Caserta/+images/f82a66af9573ba3cf431b0b1986f07e8
> > (staff three, the black block between two red block in the first half
> > of the staff); or see the youtube video
> > https://www.youtube.com/watch?v=wd3ouxA9p-o
>
> See also the examples given in Apel, the first of which being
>
> https://archive.org/details/notationofpolyph1953apel/page/392/mode/2up
>
> Best
> Lukas
>

Re: GSoC 2020 update, July 18

[Lukas-Fabian Moser]

Hi Pál,


in ancient (ars subtilior) notation there actually are noteheads with
two stems (which may also be flagged differently), called "dragma".
a picture search for "dragma ars subtilior" returned poor images; one
not entirely useless is
https://www.last.fm/music/Philippus+de+Caserta/+images/f82a66af9573ba3cf431b0b1986f07e8
(staff three, the black block between two red block in the first half
of the staff); or see the youtube video
https://www.youtube.com/watch?v=wd3ouxA9p-o


See also the examples given in Apel, the first of which being

https://archive.org/details/notationofpolyph1953apel/page/392/mode/2up

Best
Lukas

Re: GSoC 2020 update, July 18

[Werner LEMBERG]

> in ancient (ars subtilior) notation there actually are noteheads
> with two stems (which may also be flagged differently), called
> "dragma".  a picture search for "dragma ars subtilior" returned poor
> images; one not entirely useless is
> https://www.last.fm/music/Philippus+de+Caserta/+images/f82a66af9573ba3cf431b0b1986f07e8
> (staff three, the black block between two red block in the first
> half of the staff); or see the youtube video
> https://www.youtube.com/watch?v=wd3ouxA9p-o

Very interesting, thanks for the links!  I think these double-stemmed
noteheads count as stems in the normal, modern sense – in particular,
the length of the stems never change.  I rather think that we should
consider them special glyphs, this is, note head + lower stem (or note
head and lower hook, respectively) should form complete glyph
entities.

Are those glyphs already in SMuFL?


Werner

Re: GSoC 2020 update, July 18

[Benkő Pál]

in ancient (ars subtilior) notation there actually are noteheads with
two stems (which may also be flagged differently), called "dragma".
a picture search for "dragma ars subtilior" returned poor images; one
not entirely useless is
https://www.last.fm/music/Philippus+de+Caserta/+images/f82a66af9573ba3cf431b0b1986f07e8
(staff three, the black block between two red block in the first half
of the staff); or see the youtube video
https://www.youtube.com/watch?v=wd3ouxA9p-o

Owen Lamb  ezt írta (időpont: 2020. júl. 20., H, 22:27):
>
> On Sun, Jul 19, 2020 at 2:17 AM Han-Wen Nienhuys  wrote:
>
> > I don't understand why we need 2 properties here. What benefit do we
> > get relative to a single property?
> >
>
> Well, you got me there! Originally, I was under the impression that a
> notehead grob may at some point have two stems attached to it, i.e. when it
> is merged from two noteheads in opposite directions. A closer look has
> revealed that this is not the case: when this happens, there are still two
> noteheads present, and one of them is merely made transparent.
>
> That leaves only one small reason to keep the new properties: I figured it
> would make things easier for the user. SMuFL provides two variants of a
> stem attachment point from the start, so the stem-attachment property would
> have to do one of two things:
>
>- Return either the upwards variant for up-stems, or the downwards
>variant translated around the center into a pseudo-upwards position for
>down-stems. This would ensure you always get an up-stem-flavored
>coordinate, so that moving it to the right always means moving it away from
>the stem, and vice versa, just the way things have worked in the past.
>However, this isn't terribly intuitive and requires a double transformation
>to get from the original down-stem metadata to a final stem position, which
>could introduce rounding errors.
>- Return the up-or-down variant from metadata unchanged. This is easier
>to implement and understand and removes the need to transform
>unnecessarily, but it comes at the cost of having to check a grob's
>direction every time you want to make sense of the property.
>
> With the two new properties, the user would be able to specifically
> redefine -up and -down anchors from the get-go. This, I figured, would make
> Scheme scripts cleaner and easier to read and write. However, given the
> fact that a notehead grob will only ever have one stem attachment point,
> this argument doesn't have a lot of weight anymore.
>
> In short, thank you for pointing this out! If no one objects, I'll remove
> the extra properties.
>
> --Owen

Re: GSoC 2020 update, July 18

[Owen Lamb]

On Sun, Jul 19, 2020 at 2:17 AM Han-Wen Nienhuys  wrote:

> I don't understand why we need 2 properties here. What benefit do we
> get relative to a single property?
>

Well, you got me there! Originally, I was under the impression that a
notehead grob may at some point have two stems attached to it, i.e. when it
is merged from two noteheads in opposite directions. A closer look has
revealed that this is not the case: when this happens, there are still two
noteheads present, and one of them is merely made transparent.

That leaves only one small reason to keep the new properties: I figured it
would make things easier for the user. SMuFL provides two variants of a
stem attachment point from the start, so the stem-attachment property would
have to do one of two things:

   - Return either the upwards variant for up-stems, or the downwards
   variant translated around the center into a pseudo-upwards position for
   down-stems. This would ensure you always get an up-stem-flavored
   coordinate, so that moving it to the right always means moving it away from
   the stem, and vice versa, just the way things have worked in the past.
   However, this isn't terribly intuitive and requires a double transformation
   to get from the original down-stem metadata to a final stem position, which
   could introduce rounding errors.
   - Return the up-or-down variant from metadata unchanged. This is easier
   to implement and understand and removes the need to transform
   unnecessarily, but it comes at the cost of having to check a grob's
   direction every time you want to make sense of the property.

With the two new properties, the user would be able to specifically
redefine -up and -down anchors from the get-go. This, I figured, would make
Scheme scripts cleaner and easier to read and write. However, given the
fact that a notehead grob will only ever have one stem attachment point,
this argument doesn't have a lot of weight anymore.

In short, thank you for pointing this out! If no one objects, I'll remove
the extra properties.

--Owen

Re: GSoC 2020 update, July 18

[Werner LEMBERG]

Owen,


you progress looks really good.  Congrats!

Some general comments to the code style: Please avoid overlong lines
(i.e., lines longer than 80 characters if possible).  Especially if
working with git repository viewers like `gitk` or inspecting merge
requests on the gitlab web page this is very helpful.


Werner

Re: GSoC 2020 update, July 18

[Han-Wen Nienhuys]

On Sun, Jul 19, 2020 at 4:29 AM Owen Lamb  wrote:
> (I also made a couple new scheme properties for a notehead grob:
> stem-attachment-up and stem-attachment-down. At the moment, the old,
> generic stem-attachment property simply calls for the -up or -down variant
> depending on the grob's direction, but it may be wise to always make it
> return stem-attachment-up, to preserve backwards compatibility.
> Perhaps--although this is beyond my Scheme expertise--"setting"
> stem-attachment should set stem-attachment-up, while setting
> stem-attachment-down to an appropriate reflection as well? What do you all
> think?)

I don't understand why we need 2 properties here. What benefit do we
get relative to a single property?

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: GSoC 2020 update, July 18

[Karlin High]

On Sat, Jul 18, 2020, 9:29 PM Owen Lamb  wrote:

> After that, I encoded those glyphs, filling out the rest of the Aikin
> shape-note glyphs while I was at it.
>

Thanks for that! I'm in a community that uses Aikin noteheads to the
exclusion of all else.
--
Karlin High
Missouri, USA

>

GSoC 2020 update, July 18

[Owen Lamb]

Hi all,

Well, I stuck to my plan this week! To recap:

In feta-autometric.mf, I made sure that the chardwx and chardwy variables
are correctly calculated as reflections of charwx and charwy if they aren't
explicitly defined in the character definition. There was a bit of
hullabaloo around strange operator precedence and undefined variables, but
it sorted itself out quickly enough.

The first large piece of work was getting LilyPond to understand up-stem
and down-stem attachment points separately. This meant I had to follow the
function call trail from where stems are calculated in stem.cc, through
note-head.cc, and finally to open-type-font.cc, where the information is
read from the font. I added a direction parameter to the necessary
functions and ensured that Lily no longer attempts to flip the up-stem
coordinates to get the down-stem ones.

(I also made a couple new scheme properties for a notehead grob:
stem-attachment-up and stem-attachment-down. At the moment, the old,
generic stem-attachment property simply calls for the -up or -down variant
depending on the grob's direction, but it may be wise to always make it
return stem-attachment-up, to preserve backwards compatibility.
Perhaps--although this is beyond my Scheme expertise--"setting"
stem-attachment should set stem-attachment-up, while setting
stem-attachment-down to an appropriate reflection as well? What do you all
think?)

The second large piece of work involved changing the units of the stemUpSE
and stemDownNW metadata properties to staff spaces instead of their
previous units (whatever is the default unit for metafont...), and making
LilyPond understand them as such. This one was definitely frustrating--I
had to remind myself what units functions were outputting by placing
temporary comments everywhere. I ended up giving some existing functions
descriptions as to what units they're in, so future visitors can see what's
going on at a glance.

(Poring over the code for this part, I came to the realization that I would
also have to change the bounding box parameters to staff spaces to keep the
calculations simple. Well, I was going to have to get around to that
eventually! LilyPond now reads from the metadata file for stem attachment
points and bounding box values, both in units of staff spaces.)

Finally, I consolidated some noteheads, such as u1triangle/d1triangle, into
a single glyph, i.e. s1triangle, by explicitly defining chardwx and chardwy
as needed. (I couldn't do this for every glyph, of course, as some glyphs
actually change appearance when flipped. Only redundant noteheads, whose
only difference was their stem attachment points, were merged.) After that,
I encoded those glyphs, filling out the rest of the Aikin shape-note glyphs
while I was at it. There are a few issues around shape note glyph encoding,
but I'll mention those in another message.

Just today, I made a quick fix to metadata generation. Plain optional
characters, which are not stylistic alternates or ligatures, can now be
defined. In the same commit, I got rid of a couple annoying entries for a
glyph named "0" that shouldn't have been there... my bad!

The only thing I didn't do this week was allow a glyph to have multiple
SMuFL names--that is, multiple Unicode codepoints. I have yet to see a need
for it. If I do, I'll put it in.

Whew! This week was a tough one, but I learned a lot about LilyPond's
insides--and hopefully, with a few comments, made it a little easier for
future devs to make the same journey. Next week, my plan is as follows:

   - Finish encoding noteheads (Again, I'll be asking about this).
   - Migrate the rest of the contents of LILY, LILC, and LILZ, as needed,
   to SMuFL metadata.json.
   - Have LilyPond read properties from metadata.json whenever it would
   usually read them from one of the old tables.
   - Convert these properties to the appropriate units and read them as
   such.
   - Remove the old tables.

My hope is that by the end of next week, we'll be able to use Bravura as a
drop-in replacement for Emmentaler without throwing any errors--even if its
glyphs won't be scaled correctly quite yet.

Any questions, comments, or concerns would be appreciated!

Thanks,
Owen

Re: GSoC 2020 update, July 11

[Werner LEMBERG]

Hello Owen,


nice to read about your progress!

> Around the middle of the week, I tried to figure out how to get the
> Emmentaler fonts into an OpenType collection, but FontForge only has
> docs for "TrueType Collections".  Apparently, FontForge can make
> OpenType Collections by setting a "cff" flag in font.generateTtc's
> arguments, but trying that (and many variations on it) only yielded
> an error:
> 
> ValueError: Layer is out of range
> 
> And when I tried to specify layer="Fore" in the parameters, it
> segfaulted!  (I don't even know what a segfault is, only that it's
> short for "segmentation fault"...)

A segmentation fault is always a bug in the program (this is, in
FontForge).  What version are you using?  The latest one is from
March, see

  https://github.com/fontforge/fontforge/releases

If you still experience problems with that version please report them
to the FontForge people so that they can be fixed.  If it fails, there
are other programs that could be used to merge OpenType fonts into a
OpenType collection, for example, the `otf2otc` program from the
AFDKO:

  http://adobe-type-tools.github.io/afdko/AFDKO-Overview.html
  https://github.com/adobe-type-tools/afdko


Werner

GSoC 2020 update, July 11

[Owen Lamb]

Hi all!

This week, I forgot to make a plan, so my work was a bit all over the
place. However, I did make progress in a couple places, and now I have a
plan of action for next week.

First, I added support for ligatures in the .mf files. To do this, I
changed the syntax in fet_beginchar's smuflname (now smufldata) parameter.
LilyPond doesn't yet build the ligatures out of components--it only notices
that there are new optional characters and maps them to the correct
codepoint. I also plan on adding support for optional glyphs that are not
stylistic alternates or ligatures in the future.

With this new capability, I finished encoding Feta's clefs. I also encoded
the full dynamics section and a few other scattered glyphs.

I created a new function, convert_glyph_name, that converts a
lilypond.style.name to a smuflStyleName whenever possible, otherwise
leaving the string untouched. I also created a Scheme function wrapper for
it, so it can be called by the end-user. This helped me clean up the
name_to_index function in open-type-font.cc.

---
Around the middle of the week, I tried to figure out how to get the
Emmentaler fonts into an OpenType collection, but FontForge only has docs
for "TrueType Collections". Apparently, FontForge can make OpenType
Collections by setting a "cff" flag in font.generateTtc's arguments, but
trying that (and many variations on it) only yielded an error:

ValueError: Layer is out of range

And when I tried to specify layer="Fore" in the parameters, it segfaulted!
(I don't even know what a segfault is, only that it's short for
"segmentation fault"...) So I put that investigation on hold, saving the
changes I made to a local branch. I'll come back to it after more essential
work is done, I suppose.
---

The last part of the week, I added the glyphsWithAnchors object to
Emmentaler's metadata file, populated with coordinates for stem
attachment--wx and wy (and the new dwx and dwy for down-facing stems--more
on that in a sec). They're not yet in the right units (they should be in
staff spaces), but I wanted to make sure the numbers made it to LilyPond
first.

The biggest challenge I've come across so far is the fact that SMuFL
defines two different "anchors" for upward- and downward- facing stems in
an asymmetric notehead glyph. LilyPond has historically created two
versions of such a glyph, each with its own set of wx/wy values to dictate
stem placement in its own direction. This will have to be changed in order
to fit SMuFL's specs.

That said, I have made a plan for next week (or at least the first part of
the week--it depends how long it will all take):

   - Convert stemUpSE and stemDownNW to units of staff spaces, as they
   should be.
   - When a stem faces down, have LilyPond read from stemDownNW instead of
   flipping stemUpSE around.
   - Make sure defaults for the mf variables chardwx and chardwy are
   correctly calculated as reflections of charwx and charwy (see commit
   bcc889ad for my initial, untested attempt).
   - In metafont, merge noteheads in which the only difference is up/down
   stem attachment point, e.g. u1triangle and d1triangle, by explicitly
   defining the new chardwx and chardwy variables.
   - Allow Emmentaler to have plain old optional characters that aren't
   ligatures or stylistic alternates of standard SMuFL glyphs; also, allow a
   glyph to have multiple codepoints if necessary.

If you have any questions, suggestions, or dire warnings, let me know!
(Also, if you have FontForge expertise, I'd appreciate any help figuring
out why FontForge can't generate OTC's. At the moment it's not too big a
deal, though.)

--Owen

Re: GSoC 2020 update, July 2

[Werner LEMBERG]

> First, I updated the .mf files' fet_beginchar functions to take a
> SMuFL name (or a SMuFL name and a SMuFL-style alternate name)
> instead of a codepoint, and made sure the python scripts knew how to
> deal with it.
> 
> I then split smufl-map.scm into two files: name-conversion.scm,
> which maps old LilyPond names to new SMuFL names, and smufl-map.scm,
> which maps SMuFL names to their appropriate codepoints. (I might
> change the naming system in the future, but it works for now.)
> 
> Then, I had open-type-font.cc read the metadata files (which now
> conform to SMuFL specs) and construct lists of alternate glyphs,
> ligatures, and their codepoints. Lastly, I made the name_to_charcode
> function aware of these changes.

Great progress, thanks!


Werner

GSoC 2020 update, July 2

[Owen Lamb]

Hi all!

The last couple weeks were pretty stressful, which I'm sure you'll be able
to tell from the list archive. However, in the past couple days I have been
able to make up for much of the time lost.

Last week, I made plans for changing LilyPond's internal treatment of
glyphs--namely, that SMuFL names are the way to go. After a small setback
from Friday through Wednesday, I was able to implement this.

First, I updated the .mf files' fet_beginchar functions to take a SMuFL
name (or a SMuFL name and a SMuFL-style alternate name) instead of a
codepoint, and made sure the python scripts knew how to deal with it.

I then split smufl-map.scm into two files: name-conversion.scm, which maps
old LilyPond names to new SMuFL names, and smufl-map.scm, which maps SMuFL
names to their appropriate codepoints. (I might change the naming system in
the future, but it works for now.)

Then, I had open-type-font.cc read the metadata files (which now conform to
SMuFL specs) and construct lists of alternate glyphs, ligatures, and their
codepoints. Lastly, I made the name_to_charcode function aware of these
changes.

To be perfectly honest, I'm pooped! I'll be taking tomorrow off in
observance of the USA's Independence Day on Saturday, so I'll be back on
Monday.

Thank you, everyone who helped me out these past couple weeks! I couldn't
have gotten through this without you.

--Owen

(P.S. when I was trying to fix my VM, I tried setting its clock back... and
then I forgot to set it to the present again. My commits from today look
like they were made 14 hours earlier than they really were. But at least
they're there!)

Re: GSoC 2020 update, June 19

[Werner LEMBERG]

Hello Owen,


thanks a lot for your detailed summary.

> This week, I corresponded with Daniel Spreadbury on the W3C Music
> Notation Community Group public email list and Behdad Esfahbod on
> the HarfBuzz mailing list, and received some clarifications on how
> to continue.  It looks like we won't need to add OpenType support!
> Instead, we only have to take information from a SMuFL font's
> metadata.json.

Sounds good.  It's still a pity that they didn't decide to add a
SMuFL-specific SFNT table to the font...

> Another thing I have been considering is how to package the
> Emmentaler font. Daniel Spreadbury said that it would be feasible to
> make both variants of Emmentaler (music and text, as per SMuFL
> specs) parts of an OpenType Collection, as Werner suggested, but
> that does not include all the design size variants Emmentaler
> already has. If it were possible to package all of these together in
> a single OTC (I'd just have to figure out a good way to organize
> them; perhaps FontForge's font.design_size property could be used?),
> that may reduce file clutter as well, causing less hassle moving the
> whole font family around.

Having a single OTC for all optical sizes and both text and music
fonts certainly makes sense.

> However, I'm not sure whether that will work, since, as far as I can
> tell, each design size will need its own metadata file due to their
> different line thicknesses.

This shouldn't be a problem.  All font-specific JSON files contain the
`fontName` keyword, making it easy to have a bunch of JSON files where
each is associated with a single subfont of an OpenType collection.


Werner

GSoC 2020 update, June 19

[Owen Lamb]

Hi all! Here with another weekly update.

This week, I corresponded with Daniel Spreadbury on the W3C Music Notation
Community Group public email list and Behdad Esfahbod on the HarfBuzz
mailing list, and received some clarifications on how to continue. It looks
like we won't need to add OpenType support! Instead, we only have to take
information from a SMuFL font's metadata.json.

To that end, I made some metadata files, one for each of Emmentaler's
design sizes. I then wrestled with the makefile docs until I got symbolic
links to those files to show up in the build/out/fonts/otf/ directory. It
seems to work, but I'd appreciate it if some more experienced eyes could
look it over to make sure I did it right:
https://gitlab.com/lilypond/lilypond/-/commit/fe125c4606dd275ea60db7ddd3e646cbe80dce68

(As for actually reading the metadata, I'm on the lookout for a good C++ or
Scheme library for parsing JSON. I've started that discussion in another
thread.)

I also started mapping out a few more categories of glyphs while I had the
time. Some categories were rather easy (especially rests), while others
(such as accordion) will need revisiting in more detail. I'm currently
keeping track of what categories still need work, etc. At any rate, I can
now compile a simple LilyPond score completely using the new glyph lookup
system!

Another thing I have been considering is how to package the Emmentaler
font. Daniel Spreadbury said that it would be feasible to make both
variants of Emmentaler (music and text, as per SMuFL specs) parts of an
OpenType Collection, as Werner suggested, but that does not include all the
design size variants Emmentaler already has. If it were possible to package
all of these together in a single OTC (I'd just have to figure out a good
way to organize them; perhaps FontForge's font.design_size property could
be used?), that may reduce file clutter as well, causing less hassle moving
the whole font family around. However, I'm not sure whether that will work,
since, as far as I can tell, each design size will need its own metadata
file due to their different line thicknesses. Right now, I'm
leaning towards just giving each design size a separate OTC with its two
SMuFL-mandated variations, but I'd appreciate other opinions in case
there's a better option.

It turns out that alternate glyphs need names, too. The JSON metadata file
requires every stylistic alternate to have a name, preferably in keeping
with the SMuFL-style naming scheme. Right now, the metadata files I've
generated simply use the glyph's Lily-style glyph names, for both the base
glyphs and their alternates. That will have to change. I'll probably go
back to the .mf files and extend the smufl_code variable further, allowing
alternates' names to be specified when necessary and placed in the metadata
file. (The base glyph names can be easily determined by using
SMuFL's name-to-unicode JSON map, so no worries there.)

I hope I didn't miss anything, but if I did, I'll let you know. In the
meantime, everyone have a great weekend!

--Owen

Re: GSoC 2020 update, June 15

[Han-Wen Nienhuys]

On Wed, Jun 17, 2020 at 5:26 AM Owen Lamb  wrote:
>
> On Tue, Jun 16, 2020 at 12:16 AM Han-Wen Nienhuys  wrote:
>>
>> On Tue, Jun 16, 2020 at 9:06 AM Werner LEMBERG  wrote:
>>
>> [...] Now we have external
>> > metadata files again – not a single one, but a bunch of them...
>>
>> They're putting the metadata in separate files?
>
>
> If they are, I'm not aware of it. The specification only mentions one 
> metadata file, [font name]-metadata.json.

I guess you mean "they are using only one separate json file", but to
me that is still one file too many.

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: GSoC 2020 update, June 15

[Karlin High]

On 6/16/2020 10:26 PM, Owen Lamb wrote:

I wasn't sure what to say as to my "affiliation" with LilyPond and/or GSoC


I've also had that feeling when interacting with other entities on 
behalf of the LilyPond. This has happened maybe twice. In the past, I've 
said something like "I am a volunteer doing research and testing for the 
GNU LilyPond project (lilypond.org, sheet music engraving software) and 
I'm working on [insert topic here.]"

--
Karlin High
Missouri, USA

Re: GSoC 2020 update, June 15

[Owen Lamb]

On Tue, Jun 16, 2020 at 12:16 AM Han-Wen Nienhuys  wrote:

> On Tue, Jun 16, 2020 at 9:06 AM Werner LEMBERG  wrote:

[...] Now we have external
> > metadata files again – not a single one, but a bunch of them...
>
> They're putting the metadata in separate files?


If they are, I'm not aware of it. The specification only mentions one
metadata file, [font name]-metadata.json. There are a few other JSON files
mentioned, but they are only reference files for SMuFL in general, which
are not expected to be packaged with any fonts.

On Tue, Jun 16, 2020 at 12:20 AM Urs Liska  wrote:

> If it fits into what they (this is also the www music notation
> community group (https://www.w3.org/community/music-notation/)) see fit
> for the way forward it is certainly possible to talk with them.
>

I just sent a message to the list with questions, but again it looks like
there will be a delay. There was an option to sign up as a member, but I
wasn't sure what to say as to my "affiliation" with LilyPond and/or GSoC...

Thanks,
Owen

Re: GSoC 2020 update, June 15

[Urs Liska]

Am Dienstag, den 16.06.2020, 09:16 +0200 schrieb Han-Wen Nienhuys:
> Isn't Smufl a standard proposed by the Dorico folks? 

Yes and no. Daniel Spreadbury spearheaded the effort while Dorico was
developed. But it was originally conceived as an open standard.

> We could try to
> 
> agree on a mechanism with them?

If it fits into what they (this is also the www music notation
community group (https://www.w3.org/community/music-notation/)) see fit
for the way forward it is certainly possible to talk with them.

Urs

Re: GSoC 2020 update, June 15

[Han-Wen Nienhuys]

On Tue, Jun 16, 2020 at 9:06 AM Werner LEMBERG  wrote:
>
> >> Rather late in the week, I also came to the realization that, in
> >> order to support *any* SMuFL font's optional features, I'll also
> >> have to read its metadata JSON file if it has one, before
> >> defaulting to its OpenType features if it doesn't.  (Thanks,
> >> Werner, for guiding me through that business!)
> >
> > if we're doing JSON anyway, you might want see if you can migrate
> > the existing Scheme based table to JSON too.  The Scheme format is
> > convenient because we already have a Scheme parser, but JSON is more
> > fitting to the task.
>
> Well, if we are going the JSON route with external metadata files I
> think it isn't necessary to add LilyPond-specific SFNT tables (like
> 'LILY') to the font at all.  We can simply add one or more JSON files
> that hold the LilyPond metadata.
>
> I must admit that I'm not happy how the SMuFL people have solved the
> problem.  It was always inconvenient in former times that, for
> example, Type 1 fonts have to be accompanied with external metrics
> files (ditto for TeX fonts), and it was a relieve for everyone that
> TrueType (and OpenType) didn't need that.  Now we have external
> metadata files again – not a single one, but a bunch of them...

They're putting the metadata in separate files? Given that TTF/OTF
have generic embedded tables, that is .. not the brightest idea. Maybe
we can just standardize on an embedded table ("ZIP " or something)
that holds a zip file with all files we want access to?

Isn't Smufl a standard proposed by the Dorico folks? We could try to
agree on a mechanism with them?

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: GSoC 2020 update, June 15

[Han-Wen Nienhuys]

On Tue, Jun 16, 2020 at 12:00 AM Owen Lamb  wrote:
> Rather late in the week, I also came to the realization that, in order to
> support *any* SMuFL font's optional features, I'll also have to read its
> metadata JSON file if it has one, before defaulting to its OpenType
> features if it doesn't. (Thanks, Werner, for guiding me through that
> business!)

if we're doing JSON anyway, you might want see if you can migrate the
existing Scheme based table to JSON too. The Scheme format is
convenient because we already have a Scheme parser, but JSON is more
fitting to the task.

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: GSoC 2020 update, June 15

[Werner LEMBERG]

>> Rather late in the week, I also came to the realization that, in
>> order to support *any* SMuFL font's optional features, I'll also
>> have to read its metadata JSON file if it has one, before
>> defaulting to its OpenType features if it doesn't.  (Thanks,
>> Werner, for guiding me through that business!)
> 
> if we're doing JSON anyway, you might want see if you can migrate
> the existing Scheme based table to JSON too.  The Scheme format is
> convenient because we already have a Scheme parser, but JSON is more
> fitting to the task.

Well, if we are going the JSON route with external metadata files I
think it isn't necessary to add LilyPond-specific SFNT tables (like
'LILY') to the font at all.  We can simply add one or more JSON files
that hold the LilyPond metadata.

I must admit that I'm not happy how the SMuFL people have solved the
problem.  It was always inconvenient in former times that, for
example, Type 1 fonts have to be accompanied with external metrics
files (ditto for TeX fonts), and it was a relieve for everyone that
TrueType (and OpenType) didn't need that.  Now we have external
metadata files again – not a single one, but a bunch of them...

As far as I can see, it is not possible at all to create
SMuFL-compliant OpenType fonts that hold all the data that is
contained in the JSON files.  If this my assumption is correct I
wonder whether it makes sense at all to add more OpenType support to
Emmentaler than the bare minimum to make it usable in a text
environment.


Werner

Re: GSoC 2020 update, June 15

[Carl Sorensen]

On Mon, Jun 15, 2020 at 4:00 PM Owen Lamb  wrote:
>
> Hi all,
>
> Apologies for the lateness of this update. Last week was mostly research
> into stylistic alternates and how to support OpenType features in a SMuFL
> font, so not much was done in the way of code changes aside from creating a
> proof-of-concept stylistic alternate mapping.
>

The update may be formally late, but you had conversation on the list
last week, so I don't see any problem.


>
> So, my game plan for this week is as follows: while I correspond with
> HarfBuzz, I will generate a JSON file for Emmentaler. Then, I will have
> open-type-font.cc try to load a font's JSON file, and if that fails its
> GSUB table, into some sort of Scheme object (perhaps an alist?), which can
> then be read (or written--who knows if a user might want to mess with font
> metadata!) by LilyPond. I will probably need to create another
> font-specific Scheme alist so that specific font features, such as
> ligatures, alternates, or style sets, can be turned on or off at any point,
> telling HarfBuzz (or whatever glyph-replacing method we go with) which of
> them to use at any given moment.

I think that you should use a hash table, rather than an alist.  As I
understand it, you'll be creating it once, and accessing it many
times.  The extra computation to create a hash table will be repaid
many times over in the lookup.

>
> (A SMuFL font's metadata file also includes settings such as staff line
> thickness, etc. for drawing primitives in their correct proportions, so
> I'll eventually need to make LilyPond respect those as well. But one step
> at a time!)
>

> Once again, if you have any worries/suggestions, please let me know. I plan
> to send my next update on time, on Friday.
>

Thanks for your good work.  I'm excited to see this happening!

Carl

GSoC 2020 update, June 15

[Owen Lamb]

Hi all,

Apologies for the lateness of this update. Last week was mostly research
into stylistic alternates and how to support OpenType features in a SMuFL
font, so not much was done in the way of code changes aside from creating a
proof-of-concept stylistic alternate mapping.

It appears that the HarfBuzz library, already a LilyPond dependence thanks
to Pango, can read an OT font's table of features. I sent a help request to
the HarfBuzz mailing list, but it appears not to have gone through yet,
since I'm not a member of the list. Now that the weekend's over and my
message still hasn't appeared on the HarfBuzz archive, I've joined the list
and sent the message again.

Rather late in the week, I also came to the realization that, in order to
support *any* SMuFL font's optional features, I'll also have to read its
metadata JSON file if it has one, before defaulting to its OpenType
features if it doesn't. (Thanks, Werner, for guiding me through that
business!)

So, my game plan for this week is as follows: while I correspond with
HarfBuzz, I will generate a JSON file for Emmentaler. Then, I will have
open-type-font.cc try to load a font's JSON file, and if that fails its
GSUB table, into some sort of Scheme object (perhaps an alist?), which can
then be read (or written--who knows if a user might want to mess with font
metadata!) by LilyPond. I will probably need to create another
font-specific Scheme alist so that specific font features, such as
ligatures, alternates, or style sets, can be turned on or off at any point,
telling HarfBuzz (or whatever glyph-replacing method we go with) which of
them to use at any given moment.

(A SMuFL font's metadata file also includes settings such as staff line
thickness, etc. for drawing primitives in their correct proportions, so
I'll eventually need to make LilyPond respect those as well. But one step
at a time!)

Once again, if you have any worries/suggestions, please let me know. I plan
to send my next update on time, on Friday.

Thanks,
Owen

Re: GSoC 2020 update, June 5

[Werner LEMBERG]

Hello Owen,


> This week, I was able to encode the whole note (semibreve) glyph in
> its proper SMuFL-encoded spot in the PUA based on .mf log output.
> 
> I also got LilyPond to use a generated Scheme hash table to try to
> look up a glyph's SMuFL character code before falling back to the
> old way.  [...]

Nice!

> I also had to rework open-type-font.cc's lookup functions.  Now,
> name_to_index simply calls the new, more 'primitive'
> name_to_charcode and charcode_to_index methods in order to get the
> correct font index through SMuFL.

Just a general remark: A glyph name to character code mapping function
only works if there is a guaranteed one-to-one relationship between
glyph names and character codes.  Normal text fonts, for example,
don't have this property; it is quite common that a font contains far
more glyphs than character codes.  Maybe this should be reflected in
comments for clarity.

> open-type-font.cc is *only* used for music fonts, and pango-font.cc
> for text fonts, correct?  I don't want to mess anything up in the
> text encoding world.

IIRC, you are correct.

> Next, I've begun re-encoding other notehead glyphs, but of course I
> have run into difficulties rather quickly, since the old and new
> encodings hardly have a one-to-one mapping.  SMuFL suggests using
> OTF stylistic alts on the same code point for distinguishing, e.g.,
> double whole note (breve) glyphs with one or two lines on each side,
> but I've been having a bit of trouble finding how to do that in
> FontForge's Python docs.

If difficulties arise, the FontForge people are usually quite helpful.

> It will probably involve changing .mf's log output, too, adding
> support for an optional "." separator in the smuflcode string when
> Python reads the log, e.g. so that "E0A0.01" can be split into
> smufl_code and salt_code.

Sounds sensible.

Congrats to your progress, which looks very promising!


Werner

GSoC 2020 update, June 5

[Owen Lamb]

Hi all,

This week, I was able to encode the whole note (semibreve) glyph in its
proper SMuFL-encoded spot in the PUA based on .mf log output.

I also got LilyPond to use a generated Scheme hash table to try to look up
a glyph's SMuFL character code before falling back to the old way. This was
particularly challenging, as I had to get my mind around Guile's many
different notions of equality and find the right hash table lookup function
to call. (For a while I didn't realize I was looking at docs for the wrong
Guile version, too, which made things a bit frustrating.) At any rate, I
now have a better handle on how Guile works in C++ and in general, and the
lookup function works.

I also had to rework open-type-font.cc's lookup functions. Now,
name_to_index simply calls the new, more 'primitive' name_to_charcode and
charcode_to_index methods in order to get the correct font index through
SMuFL. (And in order for the ly:font-glyph-name-to-charcode Scheme function
to use the new lookup for OpenType yet preserve lookup for Pango fonts, I
made sure Pango-font also has a name_to_charcode function that simply calls
name_to_index, then index_to_charcode, then just called name_to_charcode in
ly:font-glyph-name-to-charcode.) I'd like to make sure, though:
open-type-font.cc is *only* used for music fonts, and pango-font.cc for
text fonts, correct? I don't want to mess anything up in the text encoding
world.

I added a couple LilyPond log messages that confirm whether a particular
music glyph is looked up through the new method or the old one, so I can
now see what I haven't encoded yet when I run LilyPond on a test file. PDF
output remains unchanged, which is a good sign.

Next, I've begun re-encoding other notehead glyphs, but of course I have
run into difficulties rather quickly, since the old and new encodings
hardly have a one-to-one mapping. SMuFL suggests using OTF stylistic alts
on the same code point for distinguishing, e.g., double whole note (breve)
glyphs with one or two lines on each side, but I've been having a bit of
trouble finding how to do that in FontForge's Python docs.

It will probably involve changing .mf's log output, too, adding support for
an optional "." separator in the smuflcode string when Python reads the
log, e.g. so that "E0A0.01" can be split into smufl_code and salt_code. The
Scheme table also needs to support this, so I'll probably have to let the
value of each key-value pair in the table optionally be a pair instead of a
number to hold both codes.

So that's where I am right now, and where I expect to go next week. If
there's anything I missed/messed up, please let me know, as usual.
Suggestions and advice are very welcome!

Thanks,
Owen

Re: GSoC 2020 update, May 30

[Werner LEMBERG]

> [...] I wonder whether using a number type to store the codes is
> worth the hassle of conditionally changing the number system.

No, it's not.  I just wanted to point out that big numbers *are*
supported if it is really necessary to do so.

> Would it be all right if I continued using strings for smuflcode, or
> would you prefer I switch to a numeric representation?

Please go ahead with what you currently have.


Werner

Re: GSoC 2020 update, May 30

[Owen Lamb]

Hi Werner,

Thank you for pointing out the Metapost documentation!

I've given it a look, and I wonder whether using a number type to store the
codes is worth the hassle of conditionally changing the number system.
According to the docs, there is no 0x prefix or anything similar to denote
a numeric hexadecimal literal. It seems that, if we want to use hexadecimal
number representation in the metafont files (which I think would be ideal
for human readability) and store it internally as a number too, our only
choice is to call the hex function on a string, then call decimal on it
when printing it to the log file. This seems superfluous. Leaving the codes
as strings from the start would make concatenation into the log file more
straightforward and remove the need to quarantine everything
smuflcode-related from
everything else. And Python can parse a hex string as easily as it can
parse decimal strings, so reading the log won't be an issue on its end.

Would it be all right if I continued using strings for smuflcode, or would
you prefer I switch to a numeric representation?

--Owen

On Sat, May 30, 2020 at 11:49 PM Werner LEMBERG  wrote:

>
> > I started work on Han-Wen's suggested order of operations. In order
> > to make the .mf files output a SMuFL code to their log, I needed to
> > learn Metafont, which proved to be a language as little documented
> > as it is ingenious.  [...]
>
> In case you have TeXLive installed, simply type
>
>   texdoc metapost
>
> to get a nice and short introduction into METAPOST (this is what we
> actually use to generate the fonts instead of METAFONT).
>
> > (I had to use strings because MF doesn't support numbers at/above
> > 4096.)
>
> This is not true for (recent versions of) METAPOST, which supports
> various number systems, including IEEE 64bit floating point.  However,
> to still allow processing with METAFONT to generate the nice DVI glyph
> previews, such code should be restricted so that it is executed for
> METAPOST only.  Note that selecting the number system is a run-time
> option (see appendix A); if you really need large integers, the build
> system of LilyPond has to be updated accordingly (and probably the
> minimum version of METAPOST, too).
>
> > As an aside, looking at my Git history, it appears that, when I
> > tried to change the name of my first commit to be more informative,
> > I accidentally fused it with Valentin's previous commit.  [...]
>
> Don't worry.  For GSoC purposes I strongly suggest that, shortly
> before the end, you create another branch that contains your stuff in
> concise, small, and logically ordered commits so that reviewers can
> easily follow.
>
>
> Werner
>
>
> PS: A remark to Freetype versions: I think you can safely assume that
> FreeType 2.6 and newer is available.  There is other code in
> LilyPond that could be simplified if this assumption is true, and
> I will eventually submit a Merge Request to handle that.
>

Re: GSoC 2020 update, May 30

[Werner LEMBERG]

>> In case you have TeXLive installed, simply type
>>
>>texdoc metapost
> 
> :D
> 
> I get the doc ... but its all in Cyrillic.

Pfft.  Towarischtsch, you probably have to adjust your locale
settings :-)

Try

  texdoc mpman

instead.


Werner

Re: GSoC 2020 update, May 30

[Han-Wen Nienhuys]

On Sun, May 31, 2020 at 12:34 AM Owen Lamb  wrote:
> I started work on Han-Wen's suggested order of operations. In order to make
> the .mf files output a SMuFL code to their log, I needed to learn Metafont,
> which proved to be a language as little documented as it is ingenious.
> First, I followed the Metafont tutorial provided in the LilyPond docs
> (found at http://metafont.tutorial.free.fr/). It seemed to be
> unfinished, so I started looking at the other resources on that site. *The
> METAFONT Book* was comprehensive, but, since TeXing it is not legally
> allowed,

I think nobody can stop you from texing it and looking at the result.
Don't redistribute the resulting PDF, though.

I commend you for trying to learn Metafont, but it's one of the most
obscure, niche programming languages I ever learned, and if I have to
do something, I have to look up how it works all over again. If you
got to dumping some string/number from the autometric macros, then
you've achieved your objective already.

> As an aside, looking at my Git history, it appears that, when I tried to
> change the name of my first commit to be more informative, I accidentally
> fused it with Valentin's previous commit. Sorry about that! The code isn't
> affected, but it looks rather strange. I think it's because I attempted to
> revert the previous commit *and* do an "amend" commit. The right way to do
> it would have been just to "amend," correct? At any rate, I plan on
> thinking harder about what to call my commits the first time from now on!

If you are building a  multi-commit series, you should get familiar
with rebase -i. This lets you edit commits in the middle of a
sequence.

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: GSoC 2020 update, May 30

[James Lowe]

On 31/05/2020 07:49, Werner LEMBERG wrote:

In case you have TeXLive installed, simply type

   texdoc metapost


:D

I get the doc ... but its all in Cyrillic.

?

James

Re: GSoC 2020 update, May 30

[Werner LEMBERG]

> I started work on Han-Wen's suggested order of operations. In order
> to make the .mf files output a SMuFL code to their log, I needed to
> learn Metafont, which proved to be a language as little documented
> as it is ingenious.  [...]

In case you have TeXLive installed, simply type

  texdoc metapost

to get a nice and short introduction into METAPOST (this is what we
actually use to generate the fonts instead of METAFONT).

> (I had to use strings because MF doesn't support numbers at/above
> 4096.)

This is not true for (recent versions of) METAPOST, which supports
various number systems, including IEEE 64bit floating point.  However,
to still allow processing with METAFONT to generate the nice DVI glyph
previews, such code should be restricted so that it is executed for
METAPOST only.  Note that selecting the number system is a run-time
option (see appendix A); if you really need large integers, the build
system of LilyPond has to be updated accordingly (and probably the
minimum version of METAPOST, too).

> As an aside, looking at my Git history, it appears that, when I
> tried to change the name of my first commit to be more informative,
> I accidentally fused it with Valentin's previous commit.  [...]

Don't worry.  For GSoC purposes I strongly suggest that, shortly
before the end, you create another branch that contains your stuff in
concise, small, and logically ordered commits so that reviewers can
easily follow.


Werner


PS: A remark to Freetype versions: I think you can safely assume that
FreeType 2.6 and newer is available.  There is other code in
LilyPond that could be simplified if this assumption is true, and
I will eventually submit a Merge Request to handle that.

Re: GSoC 2020 update, May 30

[Carl Sorensen]

On Sat, May 30, 2020 at 4:34 PM Owen Lamb  wrote:
>
> Hi all. Sorry for the radio silence the past couple days. I got rather
> overwhelmed trying to learn Metafont on my own, and the schedule I set up
> for myself broke down rather quickly. I'll do my best to give my next
> weekly report on time (i.e. on Friday).
>
> Since I gave an update earlier this week, I'll just fill you in on the last
> couple days. In the future, this will be a regular thing on Fridays. So,
> without further ado...
>
> I started work on Han-Wen's suggested order of operations. In order to make
> the .mf files output a SMuFL code to their log, I needed to learn Metafont,
> which proved to be a language as little documented as it is ingenious.
> First, I followed the Metafont tutorial provided in the LilyPond docs
> (found at http://metafont.tutorial.free.fr/). It seemed to be
> unfinished, so I started looking at the other resources on that site. *The
> METAFONT Book* was comprehensive, but, since TeXing it is not legally
> allowed, I looked off the source, which is rather difficult to parse out.
> (I'm considering just buying the book, as it would be good for future
> reference even outside LilyPond.) Still, I finally got something together
> that outputs a hex code for each character, defaulting to "0" if SMuFL
> isn't yet implemented for it. (I had to use strings because MF doesn't
> support numbers at/above 4096.) I do have a question about making the code
> cleaner, but I'll save that for a separate message to keep replies
> organized.

Here's an inexpensive copy of the MetafontBook.

https://www.amazon.com/Computers-Typesetting-C-Metafont-Book/dp/0201134454


HTH,

Carl

GSoC 2020 update, May 30

[Owen Lamb]

Hi all. Sorry for the radio silence the past couple days. I got rather
overwhelmed trying to learn Metafont on my own, and the schedule I set up
for myself broke down rather quickly. I'll do my best to give my next
weekly report on time (i.e. on Friday).

Since I gave an update earlier this week, I'll just fill you in on the last
couple days. In the future, this will be a regular thing on Fridays. So,
without further ado...

I started work on Han-Wen's suggested order of operations. In order to make
the .mf files output a SMuFL code to their log, I needed to learn Metafont,
which proved to be a language as little documented as it is ingenious.
First, I followed the Metafont tutorial provided in the LilyPond docs
(found at http://metafont.tutorial.free.fr/). It seemed to be
unfinished, so I started looking at the other resources on that site. *The
METAFONT Book* was comprehensive, but, since TeXing it is not legally
allowed, I looked off the source, which is rather difficult to parse out.
(I'm considering just buying the book, as it would be good for future
reference even outside LilyPond.) Still, I finally got something together
that outputs a hex code for each character, defaulting to "0" if SMuFL
isn't yet implemented for it. (I had to use strings because MF doesn't
support numbers at/above 4096.) I do have a question about making the code
cleaner, but I'll save that for a separate message to keep replies
organized.

Making a Python-readable JSON list wasn't too hard, comparatively.
Currently, I've got the python code to generate multiple .json files (one
per .mf file), each a single object with key-value pairings between
lilypond glyph names and the SMuFL codes output by MF. Next, I'll be
changing the actual encoding of the glyphs in gen-emmentaler.fontforge.py
to take the SMuFL code instead of the i variable that iterates through
consecutive numbers. I'll probably have to move the as-yet-unchanged
characters to a different code point location to avoid conflicts (both the
old and the new encodings use the same PUA), but that should be an
easy change, since, as has been mentioned before, LilyPond currently looks
for glyph names, not code points.

As an aside, looking at my Git history, it appears that, when I tried to
change the name of my first commit to be more informative, I accidentally
fused it with Valentin's previous commit. Sorry about that! The code isn't
affected, but it looks rather strange. I think it's because I attempted to
revert the previous commit *and* do an "amend" commit. The right way to do
it would have been just to "amend," correct? At any rate, I plan on
thinking harder about what to call my commits the first time from now on!

If you have any questions or suggestions, please let me know. I felt rather
overwhelmed this week and made the mistake of not asking for help sooner.

Thanks,
Owen

Re: GSoC 2020 update

[Owen Lamb]

Ah! And of course, soon after I ask, I find that the point is moot. I'm
sticking Bravura deep in the build/out directory where the font files are,
which of course is already ignored by git. Thank you and sorry for the
trouble!

--Owen

On Wed, May 27, 2020 at 2:36 PM Werner LEMBERG  wrote:

>
> > ... as long as we don't intend to ship Bravura along with LilyPond
> > I'd say it shouldn't be added to the repository.  Except if it's
> > necessary to get your work tested (maybe one day you'll habe a merge
> > request that won't work without a real SMuFL font ...).
>
> I second that.  If we are ever going to add it to lilypond's git
> repository I think the right time is just before merging the GSoC
> stuff.  Until then...
>
> > To keep something local to your computer it's better not to use the
> > .gitignore file but .git/info/exclude - which does the same but
> > without itself being committed.
>
> ... this is probably the simplest way to go.
>
>
> Werner
>

Re: GSoC 2020 update

[Werner LEMBERG]

> ... as long as we don't intend to ship Bravura along with LilyPond
> I'd say it shouldn't be added to the repository.  Except if it's
> necessary to get your work tested (maybe one day you'll habe a merge
> request that won't work without a real SMuFL font ...).

I second that.  If we are ever going to add it to lilypond's git
repository I think the right time is just before merging the GSoC
stuff.  Until then...

> To keep something local to your computer it's better not to use the
> .gitignore file but .git/info/exclude - which does the same but
> without itself being committed.

... this is probably the simplest way to go.


Werner

Re: GSoC 2020 update

[Urs Liska]

Hi Owen!

Am 27. Mai 2020 22:58:19 MESZ schrieb Owen Lamb :
>Hi all!
>
>I pushed the new dev/lamb/GSoC-2020 branch to origin yesterday, and it
>appears to be visible on GitLab. I haven't committed anything new yet,
>but
>I will soon. I'll push any commits I make at the end of each work day.
>
>I plan to give updates regularly every Friday. So far I have been
>investigating open-type-font.cc as an entrypoint for changing the
>encoding,
>but I'll have a more detailed report then.
>
>I have a couple questions in the meantime:
>
>I plan to temporarily add the Bravura font to my lilypond branch for
>testing SMuFL throughout the summer. Is there any legal reason not to

No. Bravura has very avöctively been developed and promoted to be an open font.

It may be shared along with the usual license stuff, but ...

>(or
>at least to .gitignore it so it only appears on my machine)? 

... as long as we don't intend to ship Bravura along with LilyPond I'd say it 
shouldn't be added to the repository. Except if it's necessary to get your work 
tested (maybe one day you'll habe a merge request that won't work without a 
real SMuFL font ...).

To keep something local to your computer it's better not to use the .gitignore 
file but .git/info/exclude - which does the same but without itself being 
committed.

Best
Urs

It appears
>to
>be licensed under OFL 1.1, just like Feta, but I'd just like to make
>sure
>I'm not accidentally breaking any laws as I work publicly.
>
>This next one is a minor annoyance and probably a C++ newbie question,
>but
>my IDE (VS Code, chosen for comfort) is reporting "a
>dynamically-initialized local static variable is not allowed inside of
>a
>statement expression" about a million times throughout the .cc files,
>whenever particular #define'd macros, e.g. ly_symbol2scm or
>get_property,
>are referenced. From what I know, macros aren't dynamically
>initialized,
>are they? Does anyone know why this might be happening? This doesn't
>seem
>to affect compilation, so I can easily ignore the red squiggly lines,
>but
>if there's a way to get rid of them, I'm all ears.
>
>And, of course, if you have any comments or suggestions about anything
>else, please let me know!
>
>Thanks,
>Owen

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

GSoC 2020 update

[Owen Lamb]

Hi all!

I pushed the new dev/lamb/GSoC-2020 branch to origin yesterday, and it
appears to be visible on GitLab. I haven't committed anything new yet, but
I will soon. I'll push any commits I make at the end of each work day.

I plan to give updates regularly every Friday. So far I have been
investigating open-type-font.cc as an entrypoint for changing the encoding,
but I'll have a more detailed report then.

I have a couple questions in the meantime:

I plan to temporarily add the Bravura font to my lilypond branch for
testing SMuFL throughout the summer. Is there any legal reason not to (or
at least to .gitignore it so it only appears on my machine)? It appears to
be licensed under OFL 1.1, just like Feta, but I'd just like to make sure
I'm not accidentally breaking any laws as I work publicly.

This next one is a minor annoyance and probably a C++ newbie question, but
my IDE (VS Code, chosen for comfort) is reporting "a
dynamically-initialized local static variable is not allowed inside of a
statement expression" about a million times throughout the .cc files,
whenever particular #define'd macros, e.g. ly_symbol2scm or get_property,
are referenced. From what I know, macros aren't dynamically initialized,
are they? Does anyone know why this might be happening? This doesn't seem
to affect compilation, so I can easily ignore the red squiggly lines, but
if there's a way to get rid of them, I'm all ears.

And, of course, if you have any comments or suggestions about anything
else, please let me know!

Thanks,
Owen