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
  }
}