Re[2]: LilyPond | Doc: expand NR 1.6.2.3 Hiding staves (!91)

[Trevor]

Valentin, you wrote 27/05/2020


By the way: Trevor, would you take a look when you have a minute?
I’m worried this might be a bit convoluted and/or too wordy. 
@tdanielsmusic 


I support documenting the use of Vertical-Axis-Group.remove-layer, but 
it's a difficult concept to get across.
Having never used it myself I'm still trying to understand all the 
details of the hara-kiri-group-spanner-interface.
The description in the Internal Reference is fairly clear, but I'm 
struggling to decide how best to present it

to a typical user. Let me think it over for another day or so.

Trevor

Re: GSoC 2020: SMuFL glyph name to index lookup

[Werner LEMBERG]

>> It is a technical detail that LilyPond primarily communicates with
>> OTF fonts via glyph names: this is necessary only because LilyPond
>> natively emits PostScript code, which predates the invention of
>> OpenType and thus doesn't use character codes.
> 
> it's not just a historical decision.  LilyPond needs to make
> programmatic choices about which glyphs to select, for example,
> which flag to print on a note depends on the duration of a note and
> its stem direction.  Using names makes encoding that easier: we just
> look for flags{"u" for up, "d" for down}{duration-log}.  This why I
> think it will be practical to keep a map of Feta names around even
> if the whole font gets a SmuFL layout.

I agree.  However, I think the right solution is to make LilyPond use
SMuFL character codes internally.  This will definitely make the code
uglier (so we need *lots* of comments), but I don't see an alternative
to that in the long end.

Accessing glyphs with LilyPond's glyph names would be an add-on.
Using glyph names as shown in the SMuFL specification would be another
add-on.

> once you have done 1-6 and it seems to be working (no output
> differences, but a debugger shows that you load character codes from
> the hash table), expand this mechanism to other classes of glyphs,
> eg.  flags, clefs, scripts, etc.  You can do this is in follow up
> changes, so we don't have to do a big-bang conversion.

This is an excellent suggestion.

> beyond making lilypond load glyphs through smufl, this scheme also has
> the benefit of rearranging Emmentaler in Smufl layout, so it can be
> used in other places.

Yes.


 Werner

Re: GitLab access

[David Kastrup]

Valentin Villenave  writes:

> On 5/28/20, Aaron Hill  wrote:
>> In some ways, this is akin to a job interview
>
> Gosh, I really hope it isn’t!!  My apologies if you’ve been seeing it that 
> way.
>
>> It is counter-productive for me to use my
>> time and talents to fill a role that does not need filling.
>
> That’s hardly been the way our community works; the only era were
> there were “roles” was nearly a decade ago when Graham tried to put
> together a bug triaging team and a doc editing team -- since then,
> we’ve happily gone from the cathedral to the bazaar again.

That is a rather positive spin on "since then, organisational efforts
have fallen apart with many areas no longer getting the necessary
attention".

It's always been a voluntary effort for everyone involved and people
chose what they wanted to do rather than get assigned to it.  I did not
see it as a bad thing that Graham maintained a list of efforts that
wanted to be doing, but it's not like anybody was forced to do anything.
I think it rather saved people efforts finding and identifying their
place rather than otherwise.

And it did not involve job interviews and role assignments either: he
defined roles, but people picked their choice from there.

> I wouldn’t think of it as a “role to fill” so much as a “this may give
> you additional ways to lend a hand whenever and however you feel like
> it”.  That’s all: no formalized “role”, no expectations to fulfill and
> --dear God-- no job interview.  (And that’s certainly the way I’m
> contributing myself these days, in between discouragement phases.)
>
> I have no doubt your knowledgeability and helpfulness will always be
> much appreciated no matter the venue (-user list, -devel, bugtracker,
> code reviewing, doc editing or merge requests) and, personally
> speaking, the more we see of you the better.  But of course, that’s
> entirely up to you and may vary from time to time depending on your
> free time and motivation; these are, after all, the only two
> ingredients Free Software is made of.

-- 
David Kastrup

Re: GitLab access

[Valentin Villenave]

