openLilyLib git

[Andrew Bernard]

Urs and all,

What happens to orphaned git repos? Not a case I am familiar with.

I'd be happy to fork the OLL repo and take over the management and
development. Should I do that? Are you going to delete the existing
repo?

Andrew

Re: Future of openLilyLib

[Andrew Bernard]

Urs, I am unable to email you at openlilylib.org. Is there another way 
to contact you off list?



Andrew

Re: Future of openLilyLib

[Carl Sorensen]

I think that Urs did not say he's taking it down.  I think he did say he's not 
making his future improvements public.  He's leaving it up on GitHib, but his 
work will be in a private Git repository.

Thanks,

Carl


Sent via the Samsung Galaxy S®6 active, an AT 4G LTE smartphone
Get Outlook for Android


From: lilypond-user  
on behalf of Andrew Bernard 
Sent: Tuesday, October 6, 2020 5:18:03 PM
To: lilypond-user@gnu.org 
Subject: Re: Future of openLilyLib

Urs,

I don't follow. Are you taking down OLL? There are surely many who
depend on it. It's not clear to me what you are saying. I fear you have
reached the wrong conclusion. Even if it is of value to only a dozen
people, is it not still valuable? Don't underestimate the importance - I
could not produce my scores without out. Now I am worried.

Andrew


On 7/10/2020 7:46 am, Urs Liska wrote:
> Well, despite two of today's statements arguing otherwise I must say I
> have come to a different conclusion. I have given myself exactly two
> weeks to make a determination, and I realized I have obviously
> overestimated the value and impact of my pet project openLilyLib.

Re: Future of openLilyLib

[Andrew Bernard]

Urs,

I don't follow. Are you taking down OLL? There are surely many who 
depend on it. It's not clear to me what you are saying. I fear you have 
reached the wrong conclusion. Even if it is of value to only a dozen 
people, is it not still valuable? Don't underestimate the importance - I 
could not produce my scores without out. Now I am worried.


Andrew


On 7/10/2020 7:46 am, Urs Liska wrote:

Well, despite two of today's statements arguing otherwise I must say I
have come to a different conclusion. I have given myself exactly two
weeks to make a determination, and I realized I have obviously
overestimated the value and impact of my pet project openLilyLib.

Re: Future of openLilyLib

[Urs Liska]

Well, despite two of today's statements arguing otherwise I must say I
have come to a different conclusion. I have given myself exactly two
weeks to make a determination, and I realized I have obviously
overestimated the value and impact of my pet project openLilyLib. The
two weeks until yesterday since my (I think pretty strong and explicit)
statement did not trigger *anything* except one stupid and off-topic
discussion. So I realize there is no substantial need for openLilyLib,
and I don't have the resources left (in terms of time and mental or
physical energy) to push it forward without community support. And to
be honest, to include \shapeII into LilyPond or not is definitely not a
matter of having openLilyLib or not.

So today I copied all the relevant repositories to my own Git server
and removed myself from the corresponding Github organizations. I will
use what is there to complete three substantial projects I still have
on my desktop. Everything that is necessary to use and improve the
library and the packages is still freely available and appropriately
licensed, so if anybody considers it worth the effort they can do with
it whatever seems suitable. 

Best
Urs

PS:
Those few who know more about the background shouldn't worry too much
about the final character of this statement ...

