Re: Future of OpenLilyLib

Thanks Jean and Federico. I'll open a new thread on lyLuaTex, to avoid hijacking this one. -- Graham > On 23 Nov 2022, at 16:59, Federico Bruni wrote: > > In order to run lyluatex with recent versions of lilypond (2.23.x), you must > install the most recent version of lyluatex. In other word

Re: Future of OpenLilyLib

In order to run lyluatex with recent versions of lilypond (2.23.x), you must install the most recent version of lyluatex. In other words, you should install Texlive standalone and not the texlive packaged by distros. See this discussion: https://github.com/jperon/lyluatex/issues/287 Il giorn

Re: Future of OpenLilyLib

Le 23/11/2022 à 16:31, Graham King a écrit : I've tried to get Scholarly working in the past, but failed. I'm currently failing to get lyluatex working. There are some really promising tools in OpenLilyLib, but they seem to require someone with Urs' level of focus and intellect to use them.

Re: Future of OpenLilyLib

> On 22 Nov 2022, at 09:31, Mark Knoop wrote: > > Thanks to all for your responses. There seems to be a general agreement > about the desired direction but I'd still like to hear who is actually > using this code at the moment. Is it just Kieren and me? I've tried to get Scholarly working in t

Re: Future of OpenLilyLib

Hello Mark, > Yes, I think we all agree on that. At the moment there isn't, but even > if and when that might be implemented, I can still see a role for a > repository such as OpenLilyLib to collect and host those modules. Is the > future really copying blocks of code from websites or email attach

Re: Future of OpenLilyLib

Le 22/11/2022 à 08:50, Henning Hraban Ramm a écrit : ... module code ... \endModule % or whatever name ... example ... where \endModule would act as a "trap" interrupting the parsing, but only if the file is included. If the file is compiled as main, it would continue parsing, and after \endM

Re: Future of OpenLilyLib

Mark, I use my stem slash code a lot. I don't think you should delete things willy nilly. There may be users who use stuff in OLL that do not respond in the list etc etc. Andrew

Re: Future of OpenLilyLib

Thanks to all for your responses. There seems to be a general agreement about the desired direction but I'd still like to hear who is actually using this code at the moment. Is it just Kieren and me? ### Usage Several people mentioned difficulties using OLL. - how to install? - what does it do?

Re: Future of OpenLilyLib

Am 21.11.22 um 23:28 schrieb Jean Abou Samra: One would add a new keyword in the parser akin to \include (\import? \load?). How about \require? ... module code ... \endModule % or whatever name ... example ... where \endModule would act as a "trap" interrupting the parsing, but only if

Re: Future of OpenLilyLib

On Mon, Nov 21, 2022, 6:11 PM Andrew Bernard wrote: > it costs money for me to run the server > What storage and RAM is needed? I might be able to host it for you. -- Karlin High Missouri, USA >

Re: Future of OpenLilyLib

I may as well shutdown openlilylib.space then. There are only 15 users, and it costs money for me to run the server, and there is zero traffic on Discourse. Andrew On 22/11/2022 9:22 am, Jean Abou Samra wrote: Le 21/11/2022 à 23:19, Andrew Bernard a écrit : Hello All, Why don't we keep the

Re: Future of OpenLilyLib

Hi Jean, > I would change the tense: > > [Independently of OLL,] non core developers *are* able to implement > new features with Scheme code that *can* potentially be included in > base LilyPond if proven reasonable. > > Don't you agree? I do agree that users are able to implement feature with

Re: Future of OpenLilyLib

Hi Jean, > The first step to adding non-trivial things that need discussion > is opening an issue. Do you feel like doing that? https://gitlab.com/lilypond/lilypond/-/issues/6475 Look at me, being all “Do first” ’n’ stuff… ;) We taking the discussion over there? K

Re: Future of OpenLilyLib

Le 21/11/2022 à 23:02, Kieren MacMillan a écrit : Then they should definitely be added: those were things Urs and I discussed (a fair bit off-list) as principle obstacles to the integration of “external” code (mostly equivalent to OLL at the time) into the ’Pond ecosystem. The first step to

