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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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:

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

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

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 OLL? There are surely many who

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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