Am Montag, den 21.09.2020, 17:24 +0200 schrieb Urs Liska:
> Hi all,
> 
> to begin with, I am of the (biased) opinion that openLilyLib is a
> powerful and useful extension infrastructure for LilyPond. There are
> a
> number of versatile and extended ready-to-use packages available,
> most
> notably probably edition-engraver, scholarLY and anaLYsis. But also
> the
> underlying oll-core is versatile and powerful, providing numerous
> building blocks without which I would not start any large-scale
> project
> anymore.
> 
> I can understand why this view is not shared by everyone, most likely
> simply because too much about OLL is obscure or unknown, lacking
> proper
> documentation, although the general introduction at 
> https://openlilylib
> .org should be a good start (and there are substantial manuals for
> the
> scholarLY and stylesheets packages, but only in (undocumentedly)
> self-
> compilable form).
> 
> At this point openLilyLib is completely dependent on my availability,
> at least because I am the only person with knowledge of the basic
> code
> in oll-core. 
> 
> For several reasons which I won't discuss publicly I will have to
> reduce my availablity to work on openLilyLib (and other stuff) and
> may
> be forced to completely withdraw at any point within the next years.
> 
> I would find it a pity if that would mean the end for openLilyLib.
> Therefore I'm looking not for a new maintainer but for more people
> engaging in the project, to build a community around it that can at
> some point continue without my aid.
> 
> The aspects needing support most urgently AFAICT are (in descending
> order):
> 
>  * getting more people familiar with oll-core (using the opportunity
> to
>maybe improve the coding where appropriate)
>  * complete the documentation system in order to make a more complete
>documentation feasible (here the most crucial part is integrating
>consistently scalable score examples in the web site output).
>  * getting more people familiar with the coding of scholarLY
>  * do maintenance of everything, maybe throwing out some less-than-
>useful packages
>  * write a Frescobaldi extension for managing (installing, updating
> the
>library or individual packages, preparing documents) openLilyLib
> and
>providing an API for secondary extensions (e.g. an annotation
>editor/viewer or a tool to graphically insert editionMods).
> 
> If anything of this looks like your cup of tea you are welcome to
> contact me privately or discuss stuff on-list. Of course I am more
> than
> willing to help with any of these tasks.
> 
> Best
> Urs
> 
> 

Re: Future of openLilyLib

[Martín Rincón Botero]

\reshape is nice! I would try to make it clear in the documentation, if 
\reshape is included in the core, that \shape is the legacy form to be 
eventually deprecated and replaced by \reshape. Syntactically, it makes no 
sense to have both functions available for the same thing. If there could be a 
way to simply replace \shape with \shapeII / \reshape, it would be even better.

PS: \shapeII is already part of the project I’m working on. I always wondered 
if there could be a shorthand for \shape. I’m glad I could finally figure out 
today how to clone all the Github OLL repositories!

www.martinrinconbotero.com
On 6. Oct 2020, 18:44 +0200, Karlin High , wrote:
> On 10/6/2020 11:23 AM, Kieren MacMillan wrote:
> > > \reshape ?
> > Dude… nice work. =)
>
> Made me smile, too. I think that's approaching the perfect amount of
> self-reference humor, without crossing the line to guaranteed obscurity
> for newcomers.
> --
> Karlin High
> Missouri, USA
>

Re: Future of openLilyLib

[Werner LEMBERG]

>> \reshape ?
> 
> Dude… nice work.  =)

Care to submit a MR?


Werner

Re: Future of openLilyLib

[Karlin High]

On 10/6/2020 11:23 AM, Kieren MacMillan wrote:

\reshape ?

Dude… nice work.  =)


Made me smile, too. I think that's approaching the perfect amount of 
self-reference humor, without crossing the line to guaranteed obscurity 
for newcomers.

--
Karlin High
Missouri, USA

Re: Future of openLilyLib

[Kieren MacMillan]

> \reshape ?

Dude… nice work.  =)

Kieren.


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

Re: Future of openLilyLib

[Aaron Hill]

On 2020-10-06 8:45 am, Carl Sorensen wrote:
If \shapeII is production ready, then I'm OK with adding it.  But is 
should
NOT be named \shapeII when it goes into core.  It should be something 
like

\shapeControl.  \shapeII reflects the history that it came after the
creation of \shape.  \shape might even be better, but since we have 
code
out there that uses \shape but is not \shapeII compliant, we can't 
really

use \shape.


\reshape ?


-- Aaron Hill

Re: Scrape around rim

[Martín Rincón Botero]

Sorry, I just discovered that the installation instructions for cloning
with Git explain how to clone oll-core. Not having had any experience
myself with cloning with Git before, I thought I had cloned the whole
repository. I didn't realize the packages had to be cloned separately one
by one. Anyways, the include path is a bit different:

\include "snippets/custom-music-fonts/smufl/definitions.ily"