Re: Future of OpenLilyLib

Le 21/11/2022 à 23:19, Andrew Bernard a écrit : Hello All, Why don't we keep the discussion about OLL on the OLL Discourse forum I created and run? That's the whole point of it, and to avoid cluttering the Lilypond User list. I think Mark's goal was to reach LilyPond users who are only casu

Re: Future of OpenLilyLib

Hello All, Why don't we keep the discussion about OLL on the OLL Discourse forum I created and run? That's the whole point of it, and to avoid cluttering the Lilypond User list. It's free to sign and and join. Otherwise I am running the website for nothing. https://openlilylib.space All a

Re: Future of OpenLilyLib

Hello Karlin, I’m sure no one who engages on the list will feel burdened by your questions, in the worst case they might just not engage with it and ignore it, that is as long as you talk nicely and do not demand for things (as the people here are doing this because they want to in their spare

Re: Future of OpenLilyLib

Hi all, > I don't think we're very far from that. Include files already work > as kinds of modules. I only see two potential differences between modules > and include files: > > - a module should only be loaded once, even if imported twice in > different locations, > > - a module could (option

Re: Future of OpenLilyLib

Le 21/11/2022 à 22:38, Valentin Petzel a écrit : In my opinion it is not bad to allow for modular extension of Lilypond, especially for things that do not fit the core of the program. You need to keep in mind that this would be a strong possibility of enhancing Lilypond without cluttering it’s co

Re: Future of OpenLilyLib

Hello Jean, Hello All, I think the main problem with OLL is that it tries to provide some sort of equivalent of the STL for Lilypond. Thus is packs a lot of functionality in one big chunk that is hard to organize and hard to maintain, feeling like a big, alien thing. In my opinion it is not ba

Re: Future of OpenLilyLib

Le 21/11/2022 à 21:55, Kieren MacMillan a écrit : cf. our past discussions (some on -devel, some private) about my attempts to add code, where it should go, etc. =) Yes, I remember that :-) 2. Obviously I use oll-core, since that is foundational to the EE. Note: oll-core is a somewhat

Re: Future of OpenLilyLib

Hi all, > Maybe what I'm going to say will sadden some, but personally, > I never quite understood what the advantage of developing > openLilyLib as a library external to LilyPond, as opposed to > contributing features to LilyPond itself, was supposed to be. cf. our past discussions (some on -dev

Re: Future of OpenLilyLib

On 11/21/2022 11:09 AM, Mark Knoop wrote: It would be good to get a feel from users how much this resource isused I have heard lots of good things about OpenLilyLib. But I remain somewhat unclear as to what it offers and how it would be used in my usages for SATB/TTBB shape-note hymns and lig

Re: Future of OpenLilyLib

Le 21/11/2022 à 20:02, Mark Knoop a écrit : Thanks Jean for your thoughts, which are not so far from my own. A few comments: Maybe what I'm going to say will sadden some, but personally, I never quite understood what the advantage of developing openLilyLib as a library external to LilyPond, as

Re: Future of OpenLilyLib

Thanks Jean for your thoughts, which are not so far from my own. A few comments: > Maybe what I'm going to say will sadden some, but personally, > I never quite understood what the advantage of developing > openLilyLib as a library external to LilyPond, as opposed to > contributing features to Lil

Re: Future of OpenLilyLib

Maybe what I'm going to say will sadden some, but personally, I never quite understood what the advantage of developing openLilyLib as a library external to LilyPond, as opposed to contributing features to LilyPond itself, was supposed to be. I was going to add my lyrics code to LSR, actually. It

Future of OpenLilyLib

With the imminent release of LilyPond 2.24, I thought it would be good to (once again) raise the topic of OpenLilyLib. There has been some recent movement on this (thanks to Jean and Andrew) to get the code mostly working with recent LilyPond versions and Guile 2. I have also just pushed a bunch o

Re: Once for all and one last time (was Future of openLilyLib)

> Am 10.10.2020 um 17:49 schrieb Andrew Bernard : > > There's a term for it. Necroposting! Seriously! I’m proud of my necromancer badge on stackexchange ;D HR