On 5/28/20, Aaron Hill  wrote:
> In some ways, this is akin to a job interview

Gosh, I really hope it isn’t!!  My apologies if you’ve been seeing it that way.

> It is counter-productive for me to use my
> time and talents to fill a role that does not need filling.

That’s hardly been the way our community works; the only era were
there were “roles” was nearly a decade ago when Graham tried to put
together a bug triaging team and a doc editing team -- since then,
we’ve happily gone from the cathedral to the bazaar again.

I wouldn’t think of it as a “role to fill” so much as a “this may give
you additional ways to lend a hand whenever and however you feel like
it”.  That’s all: no formalized “role”, no expectations to fulfill and
--dear God-- no job interview.  (And that’s certainly the way I’m
contributing myself these days, in between discouragement phases.)

I have no doubt your knowledgeability and helpfulness will always be
much appreciated no matter the venue (-user list, -devel, bugtracker,
code reviewing, doc editing or merge requests) and, personally
speaking, the more we see of you the better.  But of course, that’s
entirely up to you and may vary from time to time depending on your
free time and motivation; these are, after all, the only two
ingredients Free Software is made of.

Cheers,
-- V.

Re: GitLab access

[Jonas Hahnfeld via Discussions on LilyPond development]

Hi Aaron,

Am Mittwoch, den 27.05.2020, 23:59 -0700 schrieb Aaron Hill:
> On 2020-05-27 11:14 pm, Jonas Hahnfeld wrote:
> > Am Mittwoch, den 27.05.2020, 16:53 +0200 schrieb Valentin Villenave:
> > > On 5/27/20, Aaron Hill <
> > > lilyp...@hillvisions.com
> > > > wrote:
> > > > I probably could have been (or rather should
> > > > be) submitting patches for consideration.
> > > 
> > > Hear hear!  But as I said, helping out on the lists is certainly not
> > > less worthy as a way of contributing.
> > > 
> > > > I went ahead and linked my GitHub with GitLab, so I am @seraku24 on both
> > > > sites.
> > > 
> > > OK, so now you should be able to send a membership request directly
> > > from GitLab (I’m CCing Jonas just so he knows whom it’s coming from).
> > 
> > Okay, so are you asking for Reporter permission to primarily manage
> > issue reports or for Developer to actually merge code yourself? Note
> > that submitting MRs is possible even without that level of permission.
> > (Sorry if this has been discussed somewhere in the thread, I haven't
> > checked all messages very closely.)
> 
> That was what I had suspected, that no special permissions are needed to 
> contribute issues and/or merge requests.  I certainly would not be 
> asking for anything beyond that level at this time.
> 
> Perhaps all the eagerness around getting the project and team set up 
> with GitLab has put the proverbial cart before the horse here.  (Or I 
> have grossly misinterpreted Valentin's intentions.)

please don't get me wrong: I don't want to deny you any permission to
collaborate more easily. That's simply not my job, I just happen to be
one of the persons with Owner permissions and probably the one with
most experience about GitLab right now.

> The question I see at this point is whether the project is in a 
> particular need of additional members for managing the various facets of 
> the repository.  It would appear there are sufficient people, but that 
> is my outsider view.  That would give me pause to reconsider pursuing 
> membership, seeing as I do not want to intrude on anything, especially 
> if my voice would only add to the cacophony.
> 
> In some ways, this is akin to a job interview--determining whether the 
> candidate is a good fit for the job just as much as the company is a 
> good fit for the candidate.  It is counter-productive for me to use my 
> time and talents to fill a role that does not need filling.  Similarly, 
> it would be unwise for me to work a job I am ill-suited for despite the 
> desire to fill that position.

My 2 cents on this one: Every community always needs more members /
collaborators / whatever you call it  there's never a "job" to fill
, but always work to do.

Jonas


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

Re: GSoC 2020: SMuFL glyph name to index lookup

[Joram Noeck]

Hi,

Am 28.05.20 um 06:44 schrieb Werner LEMBERG:
>> This would mean every user would need to learn the new vocabulary if
>> they want to reference glyphs in their scheme code.
> Definitely not :-) However, I can imagine that LilyPond provides an
> option to *also* allow Bravura glyph names (or maybe instead; I don't
> have an opinion here) for `\musicGlyph`.
>