{
  c''4
  ^\markup { \fontsize #0 \smuflglyph #"pictScrapeAroundRim" }
  c'' c'' c''

}

This works great! Thank you!

Am Fr., 2. Okt. 2020 um 16:57 Uhr schrieb Martín Rincón Botero <
martinrinconbot...@gmail.com>:

> Actually, this doesn't work. I don't even see any path called
> /custom-music-fonts. Maybe this function got indeed moved in the meantime?
>
> Am Mi., 16. Sept. 2020 um 08:18 Uhr schrieb Martín Rincón Botero <
> martinrinconbot...@gmail.com>:
>
>> Thank you, Andrew, for the explanation! I was reading yesterday about it
>> but I couldn't find what to do exactly for this use case. That is so simple
>> to use is amazing!
>>
>> Regards,
>> Martín.
>>
>> On Wed 16. Sep 2020 at 02:33 Andrew Bernard 
>> wrote:
>>
>>> Once you install openlilylib, here's how to do it:
>>>
>>>
>>>
>>> \version "2.21.5"
>>>
>>>
>>>
>>> \include "custom-music-fonts/smufl/definitions.ily"
>>>
>>>
>>>
>>> {
>>>
>>>   c''4
>>>
>>>   ^\markup { \fontsize #0 \smuflglyph #"pictScrapeAroundRim" }
>>>
>>>   c'' c'' c''
>>>
>>>
>>>
>>> }
>>>
>>>
>>>
>>> You just use the names in the SmuFL spec pages.
>>>
>>>
>>>
>>> OLL now has a package system, but this function has not yet been moved
>>>
>>> across. Still works fine.
>>>
>>>
>>>
>>> Obviously you need to set up your path appropriately.
>>>
>>>
>>>
>>>
>>>
>>> Andrew
>>>
>>> --
>> www.martinrinconbotero.com
>>
>
>
> --
> www.martinrinconbotero.com
>


-- 
www.martinrinconbotero.com

Re: Future of openLilyLib

[Carl Sorensen]

On Tue, Oct 6, 2020 at 8:43 AM Andrew Bernard 
wrote:

> Hi JanPeter,
>
> 
>


> One thing that concerns me with lilypond at the present is what I see
> as a sort of balkanisation of code. We have LSR, OLL, and people
> making one-shot GIT repos, and it's all very fragmented. I don't think
> this is good for newcomers, and splitting like this is never good for
> open source projects. I can see the arguments for all these ways of
> making add-ons for lilypond, but it worries me. Yes, LSR is for
> snippets and exemplars, not necessarily for full blown code as OLL is,
> but lately there has been a lot of the latter in LSR that I feel could
> be in OLL.
>

Balkanization is of concern to me as well.  Although in the past, I was
against having a Lilypond stackexchange be official, my recent experience
with TeX stackexchange has caused me to wonder if we should make an
"official" LilyPond stackexchange to replace the user list.  But this may
be a thread hijack.

>
> And then there is this sort of impedance mismatch balkanisation - I
> think OLL should be a feeder into lilypond core, but it appears this
> may never happen. I'd like to promote that idea more. One example
> comes to mind: \shapeII. I have hammered this to a high degree in
> thousands of uses in hundreds of pages of scores over the years. Yes
> there is a small corner case bug or two with it, but nothing stopping
> it going into lilypond I think. It's probably the function I use in
> lilypond more than any other one. In other words, purely from my
> experience, I think it is pretty well tested and would be a good
> candidate for inclusion. Some of the pedal work that Harm and I did
> ought to be in lilypond also I think. What I am saying is that I see
> OLL as a long term incubator for lilypond features. Just a couple of
> ideas from me.
>

If \shapeII is production ready, then I'm OK with adding it.  But is should
NOT be named \shapeII when it goes into core.  It should be something like
\shapeControl.  \shapeII reflects the history that it came after the
creation of \shape.  \shape might even be better, but since we have code
out there that uses \shape but is not \shapeII compliant, we can't really
use \shape.

Thanks,

Carl

Re: Future of openLilyLib

[Andrew Bernard]

Hi JanPeter,

I have contributed a bit to OLL and its machinery and I think it is an
important and indeed necessary resource. I am not sure why the uptake
is so limited, but I think somehow we have to communicate how easy it
is to install and use more effectively.

One thing that concerns me with lilypond at the present is what I see
as a sort of balkanisation of code. We have LSR, OLL, and people
making one-shot GIT repos, and it's all very fragmented. I don't think
this is good for newcomers, and splitting like this is never good for
open source projects. I can see the arguments for all these ways of
making add-ons for lilypond, but it worries me. Yes, LSR is for
snippets and exemplars, not necessarily for full blown code as OLL is,
but lately there has been a lot of the latter in LSR that I feel could
be in OLL.

And then there is this sort of impedance mismatch balkanisation - I
think OLL should be a feeder into lilypond core, but it appears this
may never happen. I'd like to promote that idea more. One example
comes to mind: \shapeII. I have hammered this to a high degree in
thousands of uses in hundreds of pages of scores over the years. Yes
there is a small corner case bug or two with it, but nothing stopping
it going into lilypond I think. It's probably the function I use in
lilypond more than any other one. In other words, purely from my
experience, I think it is pretty well tested and would be a good
candidate for inclusion. Some of the pedal work that Harm and I did
ought to be in lilypond also I think. What I am saying is that I see
OLL as a long term incubator for lilypond features. Just a couple of
ideas from me.

I am ready, willing and able to work on OLL, so please be aware of that.

Andrew


On Wed, 7 Oct 2020 at 00:33, Jan-Peter Voigt  wrote:
>
> Hi all,
>
> I would like to repeat Urs' call to participate in the work of OLL. I
> share the opinion that it is a very versatile and powerful toolbox. My
> own contributions are mainly the edition-engraver and the
> lalily-templates. If you have any questions about what they are and how
> they work, feel free to contact me via this list or py pm.
>
> Best,
> Jan-Peter

Re: Future of openLilyLib

[Jan-Peter Voigt]

Hi all,

I would like to repeat Urs' call to participate in the work of OLL. I
share the opinion that it is a very versatile and powerful toolbox. My
own contributions are mainly the edition-engraver and the
lalily-templates. If you have any questions about what they are and how
they work, feel free to contact me via this list or py pm.

Best,
Jan-Peter

Am 21.09.20 um 17:24 schrieb Urs Liska:
> Hi all,
>
> to begin with, I am of the (biased) opinion that openLilyLib is a
> powerful and useful extension infrastructure for LilyPond. There are a
> number of versatile and extended ready-to-use packages available, most
> notably probably edition-engraver, scholarLY and anaLYsis. But also the
> underlying oll-core is versatile and powerful, providing numerous
> building blocks without which I would not start any large-scale project
> anymore.
>
> I can understand why this view is not shared by everyone, most likely
> simply because too much about OLL is obscure or unknown, lacking proper
> documentation, although the general introduction at https://openlilylib
> .org should be a good start (and there are substantial manuals for the
> scholarLY and stylesheets packages, but only in (undocumentedly) self-
> compilable form).
>
> At this point openLilyLib is completely dependent on my availability,
> at least because I am the only person with knowledge of the basic code
> in oll-core.
>
> For several reasons which I won't discuss publicly I will have to
> reduce my availablity to work on openLilyLib (and other stuff) and may
> be forced to completely withdraw at any point within the next years.
>
> I would find it a pity if that would mean the end for openLilyLib.
> Therefore I'm looking not for a new maintainer but for more people
> engaging in the project, to build a community around it that can at
> some point continue without my aid.
>
> The aspects needing support most urgently AFAICT are (in descending
> order):
>
>  * getting more people familiar with oll-core (using the opportunity to
>maybe improve the coding where appropriate)
>  * complete the documentation system in order to make a more complete
>documentation feasible (here the most crucial part is integrating
>consistently scalable score examples in the web site output).
>  * getting more people familiar with the coding of scholarLY
>  * do maintenance of everything, maybe throwing out some less-than-
>useful packages
>  * write a Frescobaldi extension for managing (installing, updating the
>library or individual packages, preparing documents) openLilyLib and
>providing an API for secondary extensions (e.g. an annotation
>editor/viewer or a tool to graphically insert editionMods).
>
> If anything of this looks like your cup of tea you are welcome to
> contact me privately or discuss stuff on-list. Of course I am more than
> willing to help with any of these tasks.
>
> Best
> Urs
>
>