Re: Once for all and one last time (was Future of openLilyLib)

There's a term for it. Necroposting! Seriously! Andrew On Sun, 11 Oct 2020 at 02:24, David Kastrup wrote: > Two weeks? I've replied on occasion to threads that were 10 years old, > basically because threads tends to be archived and turn up on keyword > searches.

Re: Once for all and one last time (was Future of openLilyLib)

Simon Albrecht writes: >> On 10.10.20 14:11, Simon Albrecht wrote: >>> Dear Karsten and list, >>> >>> On 22.09.20 22:40, Karsten Reincke wrote: 5) I've learned, that all(?) of you consider this an untenable if not silly position and that the PDFs and midi-files compiled by Lilypond

Re: Once for all and one last time (was Future of openLilyLib)

There’s no such thing as retracting an e-mail, but I would like to do it. Sorry for failing to realise how old the thread was before replying. Best, Simon On 10.10.20 14:11, Simon Albrecht wrote: Dear Karsten and list, On 22.09.20 22:40, Karsten Reincke wrote: 5) I've learned, that all(?) of

Re: Once for all and one last time (was Future of openLilyLib)

Simon Albrecht writes: > Dear Karsten and list, > > On 22.09.20 22:40, Karsten Reincke wrote: >> 5) I've learned, that all(?) of you consider this an untenable if >> not silly position and that the PDFs and midi-files compiled by >> Lilypond are never affected by the strong copyleft effect of the

Re: Once for all and one last time (was Future of openLilyLib)

Dear Karsten and list, On 22.09.20 22:40, Karsten Reincke wrote: 5) I've learned, that all(?) of you consider this an untenable if not silly position and that the PDFs and midi-files compiled by Lilypond are never affected by the strong copyleft effect of the GPL. That's good to hear. But I do

Re: Future of openLilyLib

Le 07/10/2020 à 16:30, Federico Bruni a écrit : Il giorno mer 7 ott 2020 alle 16:24, Jean Abou Samra ha scritto: PPS: I see you shut down openlilylib.org. Is the source archived somewhere  so I can better understand openLilyLib? I think it's here: https://github.com/openlilylib-documentati

Re: Future of openLilyLib

Il giorno mer 7 ott 2020 alle 16:24, Jean Abou Samra ha scritto: PPS: I see you shut down openlilylib.org. Is the source archived somewhere so I can better understand openLilyLib? I think it's here: https://github.com/openlilylib-documentation/main-site/

Re: Future of openLilyLib

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

Re: Future of openLilyLib

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

Re: Future of openLilyLib

rtphone Get Outlook for Android<https://aka.ms/ghei36> 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

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 n

Re: Future of openLilyLib

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

Re: Future of openLilyLib

\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

Re: Future of openLilyLib

>> \reshape ? > > Dude… nice work. =) Care to submit a MR? Werner

Re: Future of openLilyLib

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

> \reshape ? Dude… nice work. =) Kieren. Kieren MacMillan, composer (he/him/his) ‣ website: www.kierenmacmillan.info ‣ email: kie...@kierenmacmillan.info

Re: Future of openLilyLib

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 mig

Re: Future of openLilyLib

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 i

Re: Future of openLilyLib

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 l

Re: Future of openLilyLib

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 fre

Re: Future of openLilyLib

Hi all, I guess the problem raised here is tough (is LilyPond a markup language or a programming library, since you in fact mix notes and Scheme programs?). Nevertheless, I'd like to make a point that seems to have been overlooked so far: it's absolutely impossible to change the licensing of Lil

RE: Future of openLilyLib

> -Original Message- > From: David Kastrup > Sent: Tuesday, September 22, 2020 8:12 AM > To: Karsten Reincke > Cc: lilypond-user@gnu.org; Carl Sorensen > Subject: Re: Future of openLilyLib > > Karsten Reincke writes: > > > Summary: > > > &g

Once for all and one last time (was Future of openLilyLib)

Dear ML members; The thread becomes longer and longer. Hence I am going to summarize my concerns and won't repeat myself never again: 1) In the beginning, there was the ask of Urs to be supported by developing OLL because he wants to reduce his efforts. For making OLL a little more welcoming