Here is an implementation of the analogous `\smuflglyph`:
https://github.com/openlilylib/openlilylib/blob/master/custom-music-fonts/smufl/definitions.ily#L170

And here is the mapping of smufl names to code points:
https://github.com/openlilylib/openlilylib/blob/master/custom-music-fonts/smufl/smufldata.ily
converted from the json file provided by SMuFL.

And here is a mapping of LilyPond names and SMuFL names (not complete
but extensive):
https://github.com/openlilylib/openlilylib/blob/master/custom-music-fonts/smufl/definitions.ily

All taken from OpenLilyLib:
https://github.com/openlilylib/openlilylib/tree/master/custom-music-fonts/smufl

It is probably not the way to go for GSoC but might be interesting or
save some typing work.

Cheers,
Joram

Re: GitLab access

[Aaron Hill]

On 2020-05-27 11:14 pm, Jonas Hahnfeld wrote:

Am Mittwoch, den 27.05.2020, 16:53 +0200 schrieb Valentin Villenave:

On 5/27/20, Aaron Hill  wrote:
> I probably could have been (or rather should
> be) submitting patches for consideration.

Hear hear!  But as I said, helping out on the lists is certainly not
less worthy as a way of contributing.

> I went ahead and linked my GitHub with GitLab, so I am @seraku24 on both
> sites.

OK, so now you should be able to send a membership request directly
from GitLab (I’m CCing Jonas just so he knows whom it’s coming from).


Okay, so are you asking for Reporter permission to primarily manage
issue reports or for Developer to actually merge code yourself? Note
that submitting MRs is possible even without that level of permission.
(Sorry if this has been discussed somewhere in the thread, I haven't
checked all messages very closely.)


That was what I had suspected, that no special permissions are needed to 
contribute issues and/or merge requests.  I certainly would not be 
asking for anything beyond that level at this time.


Perhaps all the eagerness around getting the project and team set up 
with GitLab has put the proverbial cart before the horse here.  (Or I 
have grossly misinterpreted Valentin's intentions.)


The question I see at this point is whether the project is in a 
particular need of additional members for managing the various facets of 
the repository.  It would appear there are sufficient people, but that 
is my outsider view.  That would give me pause to reconsider pursuing 
membership, seeing as I do not want to intrude on anything, especially 
if my voice would only add to the cacophony.


In some ways, this is akin to a job interview--determining whether the 
candidate is a good fit for the job just as much as the company is a 
good fit for the candidate.  It is counter-productive for me to use my 
time and talents to fill a role that does not need filling.  Similarly, 
it would be unwise for me to work a job I am ill-suited for despite the 
desire to fill that position.



-- Aaron Hill

Re: GSoC 2020: SMuFL glyph name to index lookup

[Han-Wen Nienhuys]

On Thu, May 28, 2020 at 6:44 AM Werner LEMBERG  wrote:
> I think there is a fundamental misunderstanding.  Bravura is an
> OpenType font, and the only intended communication with such fonts is
> via character code values and *not* glyph names.  It is a technical
> detail that LilyPond primarily communicates with OTF fonts via glyph
> names: this is necessary only because LilyPond natively emits
> PostScript code, which predates the invention of OpenType and thus
> doesn't use character codes.

it's not just a historical decision. LilyPond needs to make
programmatic choices about which glyphs to select, for example, which
flag to print on a note depends on the duration of a note and its stem
direction. Using names makes encoding that easier: we just look for
flags{"u" for up, "d" for down}{duration-log}. This why I think it
will be practical to keep a map of Feta names around even if the whole
font gets a SmuFL layout.
> > On the other hand, I could keep the current LilyPond naming system,
> > hand-writing a dictionary that translates LilyPond names straight into
> > SMuFL code points.
>
> Exactly.

You could hand write it, but for 500 glyphs, it may be a bit of work.
I would look into the following route:

The feta/emmentaler fonts are generated with scripts under mf/ . You could

1) update the MF code to emit Smufl character codes together with the
glyphs (look at scripts/build/mf-to-table.py and
mf/feta-autometric.mf). You can dump the mapping from mf-to-table in a
format that Python can easily read/write. JSON is probably the
simplest choice.

2) update the gen-emmentaler.py script so it composes the emmentaler
font using the Smufl layout. Read the information generated in 1) to
help you.

3) use the information created in 1) to create a separate table
mapping feta/emmentaler name to Smufl character code. I would suggest
to dump the mapping as a .scm file that loads the name => number map
into a hash table. You can copy the .scm file into the scm/ directory,
as it won't be changing very often.

4) load the table into lilypond. Check out lily/lily-imports.cc to see
how to load data from Scheme

5) use the table in LilyPond. In Open_type_font, use the GUILE hash
table functions to do the name=>number lookup.

6) Do this for just a subclass of glyphs (eg. note heads). You can
have a fallback in 5) to use the old mechanism if the hash table
doesn't turn up a Smufl character code.

once you have done 1-6 and it seems to be working (no output
differences, but a debugger shows that you load character codes from
the hash table), expand this mechanism to other classes of glyphs, eg.
flags, clefs, scripts, etc. You can do this is in follow up changes,
so we don't have to do a big-bang conversion.

beyond making lilypond load glyphs through smufl, this scheme also has
the benefit of rearranging Emmentaler in Smufl layout, so it can be
used in other places.

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

Re: GitLab access

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Mittwoch, den 27.05.2020, 16:53 +0200 schrieb Valentin Villenave:
> On 5/27/20, Aaron Hill  wrote:
> > I probably could have been (or rather should
> > be) submitting patches for consideration.
> 
> Hear hear!  But as I said, helping out on the lists is certainly not
> less worthy as a way of contributing.
> 
> > I went ahead and linked my GitHub with GitLab, so I am @seraku24 on both
> > sites.
> 
> OK, so now you should be able to send a membership request directly
> from GitLab (I’m CCing Jonas just so he knows whom it’s coming from).

Okay, so are you asking for Reporter permission to primarily manage
issue reports or for Developer to actually merge code yourself? Note
that submitting MRs is possible even without that level of permission.
(Sorry if this has been discussed somewhere in the thread, I haven't
checked all messages very closely.)

Jonas


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

Re: helping with testing resources

[Jonas Hahnfeld]

Am Mittwoch, den 27.05.2020, 13:12 +0200 schrieb Davide Liessi:
> Dear Jonas,
> 
> Il giorno sab 23 mag 2020 alle ore 20:01 Jonas Hahnfeld
>  ha scritto:
> > If you have spare hardware and / or want to help with CI testing, this
> > is easy to setup with GitLab.
> 
> I have setup my laptop for GitLab's CI (of course you already know it).
> 
> A question which may be interesting also to other people: what happens
> if I suspend or switch off my laptop during a build?
> Will the merge request be marked as failed or will another build be
> scheduled in another runner?

AFAIK the pipeline will be marked failed, but the job can be retried
manually. To avoid this you can gracefully shutdown the runner, I
thought I had shared this somewhere:
https://docs.gitlab.com/runner/configuration/init.html#overriding-the-default-service-files

I'm using this and verified that it waits until the current build
finishes. The downside is that it could take up to ~30 minutes if it
has just started a doc build. In that case it may be easier to cancel
the job online and reschedule it.

Jonas


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

Re: GitLab CI: warning about C059-BdIta.otf

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Mittwoch, den 27.05.2020, 23:52 +0200 schrieb Davide Liessi:
> Dear Jonas,
> 
> I noticed in the log of test and documentation builds in GitLab CI the
> following message:
> 
> WARNING: build/out/share/lilypond/current/fonts/otf/C059-BdIta.otf:
> chmod build/out/share/lilypond/current/fonts/otf/C059-BdIta.otf: no
> such file or directory (suppressing repeats)
> 
> Is it expected?

I've seen this on every build so far (call it expected if you want),
but haven't investigated yet. I suppose there is something wrong with
the build's links to font files, maybe the link target is missing?

Jonas


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