Re: Future of openLilyLib

Hi Karsten, I gratefully appreciate your work on LilyPond. Because of your friendly and affectionate way of sharing your knowledge in this mailing list - as I was allowed to experience it in the past - I also want to believe that OpenLilylib is valuable. Personally, I refrained from familiari

Re: Licensing (was: Future of openLilyLib)

> Am 22.09.2020 um 19:29 schrieb Tim McNamara : > I am curious- is there a parallel discussion among LaTeX users? I’ve never > used LaTeX nor been part of discussions in the that community, but the > operating similarities are strong (a text input file with formatting markup > producing an o

Re: Future of openLilyLib

Sorry, I meant naturally Mr. Reincke, and not Mr. Karsten ;-). www.martinrinconbotero.com On 22. Sep 2020, 19:30 +0200, Tim McNamara , wrote: > On Sep 22, 2020, at 10:20 AM, Partitura Organum > wrote: > > > > Karsten […] mentioned the lilypond-files: "OpenLilyLib is licensed under > > the GPL.

Re: Future of openLilyLib

I probably shouldn’t be saying anything about this because I’m not an expert in licensing. However, Mr. Karsten’s assertion that “my work depends on OLL, not because I use lilypond, but because I functions of the OLL” is wrong. It implies that the content of a Lilypond file is dependent on Lilyp

Re: Future of openLilyLib

On Sep 22, 2020, at 10:20 AM, Partitura Organum wrote: > > Karsten […] mentioned the lilypond-files: "OpenLilyLib is licensed under the > GPL. Thus, the copyleft effect forces that all Lilypond files which include > OpenLilyLib files, have also to be distributed under the terms of the GPL.". >

Re: Future of openLilyLib

On Sep 22, 2020, at 10:17 AM, Karsten Reincke wrote: > On 22.09.20 14:58, Tim McNamara wrote: >>> On Sep 22, 2020, at 4:30 AM, Karsten Reincke >>> wrote: >>> Dear Carl; >>> >>> here is my explanation using the method of showing an analogy: >>> >> >> >> >> If I

Re: Future of openLilyLib (to Gilles and David

On 9/22/2020 10:50 AM, Karsten Reincke wrote: 2.B) But if yes, 'my' HelloWorld 'song' depends on the program ly- and/or scm files under /usr/share/lilypond/2.20.0/. They are licensed under the GPLv3. Thus, we have to deal with copyleft effect in any sense because a GPL v3 licensed code is integ

Re: Future of openLilyLib

On 22.09.20 14:58, Tim McNamara wrote: On Sep 22, 2020, at 4:30 AM, Karsten Reincke wrote: Dear Carl; here is my explanation using the method of showing an analogy:  If I use Emacs to write a letter to my Aunt Tillie, even though Emacs is licensed under the GPL my letter to Aunt Tillie

Re: Future of openLilyLib

Dear Carl; many thanks for your remarks, You'll find my answers int the text too On 22.09.20 15:49, Carl Sorensen wrote: [...] But here is where you lost me.  The program using guile-aspell must be released under the terms of GPL-v3. But the output of the program need not be released under

Re: Future of openLilyLib (to Gilles and David

On 22.09.20 13:05, Gilles Sadowski wrote: Hi. Moving back to the ML; it was not my intention to discuss this "off-list"; I hope I won't be sued for public disclosure of a private communication. ;-) No problem! Moreover, I appreciate your respectful way to clarify understandings before jumping

Re: Future of openLilyLib

On 22-9-2020 15:49, Carl Sorensen wrote: Since the music code is not included in the pdf output, the pdf output is not subject to GPL. The fact, that Mr. Bernard apparently does not want to realize point 5., puzzles me. I remain respectfully yours Karsten Reincke The ina

Re: Future of openLilyLib

On 22.09.20 14:58, Tim McNamara wrote: On Sep 22, 2020, at 4:30 AM, Karsten Reincke wrote: Dear Carl; here is my explanation using the method of showing an analogy: You are conflating the GPL as applied to functional software versus the rights of the user for the content produced throu

Re: Future of openLilyLib

On Tue, Sep 22, 2020 at 3:08 AM Karsten Reincke wrote: > Dear Carl; > > here is my explanation using the method of showing an analogy: > > > (1.A) MIT/GNU Scheme: > (a) is an interpreter of the Scheme programming language > (b) is licensed under the GPL > (c) takes Scheme Code & delivers output >

Re: Future of openLilyLib

> On Sep 22, 2020, at 4:30 AM, Karsten Reincke wrote: > Dear Carl; > > here is my explanation using the method of showing an analogy: > You are conflating the GPL as applied to functional software versus the rights of the user for the content produced through the use of that functional soft

Re: Future of openLilyLib

Jacques Menu writes: > Hello everybody, > > The legal subtleties of public licensing never made their way into my > mind, sorry for being limited… > What would the difference be, should openLilyLib use LGPL instead of GPL? You could use and distribute OLL derivatives integrated with non-GPL lice

Re: Future of openLilyLib

Karsten Reincke writes: > Dear Carl; > > here is my explanation using the method of showing an analogy: > > > (1.A) MIT/GNU Scheme: > (a) is an interpreter of the Scheme programming language > (b) is licensed under the GPL > (c) takes Scheme Code & delivers output > > (https://www.gnu.org/softwar

Re: Future of openLilyLib

Carl Sorensen writes: > On Mon, Sep 21, 2020 at 4:00 PM Karsten Reincke wrote > > >> >> We had this discussion a year ago and I won't repeat the details. The >> last time it ended in a kind of unfruitful shitstorm which did not >> help anyone. But if you now look for supporters, you have to see

Re: Future of openLilyLib

Hi. Moving back to the ML; it was not my intention to discuss this "off-list"; I hope I won't be sued for public disclosure of a private communication. ;-) [See quoted text for the two messages that went off-list.] 2020-09-22 12:40 UTC+02:00, Karsten Reincke : > > On 22.09.20 12:17, Gilles Sadow

Re: Future of openLilyLib

Dear Carl; here is my explanation using the method of showing an analogy: (1.A) MIT/GNU Scheme: (a) is an interpreter of the Scheme programming language (b) is licensed under the GPL (c) takes Scheme Code & delivers output (https://www.gnu.org/software/mit-scheme/) => Any Scheme code being ta

Re: Future of openLilyLib

Am Dienstag, den 22.09.2020, 17:29 +1000 schrieb Andrew Bernard: > What would the difference be should _lilypond_ use LGPL instead of > GPL? I'm sorry, I think the OP amounts to a type of elaborate > trolling > of the community. Nothing needs changing. I think so too. > > This has all been gone

Re: Future of openLilyLib

What would the difference be should _lilypond_ use LGPL instead of GPL? I'm sorry, I think the OP amounts to a type of elaborate trolling of the community. Nothing needs changing. This has all been gone through. I can only perceive this as an attempt to damage openlilylib in people's minds (heaven

Re: Future of openLilyLib

Hello everybody, The legal subtleties of public licensing never made their way into my mind, sorry for being limited… What would the difference be, should openLilyLib use LGPL instead of GPL? JM > Le 22 sept. 2020 à 02:34, Andrew Bernard a écrit : > > Karsten, despite your lengthy discourse

Re: Future of openLilyLib

Karsten, despite your lengthy discourse on licensing, I am sure you have the wrong end of the stick here. Your unique interpretation of GPL in relation to lilypond is not shared by anybody as far as I know. Users are happily producing scores and works not subject to having to provide source code. I

Re: Future of openLilyLib

On Mon, Sep 21, 2020 at 4:00 PM Karsten Reincke wrote > > We had this discussion a year ago and I won't repeat the details. The > last time it ended in a kind of unfruitful shitstorm which did not help > anyone. But if you now look for supporters, you have to see that your > license model reduce

Re: Future of openLilyLib

Dear Urs; I gratefully appreciate your work on LilyPond. Because of your friendly and affectionate way of sharing your knowledge in this mailing list - as I was allowed to experience it in the past - I also want to believe that OpenLilylib is valuable. Personally, I refrained from familiarizin

Future of openLilyLib

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