Re: Openlilylib questions
Hi Andrew, > Since handing over OLL I have lost track of processes. What is the > communications platform for queries and discussions now? This mailing list seems best. > And are we in fact still open for business? I need to submit a pull > request to add some code for my slash stem functions which somehow > never made it in. Yes - please do so in the relevant github repo. Cheers, M -- Mark Knoop
Re: Openlilylib questions
Are we taking pull requests. Sorry my metaphor may not have been clear! On 7 April 2023 10:17:51 pm AEST, Jean Abou Samra wrote: > > >> Le 7 avr. 2023 à 14:06, Andrew Bernard a écrit : >> >> Since handing over OLL I have lost track of processes. What is the >> communications platform for queries and discussions now? > > >I don’t think anything has been set up to replace your Discourse server, but >GitHub issues are still there. > > >> And are we in fact still open for business? > >What does that mean in practical terms? > > >
Re: Openlilylib questions
> Le 7 avr. 2023 à 14:06, Andrew Bernard a écrit : > > Since handing over OLL I have lost track of processes. What is the > communications platform for queries and discussions now? I don’t think anything has been set up to replace your Discourse server, but GitHub issues are still there. > And are we in fact still open for business? What does that mean in practical terms?
Openlilylib questions
Since handing over OLL I have lost track of processes. What is the communications platform for queries and discussions now? And are we in fact still open for business? I need to submit a pull request to add some code for my slash stem functions which somehow never made it in. Andrew
Re: Openlilylib repository
At 21:50 on 09 Feb 2023, Andrew Bernard wrote: > I seem to have become completely detached from OLL. > Where is the repository located now? The only repos I can find are > last modified 6-10 years ago. The repositories are here. (You can sort them by last updated to see the active ones more easily.) https://github.com/orgs/openlilylib/repositories As I mentioned a while ago I would like to convert the oldest one to an "entry-point" to help with visibility - see https://github.com/openlilylib/openlilylib/pull/1 Unfortunately I don't have any rights over that repo to merge this. -- Mark Knoop
Openlilylib repository
I seem to have become completely detached from OLL. Where is the repository located now? The only repos I can find are last modified 6-10 years ago. Andrew
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 words, you should > install Texlive standalone and not the texlive packaged by distros. > > See this discussion: > https://github.com/jperon/lyluatex/issues/287 > > > Il giorno mer 23 nov 2022 alle 17:55:34 +0100, Jean Abou Samra > ha scritto: >> 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. This >>> thread is raising my hopes once more. >> I'd suggest you open a new thread about lyLuaTeX, with details >> of your problems getting it to run. >> (Note that lyLuaTeX isn't part of openLilyLib.) >> Best, >> Jean > >
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 giorno mer 23 nov 2022 alle 17:55:34 +0100, Jean Abou Samra ha scritto: 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. This thread is raising my hopes once more. I'd suggest you open a new thread about lyLuaTeX, with details of your problems getting it to run. (Note that lyLuaTeX isn't part of openLilyLib.) Best, Jean
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. This thread is raising my hopes once more. I'd suggest you open a new thread about lyLuaTeX, with details of your problems getting it to run. (Note that lyLuaTeX isn't part of openLilyLib.) Best, Jean OpenPGP_signature Description: OpenPGP digital signature
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 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. This thread is raising my hopes once more.
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 attachments > and saving them to randomly organized local files? If at some point Lilypond would have the capabilities to use modules that might be packaged and distributed I think this part of OLL could turn into some sort of centralized archive like CTAN, or into a centralized index, refering to the packages themselfes. I do not think that OLL as a giant git repository of packages makes a lot of sense in the terms of maintainence though. Cheers, Valentin signature.asc Description: This is a digitally signed message part.
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 \endModule you could put some examples and tests for the snippet / module functionality. That is how module documentation in TeX works (as you are probably aware). I don’t think many users would look into that, esp. since LilyPond’s documentation is more concise and centralized. I wasn't even aware that TeX used a similar principle :-) However, I wouldn't see a lot of value to it for documentation. Maybe it would have some value for usage examples. Best, Jean OpenPGP_signature Description: OpenPGP digital signature
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? - combersome, unwieldy, unmaintained This is the prime reason I decided to propose this reorganization. I have started work to improve documentation and plan to work through most of it incrementally. See below re maintenance. ### Shouldn't this all be in LilyPond or LSR? Possibly, but it isn't at the moment. Certainly there are features in OLL which could/should be moved into LilyPond, and some which already have been. I believe maintaining _and_ **using** that code in the meantime is the best way to a) work out which features should be prioritized, and b) come to some agreement about interfaces and syntax for those features. _Shouldn't this be done in code review as part of adding to LilyPond directly?_ Possibly, but users are not always able to be focussed on this at the time of development. If I'm engraving a score which is due next week and need to do X then I'm most likely to write/adapt/hack together something which works "well-enough" to get the score out next week. I almost certainly won't have time to polish it to the point of submitting, and following up, a merge request to LilyPond. But I might be able to include it as an OLL module which somebody else might see and either improve, use to solve a different problem, expand, etc. LSR has it's own set of problems, some of which have already come up in this thread. ### There should be a better/easier way to include modular code in LilyPond 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 attachments and saving them to randomly organized local files? In the meantime, OLL (mostly) works and can be improved with better documentation. ### Maintenance At the moment I use several parts of the OLL (mostly edition-engraver, scholarly and bits from oll-misc) and so will keep maintaining them. I'm also happy to help maintain any other parts which are used by others. I'd like to identify what _isn't_ used so it can be marked as unmaintained/deprecated/scavenged for parts. Regards, Mark -- Mark Knoop
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 the file is included. If the file is compiled as main, it would continue parsing, and after \endModule you could put some examples and tests for the snippet / module functionality. That is how module documentation in TeX works (as you are probably aware). I don’t think many users would look into that, esp. since LilyPond’s documentation is more concise and centralized. Otherwise I’ll leave this discussion to you, since I never need the more sophisticated features of LilyPond for my folk songs and odd other piece. Thank you for your work! Hraban
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 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 casual users of OLL. I would prefer not to move the thread now that it has started here, it always makes things confusing... Jean
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 Scheme code, but handling of such code is usually a matter of copying snippets, eventually outsourcing them into a file. With a module interface a user could implement his feature as module and publish this module. Then it would be very easy for other users to use this feature in own project, and we might see: Some modules are experiencing so frequent use that they might be well suited for actually being part of core Lilypond. I did not intent to say that non core developers have absolutely no way of testing out functions, but that it would be much easier to have an ecosystem where such functions can be tested. > It is true that not every feature fits. However, in practice, I > have encountered few features that fit neither in an LSR > snippet, nor in LilyPond's core, nor as some kind of mix between > the two where the core receives some generic tools useful for > other purposes as well, while the LSR snippet makes use of these > tools for a very specific purpose. But this might just be a result of the missing infrastructure :). If the extension methods we offer are simply snippets then it is clear that we will mostly get snippets and be bound to snippets. On the other hand a module could be thought as a snippet+. > - a module should only be loaded once, even if imported twice in > different locations, > - a module could (optionally?) have its own namespace (Guile module >object) with private definitions, and only export the definitions >it needs. I think Include files provide something similar to loading modules, but in the most primitive form possible, that is simply text insertion. I do agree on your points. @1: A Lilypond file could simply start with a declaration of required modules, which are then sourced at the start. @2: Definitely sensible, unnamespaced modules are prone to unwanted behaviour. I’d add that a module could not only contain ly files but also scm files, and they could be loaded similar to base Lilypond’s scm/* and ly/* files, allowing for control bigger than a single session. Then we could simply use define-public for public definitions. Cheers, Valentin signature.asc Description: This is a digitally signed message part.
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 adding non-trivial things that need discussion is opening an issue. Do you feel like doing that? I feel like the moment we have a real module system, two things will happen fairly quickly: 1. Many \include files (which are, to be fair, pretty cumbersome, especially in any reasonably complex file set) will become modules… and modular stylesheets will suddenly become exponentially less of a headache to implement. 2. The uptake (and thus maintenance) of really-helpful-but-currently-obscure code (e.g., the EE) will ramp up. What’s required to add those two things you’re talking about? One would add a new keyword in the parser akin to \include (\import? \load?). Not importing a module more than once should be almost trivial (just remember which modules have already been imported). The namespacing thing is less trivial, but you can probably get along by creating a new parser, and use-module! its namespace into the main file's namespace, or its public interface if you want to get public names only. You'd also need some sort of syntax like \public var = val e.g. \public func = #(define-music-function ...) as an equivalent of #(define-public var val) Again, some hacking time but nothing hard if you know a bit about the parser, really. (But the entry barrier to the parser *is* high.) One additional idea of mine in the category of "I don't know if it's a good or a bad idea" is structuring LSR snippets / modules as ... 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 \endModule you could put some examples and tests for the snippet / module functionality. Jean OpenPGP_signature Description: OpenPGP digital signature
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 casual users of OLL. I would prefer not to move the thread now that it has started here, it always makes things confusing... Jean OpenPGP_signature Description: OpenPGP digital signature
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 are welcome. Andrew On 22/11/2022 4:09 am, Mark Knoop wrote: With the imminent release of LilyPond 2.24, I thought it would be good to (once again) raise the topic of OpenLilyLib.
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 time this can be one hell of a turn-off. We do not *serve* the community, we *are* the community). Generally I think we feel glad about people of all levels joining and being in the community, and I do not think anyone here has problems with not all questions being on the most obscure Lilypond level. Maybe unless they are questions that can easily be answered by reading a small bit of documentation. Cheers, Valentin Am Montag, 21. November 2022, 20:43:29 CET schrieb Karlin High: > 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 light choral works. > > My first experience with OLL was downloading the zip folder with it, > just to start poking it with sticks and see what it does. I extracted > the zip, tried to use with LilyPond on Windows, and got lots of file > path errors about not being able to find things or do anything. > > It seemed like I could not find "a way in" to making use of it. > > Asking questions on the lists and such left me feel like I was burdening > the developers for it, needing "explain it like I am 5 years old" > efforts when they could best serve the community by exploring and > advancing the limits of LilyPond's capabilities with others who were > already up to speed in the relevant areas. > > I still have a dream project of using LilyPond to produce a new edition > of a hymnal containing 467 songs. The Edition Engraver seems like a > must-have for that. signature.asc Description: This is a digitally signed message part.
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 (optionally?) have its own namespace (Guile module > object) with private definitions, and only export the definitions > it needs. > > None of these two would be very complicated to add to LilyPond. 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. I feel like the moment we have a real module system, two things will happen fairly quickly: 1. Many \include files (which are, to be fair, pretty cumbersome, especially in any reasonably complex file set) will become modules… and modular stylesheets will suddenly become exponentially less of a headache to implement. 2. The uptake (and thus maintenance) of really-helpful-but-currently-obscure code (e.g., the EE) will ramp up. What’s required to add those two things you’re talking about? Thanks, Kieren.
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 core. It is true that not every feature fits. However, in practice, I have encountered few features that fit neither in an LSR snippet, nor in LilyPond's core, nor as some kind of mix between the two where the core receives some generic tools useful for other purposes as well, while the LSR snippet makes use of these tools for a very specific purpose. And if non core developer were able to implement new features in modules that could potentially be included into base Lilypond if proven reasonable it might become easier to contribute to Lilypond. 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? This is a big part of the reason why languages like python are so popular. But the OLL implementation is just unwieldy and hard to maintain. Currently if I were to develop an OLL module for Lilypond I would face two problems: Any potential user first must be motivated to install OLL, which is a cluttered and unintuitive process. And then my package would constantly depend on OLL being maintained. Thus I think what would be more sustainable is if we had an module interface that is well maintained (eventually to the point of maintaining against multiple Lilypond versions), and individual packages using this interface. 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 (optionally?) have its own namespace (Guile module object) with private definitions, and only export the definitions it needs. None of these two would be very complicated to add to LilyPond. Even more promising would be if Lilypond itself were to allow for modules, which would eliminating the need for oll-core at all (also this would even allow for more crazy stuff, like packaging specifying code that is executed at different stages). But as it stands I’m not sure if OLL can be maintained. We’ve seen how quickly OLL falls if a handful of people fall away, and what we face here is basically an uphill battle trying to keep that thing maintained (not even talking about further developing it). Yes. Best, Jean OpenPGP_signature Description: OpenPGP digital signature
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 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 core. And if non core developer were able to implement new features in modules that could potentially be included into base Lilypond if proven reasonable it might become easier to contribute to Lilypond. This is a big part of the reason why languages like python are so popular. But the OLL implementation is just unwieldy and hard to maintain. Currently if I were to develop an OLL module for Lilypond I would face two problems: Any potential user first must be motivated to install OLL, which is a cluttered and unintuitive process. And then my package would constantly depend on OLL being maintained. Thus I think what would be more sustainable is if we had an module interface that is well maintained (eventually to the point of maintaining against multiple Lilypond versions), and individual packages using this interface. Even more promising would be if Lilypond itself were to allow for modules, which would eliminating the need for oll-core at all (also this would even allow for more crazy stuff, like packaging specifying code that is executed at different stages). But as it stands I’m not sure if OLL can be maintained. We’ve seen how quickly OLL falls if a handful of people fall away, and what we face here is basically an uphill battle trying to keep that thing maintained (not even talking about further developing it). Cheers, Valentin Am Montag, 21. November 2022, 18:54:50 CET schrieb Jean Abou Samra: > 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's just > more convenient for users to grab, and it's not like this is > a very large piece of code that really needs version control > (although version control in LSR *would* be nice). > > To be honest, although I wasn't there at the time, it is my > impression that this split was partly motivated by some personal > conflicts that reduced Urs' willingness to submit patches to > LilyPond, which is not relevant for us today. > > Some of the OLL stuff has been made part of LilyPond over the > years, for example Merge_mmrest_numbers_engraver and \vshape. > There is also \staffHighlight, which serves a purpose that > overlaps a bit with the purpose of AnaLYsis. Long-term, I would > like to see edition-engraver go that route as well (with a > better, iterator-based implementation). > > So it's a shrug from me: I thank you for your effort in making > the code 2.23.81-compatible, and I'm fine with any reorganizations > you want to make, but I will always feel that this code is not > really at home. > > Best, > Jean > signature.asc Description: This is a digitally signed message part.
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 haphazard bag of stuff, some of which is useful, some of which has already been integrated to LilyPond (like ly:version?, added by Urs himself), and some of which ... cough, doesn't make a lot of sense to me (options, property sets and presets). There are things to “clean out” there too. Best, Jean OpenPGP_signature Description: OpenPGP digital signature
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 -devel, some private) about my attempts to add code, where it should go, etc. =) > To be honest, although I wasn't there at the time, it is my > impression that this split was partly motivated by some personal > conflicts that reduced Urs' willingness to submit patches to > LilyPond, which is not relevant for us today. The patch-discussion and -submission process has definitely been an impediment to many developers in the past. > I would like to see edition-engraver go that route as well > (with a better, iterator-based implementation). You know you’re preaching to the choir here… ;) [Mark] > It would be good to get a feel from users how much this resource is > used, and which bits are most important to maintain. 1. I use the edition-engraver on everything more complicated than a MWE or “music theory exercise” [and sometimes I even use it for those! LOL]. 2. Obviously I use oll-core, since that is foundational to the EE. 3. I use stylesheets and notation/font selection and breaks for everything BUT not the OLL frameworks which either never really got built out (stylesheets) or I've just never had enough breathing room to study (fonts and breaks); if those WERE built out, well-documented, and clearly optimized, I would consider those to be essential "bits". Lots of thoughts on OLL and modular code integration etc., but will wait for concrete questions to answer. Best, Kieren.
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 light choral works. My first experience with OLL was downloading the zip folder with it, just to start poking it with sticks and see what it does. I extracted the zip, tried to use with LilyPond on Windows, and got lots of file path errors about not being able to find things or do anything. It seemed like I could not find "a way in" to making use of it. Asking questions on the lists and such left me feel like I was burdening the developers for it, needing "explain it like I am 5 years old" efforts when they could best serve the community by exploring and advancing the limits of LilyPond's capabilities with others who were already up to speed in the relevant areas. I still have a dream project of using LilyPond to produce a new edition of a hymnal containing 467 songs. The Edition Engraver seems like a must-have for that. -- Karlin High Missouri, USA
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 opposed to contributing features to LilyPond itself, was supposed to be. Having just looked through quite a lot of the code in openLilyLib, I think there will always be code there that is not suitable for inclusion in LilyPond, for many reasons (highly specialized use cases, code which works just-well-enough™, etc...). It's no criticism of the core LilyPond developers to acknowledge that not every desired feature will be accepted, and even if so, there is still a significantly higher hurdle to contributing to LilyPond than to OpenLilyLib (and rightly so). That is true. On the other hand, the hurdle for contributing to LilyPond is already significantly lower than it used to be a few years ago (we migrated to GitLab, large parts of the contributor's guide were rewritten, ...). It's all a tradeoff. The less requirements you put on quality, the more maintenance trouble you get (and there is an inherent maintenance trouble related to the fact that OLL is not usually constrained to a single version of LilyPond, although you are proposing to make it so in the short period until 2.24). Almost all programming languages have non-core features which are developed in a modular way - this fact would seem to support the case for something similar for LilyPond. A Python library for scientific computing has absolutely nothing to do with a Python library for creating web pages, so the developers have no reason to tie themselves together. In contrast, music typesetting is an intricate task with dependencies everywhere. I see two advantages over LSR, the primary one being version control (which includes being able to search it locally with git grep); the other being the potential to include code which is larger in scale and interacts sensibly. (Once you start importing several LSR snippets into one project, the potential for adverse side-effects becomes > 0.) I dream of a remake of LSR that would fix its problems (lack of history / version control, LSR editors don't know who submitted a snippet and are not notified about it, things like that). On the other hand, when I see a large snippet of useful code, my first reaction is normally to wonder how some of it could be turned into a patch. To be honest, although I wasn't there at the time, it is my impression that this split was partly motivated by some personal conflicts that reduced Urs' willingness to submit patches to LilyPond, which is not relevant for us today. Indeed, this isn't relevant, except to acknowledge that for whatever reason, there is at the moment a bunch of useful stuff which is a) not yet in LilyPond, and b) bit-rotting until it is dealt with. Yes. Some of the OLL stuff has been made part of LilyPond over the years, for example Merge_mmrest_numbers_engraver and \vshape. There is also \staffHighlight, which serves a purpose that overlaps a bit with the purpose of AnaLYsis. Long-term, I would like to see edition-engraver go that route as well (with a better, iterator-based implementation). Absolutely I'd also love to see this. (Another task which I didn't put in my first email is to clean out code that *has* made it into LilyPond.) Whilst I was able to fix-up the edition-engraver for Guile 2, I am certainly not up to rewriting it "better" - and I don't expect anybody else to do that either. Iterators are currently not Scheme-accessible anyway. It would have to be done on the C++ level. My hope is that by making OLL a little more usable and less chaotic, it might be possible to identify firstly which features are being most used, and secondly use that information to prioritize moving those into LilyPond in the best way possible. Good. Best, Jean OpenPGP_signature Description: OpenPGP digital signature
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 LilyPond itself, was supposed to be. Having just looked through quite a lot of the code in openLilyLib, I think there will always be code there that is not suitable for inclusion in LilyPond, for many reasons (highly specialized use cases, code which works just-well-enough™, etc...). It's no criticism of the core LilyPond developers to acknowledge that not every desired feature will be accepted, and even if so, there is still a significantly higher hurdle to contributing to LilyPond than to OpenLilyLib (and rightly so). Almost all programming languages have non-core features which are developed in a modular way - this fact would seem to support the case for something similar for LilyPond. > I was going to add my lyrics code to LSR, actually. It's just > more convenient for users to grab, and it's not like this is > a very large piece of code that really needs version control > (although version control in LSR *would* be nice). I see two advantages over LSR, the primary one being version control (which includes being able to search it locally with git grep); the other being the potential to include code which is larger in scale and interacts sensibly. (Once you start importing several LSR snippets into one project, the potential for adverse side-effects becomes > 0.) > To be honest, although I wasn't there at the time, it is my > impression that this split was partly motivated by some personal > conflicts that reduced Urs' willingness to submit patches to > LilyPond, which is not relevant for us today. Indeed, this isn't relevant, except to acknowledge that for whatever reason, there is at the moment a bunch of useful stuff which is a) not yet in LilyPond, and b) bit-rotting until it is dealt with. > Some of the OLL stuff has been made part of LilyPond over the > years, for example Merge_mmrest_numbers_engraver and \vshape. > There is also \staffHighlight, which serves a purpose that > overlaps a bit with the purpose of AnaLYsis. Long-term, I would > like to see edition-engraver go that route as well (with a > better, iterator-based implementation). Absolutely I'd also love to see this. (Another task which I didn't put in my first email is to clean out code that *has* made it into LilyPond.) Whilst I was able to fix-up the edition-engraver for Guile 2, I am certainly not up to rewriting it "better" - and I don't expect anybody else to do that either. My hope is that by making OLL a little more usable and less chaotic, it might be possible to identify firstly which features are being most used, and secondly use that information to prioritize moving those into LilyPond in the best way possible. -- Mark Knoop
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's just more convenient for users to grab, and it's not like this is a very large piece of code that really needs version control (although version control in LSR *would* be nice). To be honest, although I wasn't there at the time, it is my impression that this split was partly motivated by some personal conflicts that reduced Urs' willingness to submit patches to LilyPond, which is not relevant for us today. Some of the OLL stuff has been made part of LilyPond over the years, for example Merge_mmrest_numbers_engraver and \vshape. There is also \staffHighlight, which serves a purpose that overlaps a bit with the purpose of AnaLYsis. Long-term, I would like to see edition-engraver go that route as well (with a better, iterator-based implementation). So it's a shrug from me: I thank you for your effort in making the code 2.23.81-compatible, and I'm fine with any reorganizations you want to make, but I will always feel that this code is not really at home. Best, Jean OpenPGP_signature Description: OpenPGP digital signature
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 of commits to resolve (as far as I can tell) the remaining errors and warnings, at least in the usage examples included in the repositories. (See pull requests below.) I believe there is still an important role for OpenLilyLib - the edition-engraver in particular is an integral part of my own usage of LilyPond - and it would seem to me to be a much better vehicle than the LSR for anything more complex than small code examples. The recent discussions on the lilypond-user list regarding the \alignTo function and Jean's lyric spacing code would indicate that these would be prime contenders for inclusion. It would be good to get a feel from users how much this resource is used, and which bits are most important to maintain. Following are my impressions of the current problems with openlilylib and a proposal to (begin to) address them. ## Problems - unclear documentation - too many repositories, duplicated and out-of-date content - un-maintained code ## Proposal 1. Centralize into main 'entry-point' repository using git submodules containing newest, working code. This will contain clear instructions as to how to install `openlilylib`. 2. Update, fix or remove non-working code from this core set 3. Only target current stable LilyPond from 2.24.0 onwards (update to 2.23.81 for now) ### Core repositories I propose to include these as git submodules. - `oll-core` :: core functions - `edition-engraver`, and these packages that depend on it - `breaks`, `page-layout`, `partial-compilation` - `analysis` :: graphical highlighting of musical analysis - `ji` :: just intonation - `notation-fonts` :: manage font selection - `oll-misc` :: various helper functions - `stylesheets` :: hierarchical stylesheets - `scholarly` :: toolbox for annotating scores ### Older repositories - propose to deprecate AFAICT these are deprecated and/or unused. I propose they are "officially" dropped unless there are any regular users who are able to maintain them. - `openlilylib` :: very deprecated - turn this into the 'entry-point' repository - `LO-ly` :: moved to https://github.com/OOoLilyPond - `bezier` :: slur-attachment function and improved `\shape` - `contemporary` :: nothing here - `gridly` :: music editing in independent segments - `grob-tools` :: moved to `oll-core` - `lalily-templates` :: template package - `lilypond-export` :: export to other formats - `snippets` :: mostly moved to `oll-misc` - `templates` :: templates and predefined instruments ## Pull requests - https://github.com/openlilylib/oll-misc/pull/10 - https://github.com/openlilylib/scholarly/pull/73 - https://github.com/openlilylib/analysis/pull/17 -- Mark Knoop
Re: Openlilylib
Hi Mark, thank you! Due to a change in work, I haven't gotten around to testing your changes in depth yet, but I assume that as an OLL user, you've solved the problems so that it works. When I have it running here, I may approach you with a call for a pull request. Best Jan-Peter Am 17.07.22 um 16:56 schrieb Mark Knoop: Hi Andrew and other OLL users, At 18:24 on 27 May 2022, Andrew Bernard wrote: The upshot of that is that I suppose I should revive the OLL work. I'll recreate the dedicated server I set up, recreate the Discourse forum for discussion, and work on the git repository, then people can collaboratively work together again and I can take pull requests and so on. Just a note to say that I have forks of some of the OLL repositories on Github as follows. https://github.com/markk/oll-core https://github.com/markk/edition-engraver https://github.com/markk/partial-compilation https://github.com/markk/breaks Some of these have some minor updates to make them compatible with current LilyPond and Guile 2.2. Andrew, I'm happy for you to host an alternative repository if you prefer, but it would be good to avoid multiple forks and duplicated effort. I note a bug with the edition-engraver which can no longer address the first moment of the score. This needs further investigation (unless somebody else has already solved this?). -- Mark Knoop
Re: Openlilylib
At 15:56 on 17 Jul 2022, Mark Knoop wrote: I note a bug with the edition-engraver which can no longer address the first moment of the score. This needs further investigation (unless somebody else has already solved this?). Further to this, I've just pushed a fix for the first moment bug to my fork of the edition-engraver. The solution was to remove the conditional calling of `start-translation-timestep` and always call it. https://github.com/markk/edition-engraver/commit/cda9acb4a721c562f738e84b560dc8f7bda4df4e This also means that the partial-compilation module now works again. -- Mark Knoop
Re: Openlilylib
Hi Andrew and other OLL users, At 18:24 on 27 May 2022, Andrew Bernard wrote: The upshot of that is that I suppose I should revive the OLL work. I'll recreate the dedicated server I set up, recreate the Discourse forum for discussion, and work on the git repository, then people can collaboratively work together again and I can take pull requests and so on. Just a note to say that I have forks of some of the OLL repositories on Github as follows. https://github.com/markk/oll-core https://github.com/markk/edition-engraver https://github.com/markk/partial-compilation https://github.com/markk/breaks Some of these have some minor updates to make them compatible with current LilyPond and Guile 2.2. Andrew, I'm happy for you to host an alternative repository if you prefer, but it would be good to avoid multiple forks and duplicated effort. I note a bug with the edition-engraver which can no longer address the first moment of the score. This needs further investigation (unless somebody else has already solved this?). -- Mark Knoop
Re: Owners of GitHub openlilylib organisation
Le 06/06/2022 à 13:00, Andrew Bernard a écrit : Not exactly just fork . The use of an organisation in github is important I believe. I suppose it is silly but I wanted the name openlilylib for the org, and also to preserve all the users etc, but now it will have to be oll. How about migrating to GitLab and using gitlab.com/openlilylib? Isn't that what you did the first time? From my point of view, GitLab is on par with GitHub in terms of features, has an easier review interface, and is more friendly to FOSS. Plus, LilyPond itself uses GitLab, so it means an OLL contributor will easily start contributing to the core. Best, Jean
Re: Owners of GitHub openlilylib organisation
Not exactly just fork . The use of an organisation in github is important I believe. I suppose it is silly but I wanted the name openlilylib for the org, and also to preserve all the users etc, but now it will have to be oll. Andrew Jean Abou Samra wrote on 6/06/2022 8:47 PM: Well, I guess the way to go for you is to fork OLL at this point.
Re: Owners of GitHub openlilylib organisation
Le 06/06/2022 à 07:35, Andrew Bernard a écrit : Yes, I already wrote to him. No reply and no bounce. So I can see who the owners are from github, but asking if they are still on here. Well, I guess the way to go for you is to fork OLL at this point.
Re: Owners of GitHub openlilylib organisation
Yes, I already wrote to him. No reply and no bounce. So I can see who the owners are from github, but asking if they are still on here. Andrew Jean Abou Samra wrote on 6/06/2022 3:18 PM: Le 06/06/2022 à 05:01, Andrew Bernard a écrit : From https://github.com/orgs/openlilylib/people, it looks like that may be Janek (in CC, hoping that this address is still valid). There's also someone I don't know, Jeffery Shivers. Jean
Re: Owners of GitHub openlilylib organisation
Le 06/06/2022 à 05:01, Andrew Bernard a écrit : Are any of the owners of the openlilylib github organisation still on this list? If so, could they please contact me as I am trying to revive the OLL project. From https://github.com/orgs/openlilylib/people, it looks like that may be Janek (in CC, hoping that this address is still valid). There's also someone I don't know, Jeffery Shivers. Jean
Owners of GitHub openlilylib organisation
Are any of the owners of the openlilylib github organisation still on this list? If so, could they please contact me as I am trying to revive the OLL project. Andrew
OpenLilyLib portal
I've recreated a server to run a portal site for OpenLilyLib project and related topics. https://openlilylib.space/ I'll be making the Discourse server today, for OLL specific discussion and support. Also, I'll be providing access and support for the OLL repository on GitHub, which is after all the main point. At some time I feel the need to majorly refactor the repo codebase, but as this is disruptive I will not do this right away (and besides, it needs a lot of thinking to clean up). Andrew
OpenLilyLib portal
I've created a new server to run a portal site for OpenLilyLib project and related topics. https://openlilylib.space/ I'll be making the Discourse server today, for OLL specific discussion and support. Also, I'll be providing access and support for the OLL repository on GitHub, which is after all the main point. At some time I feel the need to majorly refactor the repo codebase, but as this is disruptive I will not do this right away (and besides, it needs a lot of thinking to clean up). Andrew
Re: Openlilylib
Welcome back, Andrew, and thanks for picking up the OLL work again! After a bit of a break I recently worked with LilyPond again and had to search the mailing list for some time to get everything up and running with the newest version and OLL again, which made me realise how much I rely on OLL whilst not having the technical knowhow to fix things myself. So your return and plans are very good news to me. Could you perhaps post a summary with all the relevant links? For example, I’m not sure if it’ll be the old GitHub repository or a fork, and I don’t think I ever knew there was a Discourse forum (or I forgot). Thanks, Peter -- Peter Crighton | Musician & Music Engraver based in Mainz, Germany https://www.petercrighton.de On Fri, 27 May 2022 at 10:28, Andrew Bernard wrote: > Hello All, > > Having had to abandon the Openlilylib (OLL) work I took over from Urs > Liska, for various reasons, in the meantime I went over to Dorico > instead of Lilypond for my work. Having spent a lot of money on Dorico > (AUD$800+) and given it my best shot for more than year, it really falls > short for the modernist work that I do, dogmatically follows the Gould > rule book and does not let you override most of that (it's what software > people call an opinionated program), crashes often with the latest > release and they cant solve it and just remain silent, and worse, the > forum which I initially thought helpful is turning out to be quite toxic > and I get a lot of personal abuse. along with deprecating comments about > the music I work on. Consequently I have binned Dorico as of yesterday > and I am coming back to lilypond. > > The upshot of that is that I suppose I should revive the OLL work. I'll > recreate the dedicated server I set up, recreate the Discourse forum for > discussion, and work on the git repository, then people can > collaboratively work together again and I can take pull requests and so on. > > I stalled initially a couple of years ago when I decided to totally > refactor the OLL github repostory, but now I think if we open it up > again as is and I work on that on the background which would be useful. > > I'll pay for the server resources out of my own pocket, but provide a > Paypal link for donations for running costs (server, domain name, etc). > > Andrew > > > >
Re: Openlilylib
Hi Andrew, sorry that your investments into Dorico didn’t work out! It’s great to have you back in the Pond :) I have been thinking that it would be nice to invest more time into Lily myself, but I don’t yet know whether/how/when I can make that happen. Best, Simon On 27/05/2022 10:24, Andrew Bernard wrote: Hello All, Having had to abandon the Openlilylib (OLL) work I took over from Urs Liska, for various reasons, in the meantime I went over to Dorico instead of Lilypond for my work. Having spent a lot of money on Dorico (AUD$800+) and given it my best shot for more than year, it really falls short for the modernist work that I do, dogmatically follows the Gould rule book and does not let you override most of that (it's what software people call an opinionated program), crashes often with the latest release and they cant solve it and just remain silent, and worse, the forum which I initially thought helpful is turning out to be quite toxic and I get a lot of personal abuse. along with deprecating comments about the music I work on. Consequently I have binned Dorico as of yesterday and I am coming back to lilypond. The upshot of that is that I suppose I should revive the OLL work. I'll recreate the dedicated server I set up, recreate the Discourse forum for discussion, and work on the git repository, then people can collaboratively work together again and I can take pull requests and so on. I stalled initially a couple of years ago when I decided to totally refactor the OLL github repostory, but now I think if we open it up again as is and I work on that on the background which would be useful. I'll pay for the server resources out of my own pocket, but provide a Paypal link for donations for running costs (server, domain name, etc). Andrew
Re: Openlilylib
Just another Dorico opinion, not in any way denying yours… I’ve worked with Dorico for the last few years exclusively for mockups of original work , transcriptions and orchestrations. It is a tremendous piece of software in particular the playback engine. There is definitely a steep learning curve but once one understands the concept behind the software, it becomes incredibly easy to input, edit and play scores. Depending on your software instruments and the intricacies of your playback templates, rendering the performance can be extremely realistic. As for the forum, I don’t live there so I don’t catch every thread, but my experience has been generally positive. There are many “gurus” lurking there that can answer most questions and I’ve never seen any animosity towards other forum members (excepting, of course, the usual RTFM answers …) Stability has also never been a problem for me. My template is huge: full orchestra routed to 8 instances of Vienna Server housing more than 1.5T of software instrument samples. My template used ~ 128G in-memory. Aside from having to get a coffee while it loaded, working in it for extended periods of time was rather uneventful from a stability standpoint. I am definitely not advocating for anyone to switch / trial / whatever to Dorico. It is simply another tool in my box with which to solve particular problems. I use (have been for well over a decade) lilypond exclusively for copying scores as it is by far the fastest way for me to input notes and get the score as close as possible to the original edition I’m copying. The added benefit of midi allows me to toss that output into a sequencer if I want to turn it into a mockup. I’m sorry you didn’t have a good experience with Dorico, but I just wanted to share a differing opinion. David From: lilypond-user on behalf of Andrew Bernard Date: Friday, May 27, 2022 at 4:26 AM To: lilypond-user@gnu.org Subject: Openlilylib Hello All, Having had to abandon the Openlilylib (OLL) work I took over from Urs Liska, for various reasons, in the meantime I went over to Dorico instead of Lilypond for my work. Having spent a lot of money on Dorico (AUD$800+) and given it my best shot for more than year, it really falls short for the modernist work that I do, dogmatically follows the Gould rule book and does not let you override most of that (it's what software people call an opinionated program), crashes often with the latest release and they cant solve it and just remain silent, and worse, the forum which I initially thought helpful is turning out to be quite toxic and I get a lot of personal abuse. along with deprecating comments about the music I work on. Consequently I have binned Dorico as of yesterday and I am coming back to lilypond. The upshot of that is that I suppose I should revive the OLL work. I'll recreate the dedicated server I set up, recreate the Discourse forum for discussion, and work on the git repository, then people can collaboratively work together again and I can take pull requests and so on. I stalled initially a couple of years ago when I decided to totally refactor the OLL github repostory, but now I think if we open it up again as is and I work on that on the background which would be useful. I'll pay for the server resources out of my own pocket, but provide a Paypal link for donations for running costs (server, domain name, etc). Andrew
Re: Openlilylib
Welcome back, and thank you. Having read your account of your situation, and knowing nothing else about your circumstances or condition, I hope we'll have you around with us for a good, long while yet. On Fri, 27 May 2022, 17:27 Andrew Bernard, wrote: > Hello All, > > Having had to abandon the Openlilylib (OLL) work I took over from Urs > Liska, for various reasons, in the meantime I went over to Dorico > instead of Lilypond for my work. Having spent a lot of money on Dorico > (AUD$800+) and given it my best shot for more than year, it really falls > short for the modernist work that I do, dogmatically follows the Gould > rule book and does not let you override most of that (it's what software > people call an opinionated program), crashes often with the latest > release and they cant solve it and just remain silent, and worse, the > forum which I initially thought helpful is turning out to be quite toxic > and I get a lot of personal abuse. along with deprecating comments about > the music I work on. Consequently I have binned Dorico as of yesterday > and I am coming back to lilypond. > > The upshot of that is that I suppose I should revive the OLL work. I'll > recreate the dedicated server I set up, recreate the Discourse forum for > discussion, and work on the git repository, then people can > collaboratively work together again and I can take pull requests and so on. > > I stalled initially a couple of years ago when I decided to totally > refactor the OLL github repostory, but now I think if we open it up > again as is and I work on that on the background which would be useful. > > I'll pay for the server resources out of my own pocket, but provide a > Paypal link for donations for running costs (server, domain name, etc). > > Andrew > > > >
Openlilylib
Hello All, Having had to abandon the Openlilylib (OLL) work I took over from Urs Liska, for various reasons, in the meantime I went over to Dorico instead of Lilypond for my work. Having spent a lot of money on Dorico (AUD$800+) and given it my best shot for more than year, it really falls short for the modernist work that I do, dogmatically follows the Gould rule book and does not let you override most of that (it's what software people call an opinionated program), crashes often with the latest release and they cant solve it and just remain silent, and worse, the forum which I initially thought helpful is turning out to be quite toxic and I get a lot of personal abuse. along with deprecating comments about the music I work on. Consequently I have binned Dorico as of yesterday and I am coming back to lilypond. The upshot of that is that I suppose I should revive the OLL work. I'll recreate the dedicated server I set up, recreate the Discourse forum for discussion, and work on the git repository, then people can collaboratively work together again and I can take pull requests and so on. I stalled initially a couple of years ago when I decided to totally refactor the OLL github repostory, but now I think if we open it up again as is and I work on that on the background which would be useful. I'll pay for the server resources out of my own pocket, but provide a Paypal link for donations for running costs (server, domain name, etc). Andrew
Re: Openlilylib
Andrew, I don't have any expertise with OLL. But I hate to see OLL just wither away. I would be happy to serve as a caretaker if that would help. I could take an ownership role with OLL, if you'd like. Also, I'd be happy to try set up Scores of Beauty. Do you have the source that you downloaded from Urs's site? Would you be willing to share it with me? Thanks, Carl On Mon, May 9, 2022 at 1:54 AM Andrew Bernard wrote: > Hello All, > > I've been absent from the list for a long time, but recently got CC'd > about an Openlilylib pull request. > > I must apologise for never getting around to updating the list on the > Openlilylib project status. Some time ago I took over from Urs who is no > longer able to do the work for private reasons I am not at liberty to > share. All started well and I setup a Linux server and a Wordpress site > and forum for the project. Taking over the code repository it had long > needed a large amount of refactoring, which I started but this proved to > be a complicated project for reasons I need not detain people with here. > > Then due to what can only be described as sheer stupidity I managed to > irrecoverably destroy my Linux server (it's a long story). What happened > after that is twofold. First, I am sorry to say that I was diagnosed > with the quite rare blood cancer Multiple Myeloma some ten years ago > now. It's fatal and incurable, though it can be managed well, especially > by the hospital here in Melbourne, Australia which has a world leading > research department specializing, amazingly, in the particular cancer. > So although I am doing well sometimes large software tasks become very > onerous and difficult, compared to before I became ill. Second, with the > difficulties mentioned, it seemed to me that I only ever got less than > half a dozen people signed up on the Discourse forum, and the project > seemed hardly worth the effort to continue, even though I do know there > are quite a few OLL end users. The sum of all this is that I have left > it dormant for such a long time. > > So at present there is no repository owner to accept pull requests, > > I am not really able to restart this project, and very happy for others > to pick up the ball. People are welcome to contact me for any advice. > > Once again, apologies for being incommunicado, and all the best to > everyone. > > > Andrew Bernard > > > > > >
Re: Openlilylib
Hi Andrew, thanks for the information. Sorry to hear about your illness and all the best wishes nonetheless! Best, Simon On 09/05/2022 09:53, Andrew Bernard wrote: Hello All, I've been absent from the list for a long time, but recently got CC'd about an Openlilylib pull request. I must apologise for never getting around to updating the list on the Openlilylib project status. Some time ago I took over from Urs who is no longer able to do the work for private reasons I am not at liberty to share. All started well and I setup a Linux server and a Wordpress site and forum for the project. Taking over the code repository it had long needed a large amount of refactoring, which I started but this proved to be a complicated project for reasons I need not detain people with here. Then due to what can only be described as sheer stupidity I managed to irrecoverably destroy my Linux server (it's a long story). What happened after that is twofold. First, I am sorry to say that I was diagnosed with the quite rare blood cancer Multiple Myeloma some ten years ago now. It's fatal and incurable, though it can be managed well, especially by the hospital here in Melbourne, Australia which has a world leading research department specializing, amazingly, in the particular cancer. So although I am doing well sometimes large software tasks become very onerous and difficult, compared to before I became ill. Second, with the difficulties mentioned, it seemed to me that I only ever got less than half a dozen people signed up on the Discourse forum, and the project seemed hardly worth the effort to continue, even though I do know there are quite a few OLL end users. The sum of all this is that I have left it dormant for such a long time. So at present there is no repository owner to accept pull requests, I am not really able to restart this project, and very happy for others to pick up the ball. People are welcome to contact me for any advice. Once again, apologies for being incommunicado, and all the best to everyone. Andrew Bernard
Re: Openlilylib
On Mon, May 9, 2022 at 12:55 AM Andrew Bernard wrote: > Hello All, > > I've been absent from the list for a long time, but recently got CC'd > about an Openlilylib pull request. > > I must apologise for never getting around to updating the list on the > Openlilylib project status. Some time ago I took over from Urs who is no > longer able to do the work for private reasons I am not at liberty to > share. All started well and I setup a Linux server and a Wordpress site > and forum for the project. Taking over the code repository it had long > needed a large amount of refactoring, which I started but this proved to > be a complicated project for reasons I need not detain people with here. > > Then due to what can only be described as sheer stupidity I managed to > irrecoverably destroy my Linux server (it's a long story). What happened > after that is twofold. First, I am sorry to say that I was diagnosed > with the quite rare blood cancer Multiple Myeloma some ten years ago > now. It's fatal and incurable, though it can be managed well, especially > by the hospital here in Melbourne, Australia which has a world leading > research department specializing, amazingly, in the particular cancer. > So although I am doing well sometimes large software tasks become very > onerous and difficult, compared to before I became ill. Second, with the > difficulties mentioned, it seemed to me that I only ever got less than > half a dozen people signed up on the Discourse forum, and the project > seemed hardly worth the effort to continue, even though I do know there > are quite a few OLL end users. The sum of all this is that I have left > it dormant for such a long time. > > So at present there is no repository owner to accept pull requests, > > I am not really able to restart this project, and very happy for others > to pick up the ball. People are welcome to contact me for any advice. > > Once again, apologies for being incommunicado, and all the best to > everyone. > > > Andrew Bernard > Although I don't currently use OLL, I thank you for all your work on it, and I'm sorry to hear about your health issues. I hope you continue to have a productive, pain-free, and as happy a life as possible. All the best, Ralph -- Ralph Palmer Seattle USA (he, him, his) palmer.r.vio...@gmail.com
Re: openlilylib pull request
Le 09/05/2022 à 01:59, David Kastrup a écrit : Simon Albrecht writes: On 08/05/2022 20:37, Jean Abou Samra wrote: The case study of how OLL fell out of maintenance is one of the things leading me to think that a model where snippets providing significant functionality and becoming somewhat popular get upstreamed into the LilyPond core is a better fit for LilyPond than them letting them be provided through external packages. In many cases, that may be true. In other cases, it really makes sense to allow for a more flexible space of user code available to the community. The TeX ecosystem may have some issues with maintaining packages and especially with interoperability, but it provides an unbelievable wealth of high-quality additions to the core software that could never be provided otherwise. Due to the relative lack of adoption and the small size of the community LilyPond can’t seem to take some threshold toward creating a similarly stable ecosystem (so far?). The "TeX ecosystem" consists of plain TeX with fudge-ons (comparable to LilyPond and LSR snippets), of the monolithic Context (driven by a not-much-more-than-one-man company), and of the modular LaTeX. The only system that has exploded in number and functionality of extensions and styles is LaTeX. That suggests that the development potential is not as much dependent on the underlying technology but of readily available interfaces for integrating both functionality as well as document styles into a fixed framework. I am not sure I would say that. Even though LaTeX is already more workable than plain TeX, it quickly gets pretty limited in features on its own, and programming it is very much not fun at all if not atrocious. So you need packages to accomplish about any standard task. The very quality of core LilyPond may be the reason why packaging layers around it have failed to really take off and LSR remains far more commonly used than openLilyLib. Not to mention that many amazing LilyPond snippets are expressed in less than 50 lines of Scheme code, which is just as convenient to inline in your file than to include. I don't think the same holds with TeX. We need to reflect on what packaging systems bring to other projects and what in that is or is not relevant to the LilyPond community. In other words, we should create a packaging system that fits a purpose. I don't believe that a packaging layer will enable us to steal some of LaTeX's success by its only existence. Another aspect is that TeX is frozen, and working with it is working with a prehistoric and pitiful piece of software by today's standards. But it's impossible to change due to backwards compatibility (I think), so you get more and more new competitors, each with its own incompatibilities: XeTeX, LuaTeX, ConTeXt. Having most features baked into LilyPond's core means we can make it evolve rather fast compared to the size of the project. convert-ly also helps there. Jean
Re: openlilylib pull request
Am 09.05.22 um 01:59 schrieb David Kastrup: The "TeX ecosystem" consists of plain TeX with fudge-ons (comparable to LilyPond and LSR snippets), of the monolithic Context (driven by a not-much-more-than-one-man company), and of the modular LaTeX. The only system that has exploded in number and functionality of extensions and styles is LaTeX. This might get off topic quickly, but I don’t want to let that uncommented WRT ConTeXt: ConTeXt is driven by a small community, even if Hans Hagen still does most of the programming (in communication with experts, e.g. for math or “exotic” languages). His company doesn’t play a big role and could hardly ever use ConTeXt for commercial projects (not because you couldn’t use ConTeXt for commercial projects, I do, but because the projects they got paid for didn’t involve producing PDFs). ConTeXt is monolithic insofar as it usually doesn’t need some settings as a package, because you just setup the settings yourself, and the interface is quite consistent. There *is* a growing number of modules, though. Many are part of the distribution, others are “third party”; if they gain wider acceptance, they often get integrated into the distribution, like the bibliography module. It’s common for ConTeXt users to just install all available modules – but LaTeX users also often just install the whole TeX live distribution. That suggests that the development potential is not as much dependent on the underlying technology but of readily available interfaces for integrating both functionality as well as document styles into a fixed framework. I guess development of open source projects depends the most on people who do it against all odds (like you). Of course it helps if they do it in a way that others can chime in. And then we need people who help building the community, answer questions etc. Hraban
Openlilylib
Hello All, I've been absent from the list for a long time, but recently got CC'd about an Openlilylib pull request. I must apologise for never getting around to updating the list on the Openlilylib project status. Some time ago I took over from Urs who is no longer able to do the work for private reasons I am not at liberty to share. All started well and I setup a Linux server and a Wordpress site and forum for the project. Taking over the code repository it had long needed a large amount of refactoring, which I started but this proved to be a complicated project for reasons I need not detain people with here. Then due to what can only be described as sheer stupidity I managed to irrecoverably destroy my Linux server (it's a long story). What happened after that is twofold. First, I am sorry to say that I was diagnosed with the quite rare blood cancer Multiple Myeloma some ten years ago now. It's fatal and incurable, though it can be managed well, especially by the hospital here in Melbourne, Australia which has a world leading research department specializing, amazingly, in the particular cancer. So although I am doing well sometimes large software tasks become very onerous and difficult, compared to before I became ill. Second, with the difficulties mentioned, it seemed to me that I only ever got less than half a dozen people signed up on the Discourse forum, and the project seemed hardly worth the effort to continue, even though I do know there are quite a few OLL end users. The sum of all this is that I have left it dormant for such a long time. So at present there is no repository owner to accept pull requests, I am not really able to restart this project, and very happy for others to pick up the ball. People are welcome to contact me for any advice. Once again, apologies for being incommunicado, and all the best to everyone. Andrew Bernard
Re: openlilylib pull request
Simon Albrecht writes: > On 08/05/2022 20:37, Jean Abou Samra wrote: >> The case study of how OLL fell out of maintenance is one of the >> things leading me to think that a model where snippets providing >> significant functionality and becoming somewhat popular get >> upstreamed into the LilyPond core is a better fit for LilyPond >> than them letting them be provided through external packages. > > > In many cases, that may be true. In other cases, it really makes sense > to allow for a more flexible space of user code available to the > community. > > The TeX ecosystem may have some issues with maintaining packages and > especially with interoperability, but it provides an unbelievable > wealth of high-quality additions to the core software that could never > be provided otherwise. Due to the relative lack of adoption and the > small size of the community LilyPond can’t seem to take some threshold > toward creating a similarly stable ecosystem (so far?). The "TeX ecosystem" consists of plain TeX with fudge-ons (comparable to LilyPond and LSR snippets), of the monolithic Context (driven by a not-much-more-than-one-man company), and of the modular LaTeX. The only system that has exploded in number and functionality of extensions and styles is LaTeX. That suggests that the development potential is not as much dependent on the underlying technology but of readily available interfaces for integrating both functionality as well as document styles into a fixed framework. -- David Kastrup
Re: openlilylib pull request
On 08/05/2022 20:37, Jean Abou Samra wrote: The case study of how OLL fell out of maintenance is one of the things leading me to think that a model where snippets providing significant functionality and becoming somewhat popular get upstreamed into the LilyPond core is a better fit for LilyPond than them letting them be provided through external packages. In many cases, that may be true. In other cases, it really makes sense to allow for a more flexible space of user code available to the community. The TeX ecosystem may have some issues with maintaining packages and especially with interoperability, but it provides an unbelievable wealth of high-quality additions to the core software that could never be provided otherwise. Due to the relative lack of adoption and the small size of the community LilyPond can’t seem to take some threshold toward creating a similarly stable ecosystem (so far?). Best, Simon
Re: openlilylib pull request
Le 08/05/2022 à 20:37, Jean Abou Samra a écrit : Le 08/05/2022 à 20:08, Simon Albrecht a écrit : Dear community, I have made some small updates to keep the openlilylib/bezier module working with current versions of LilyPond and created a pull request on GitHub. Is anyone currently able to notice and approve the request? I don't think so. Urs left the community, as you know (and for reasons unknown to me). I haven't seen anyone really maintaining OLL recently. Andrew (in CC) had set up http://openlilylib.space/ and a migration to GitLab at some point, but the website has been down for a while, and I can't find the repo on GitLab. If I recall correctly, the main people involved in coding OLL apart from Urs and Andrew were Janek and Jan-Peter. Both of them are inactive at the moment. Did I miss anyone? (The activity period of OLL was before I started getting involved.) I may be wrong, but I guess the most straightforward path for you right now is to fork this repository and advertise the fork. The case study of how OLL fell out of maintenance is one of the things leading me to think that a model where snippets providing significant functionality and becoming somewhat popular get upstreamed into the LilyPond core is a better fit for LilyPond than them letting them be provided through external packages. PS: I wrote this before actually looking at the PR, and coincidentally it turns out that it removes code for a functionality that I integrated into the core :-) (Although I wasn't even aware that it existed in OLL at the time, and just implemented it following a 10-year-old issue in the tracker, opened by Urs.) Best, Jean
Re: openlilylib pull request
Le 08/05/2022 à 20:08, Simon Albrecht a écrit : Dear community, I have made some small updates to keep the openlilylib/bezier module working with current versions of LilyPond and created a pull request on GitHub. Is anyone currently able to notice and approve the request? I don't think so. Urs left the community, as you know (and for reasons unknown to me). I haven't seen anyone really maintaining OLL recently. Andrew (in CC) had set up http://openlilylib.space/ and a migration to GitLab at some point, but the website has been down for a while, and I can't find the repo on GitLab. If I recall correctly, the main people involved in coding OLL apart from Urs and Andrew were Janek and Jan-Peter. Both of them are inactive at the moment. Did I miss anyone? (The activity period of OLL was before I started getting involved.) I may be wrong, but I guess the most straightforward path for you right now is to fork this repository and advertise the fork. The case study of how OLL fell out of maintenance is one of the things leading me to think that a model where snippets providing significant functionality and becoming somewhat popular get upstreamed into the LilyPond core is a better fit for LilyPond than them letting them be provided through external packages. Jean
openlilylib pull request
Dear community, I have made some small updates to keep the openlilylib/bezier module working with current versions of LilyPond and created a pull request on GitHub. Is anyone currently able to notice and approve the request? Best, Simon
Re: [openLilyLib] oll-core incompatible with Guile 2.2
I have written a message to the list a year ago regarding this. The problem is that OLL has a call in oll-core/internal/control.scm: (use-syntax (ice-9 syncase)) Which does not work anymore in 2.2, neither is it nescessary anymore, as guile 2 provides R5RS natively. My fix to this was to include a check for the guile version, like in the appended file. There are a few other problems in certain OLL modules, which can also be mitigated. Cheers, Valentin Am Mittwoch, 19. Jänner 2022, 01:45:04 CET schrieb Jean Abou Samra: > Le 18/01/2022 à 20:43, Simon Albrecht a écrit : > > Dear list, > > > > I have started using the experimental 2.23.5 build with Guile 2.2 [1] > > and it turns out to be incompatible with the core of openLilyLib. > > > > Here are the error messages I got—it may be that only the first is > > relevant: > > [...] > > Take a look at the attached patch (apply with 'git am'). > For me, it makes the file > edition-engraver/usage-examples/example-1.ly work. Note, > however, that ... > > > I would have to delve in order to find the root of the error and solve > > the problem, which I don’t really have time for, unless I must… > > ... this applies to me as well, so I haven't tested > anything else and don't intend to delve deeper than > this for now. > > Best, > Jean;; control syntax ;; ;; Andrew Bernard 2017 (define-module (oll-core internal control)) (if (< (string->number (car (string-split (version) #\.))) 2) (use-syntax (ice-9 syncase))) ;; when and unless from R6RS (define-syntax when (syntax-rules () ((when test result1 result2 ...) (if test (begin result1 result2 ...) (define-syntax unless (syntax-rules () ((unless test result1 result2 ...) (if (not test) (begin result1 result2 ...) signature.asc Description: This is a digitally signed message part.
Re: [openLilyLib] oll-core incompatible with Guile 2.2
Le 19/01/2022 à 01:45, Jean Abou Samra a écrit : Le 18/01/2022 à 20:43, Simon Albrecht a écrit : Dear list, I have started using the experimental 2.23.5 build with Guile 2.2 [1] and it turns out to be incompatible with the core of openLilyLib. Here are the error messages I got—it may be that only the first is relevant: [...] Take a look at the attached patch (apply with 'git am'). For me, it makes the file edition-engraver/usage-examples/example-1.ly work. Note, however, that ... I would have to delve in order to find the root of the error and solve the problem, which I don’t really have time for, unless I must… ... this applies to me as well, so I haven't tested anything else and don't intend to delve deeper than this for now. I forgot something: if you are using 2.23.4 or higher (as with these experimental binaries), you also need the attached in the edition-engraver. Jean From 12d3e43590cc091ecb1a4f5b8b9d06de5c28121f Mon Sep 17 00:00:00 2001 From: Jean Abou Samra Date: Wed, 19 Jan 2022 01:45:50 +0100 Subject: [PATCH] Replace ly:context-now with ly:context-current-moment ly:context-now was doing exactly the same as ly:context-current-moment and this duplication was removed in LilyPond 2.23. --- engine.scm | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/engine.scm b/engine.scm index aee8adc..52552eb 100644 --- a/engine.scm +++ b/engine.scm @@ -756,7 +756,7 @@ Path: ~a" path) (define (start-translation-timestep trans) (log-slot "start-translation-timestep") (if (or (not start-translation-timestep-moment) - (ly:moment
Re: [openLilyLib] oll-core incompatible with Guile 2.2
Le 18/01/2022 à 20:43, Simon Albrecht a écrit : Dear list, I have started using the experimental 2.23.5 build with Guile 2.2 [1] and it turns out to be incompatible with the core of openLilyLib. Here are the error messages I got—it may be that only the first is relevant: [...] Take a look at the attached patch (apply with 'git am'). For me, it makes the file edition-engraver/usage-examples/example-1.ly work. Note, however, that ... I would have to delve in order to find the root of the error and solve the problem, which I don’t really have time for, unless I must… ... this applies to me as well, so I haven't tested anything else and don't intend to delve deeper than this for now. Best, Jean From 84078085af9d83e4f5fa3bfa93f7804e99803698 Mon Sep 17 00:00:00 2001 From: Jean Abou Samra Date: Wed, 19 Jan 2022 01:37:41 +0100 Subject: [PATCH] Quick fixes for Guile 2 compatibility Don't define when and unless in Guile 2, they're already defined and the functionality of (ice-9 syncase) has been made available by default, thus removing the module. Use #f as explicit destination in format calls to silence warning. Load as identifier because define-method apparently no longer accepts it as expression. --- internal/control.scm | 28 internal/file-handling.scm | 3 +-- internal/logging.scm | 10 +- internal/named-alists.scm| 3 +-- internal/options.scm | 2 +- internal/os-path.scm | 6 +++--- load/templates.ily | 2 +- load/tools.ily | 2 +- temp-package-declaration.ily | 6 +++--- tree.scm | 15 --- usage-examples/properties.ly | 4 ++-- usage-examples/stack.ly | 6 ++ util/consist-to-contexts.ily | 3 +-- util/include-pattern.ily | 2 +- 14 files changed, 46 insertions(+), 46 deletions(-) diff --git a/internal/control.scm b/internal/control.scm index 8a9c0b7..c1d9c19 100644 --- a/internal/control.scm +++ b/internal/control.scm @@ -5,20 +5,24 @@ (define-module (oll-core internal control)) -(use-syntax (ice-9 syncase)) +(cond-expand + (guile-2) + (else + (use-syntax (ice-9 syncase)) -;; when and unless from R6RS + ;; when and unless from R6RS -(define-syntax when - (syntax-rules () -((when test result1 result2 ...) - (if test - (begin result1 result2 ...) + (define-syntax when +(syntax-rules () + ((when test result1 result2 ...) + (if test + (begin result1 result2 ...) -(define-syntax unless - (syntax-rules () -((unless test result1 result2 ...) - (if (not test) - (begin result1 result2 ...) + (define-syntax unless +(syntax-rules () + ((unless test result1 result2 ...) + (if (not test) + (begin result1 result2 ...) +)) diff --git a/internal/file-handling.scm b/internal/file-handling.scm index ff5c07b..ff9b75d 100644 --- a/internal/file-handling.scm +++ b/internal/file-handling.scm @@ -46,7 +46,7 @@ (let ((parser (ly:parser-clone))) (ly:parser-parse-string parser "\\language \"nederlands\"") (ly:parser-parse-string parser - (format "\\include \"~a\"" file)) + (format #f "\\include \"~a\"" file)) #t) #f)) @@ -63,4 +63,3 @@ (set! lines (cons line lines)) (lp (read-line h 'concat)) #f))) - diff --git a/internal/logging.scm b/internal/logging.scm index 3360287..7de996b 100644 --- a/internal/logging.scm +++ b/internal/logging.scm @@ -38,12 +38,12 @@ ; Generic function to consistently format the output for the logging functions (define (oll-format-log fmt vals) - (apply format (format "\n\n~a\n" fmt) vals)) + (apply format #f (format "\n\n~a\n" fmt) vals)) ; Open log file (define oll-logfile (open-output-file - (format "~a.oll.log" (ly:parser-output-name (*parser*) + (format #f "~a.oll.log" (ly:parser-output-name (*parser*) ; Generic function to consistently write to log file. ; is a sectioning header in the log file @@ -57,7 +57,7 @@ (number->string (cadr (ly:input-file-line-char-column (*location* "\n~a:\n" - (apply format fmt vals) + (apply format #f fmt vals) "\n\n") title)) @@ -70,7 +70,7 @@ (begin ;log-to-file "Error" fmt vals) (ly:input-message (*location*) - (format "Error:~a" (oll-format-log fmt vals))) + (format #f "Error:~a" (oll-format-log fmt vals))) (ly:error "" (define (oll:warn fmt . vals) @@ -99,4 +99,4 @@ (export oll:error) (export oll:warn) (export oll:log) -(export oll:debug) \ No newline at end of file +(export oll:debug) diff --git a/internal/named-alists.scm b/internal/named-alists.scm index e494e72..147eafb 100644 --- a/internal/named-alists.scm +++ b/internal
[openLilyLib] oll-core incompatible with Guile 2.2
Dear list, I have started using the experimental 2.23.5 build with Guile 2.2 [1] and it turns out to be incompatible with the core of openLilyLib. Here are the error messages I got—it may be that only the first is relevant: %% /home/simon/openlilylib/oll-core/internal/init.ily:46:2: error: GUILE signaled an error for the expression beginning here # (use-modules Omitting the destination on a call to format is deprecated. Pass #f as the destination, before the format string. Unbound variable: use-syntax /home/simon/openlilylib/oll-core/internal/init.ily:59:1: error: unknown escaped string: `\registerOption' \registerOption #'(_propsets) #'() /home/simon/openlilylib/oll-core/internal/init.ily:59:17: error: syntax error, unexpected SCM_TOKEN, expecting '.' or '=' \registerOption #'(_propsets) #'() /home/simon/openlilylib/oll-core/internal/init.ily:60:1: error: unknown escaped string: `\definePropertySet' \definePropertySet #'(OLL global) #'() /home/simon/openlilylib/oll-core/internal/init.ily:60:20: error: syntax error, unexpected SCM_TOKEN, expecting '.' or '=' \definePropertySet #'(OLL global) #'() /home/simon/openlilylib/oll-core/internal/init.ily:63:1: error: unknown escaped string: `\registerOption' \registerOption oll-core.root #(this-parent) /home/simon/openlilylib/oll-core/internal/init.ily:63:17: error: syntax error, unexpected SYMBOL, expecting '.' or '=' \registerOption oll-core.root #(this-parent) /home/simon/openlilylib/oll-core/internal/init.ily:63:31: error: syntax error, unexpected SCM_TOKEN, expecting '=' \registerOption oll-core.root #(this-parent) /home/simon/openlilylib/oll-core/internal/init.ily:66:1: error: unknown escaped string: `\registerOption' \registerOption loaded-packages #'(oll-core) /home/simon/openlilylib/oll-core/internal/init.ily:67:1: error: unknown escaped string: `\registerOption' \registerOption loaded-modules.oll-core #'() /home/simon/openlilylib/oll-core/internal/init.ily:67:41: error: syntax error, unexpected SCM_TOKEN, expecting '=' \registerOption loaded-modules.oll-core #'() /home/simon/openlilylib/oll-core/internal/init.ily:79:1: error: unknown escaped string: `\setLogLevel' \setLogLevel log ERROR: In procedure %resolve-variable: Unbound variable: getOption %% I would have to delve in order to find the root of the error and solve the problem, which I don’t really have time for, unless I must… Can someone help me out? Best regards Simon [1] https://lists.gnu.org/archive/html/lilypond-devel/2021-12/msg7.html
Re: [openLilyLib] oll-core incompatible with Guile 2.2
https://github.com/openlilylib/oll-core/issues/62 On 18/01/2022 20:43, Simon Albrecht wrote: I have started using the experimental 2.23.5 build with Guile 2.2 [1] and it turns out to be incompatible with the core of openLilyLib. Here are the error messages I got—it may be that only the first is relevant: %% /home/simon/openlilylib/oll-core/internal/init.ily:46:2: error: GUILE signaled an error for the expression beginning here # (use-modules Omitting the destination on a call to format is deprecated. Pass #f as the destination, before the format string. Unbound variable: use-syntax /home/simon/openlilylib/oll-core/internal/init.ily:59:1: error: unknown escaped string: `\registerOption' \registerOption #'(_propsets) #'() /home/simon/openlilylib/oll-core/internal/init.ily:59:17: error: syntax error, unexpected SCM_TOKEN, expecting '.' or '=' \registerOption #'(_propsets) #'() /home/simon/openlilylib/oll-core/internal/init.ily:60:1: error: unknown escaped string: `\definePropertySet' \definePropertySet #'(OLL global) #'() /home/simon/openlilylib/oll-core/internal/init.ily:60:20: error: syntax error, unexpected SCM_TOKEN, expecting '.' or '=' \definePropertySet #'(OLL global) #'() /home/simon/openlilylib/oll-core/internal/init.ily:63:1: error: unknown escaped string: `\registerOption' \registerOption oll-core.root #(this-parent) /home/simon/openlilylib/oll-core/internal/init.ily:63:17: error: syntax error, unexpected SYMBOL, expecting '.' or '=' \registerOption oll-core.root #(this-parent) /home/simon/openlilylib/oll-core/internal/init.ily:63:31: error: syntax error, unexpected SCM_TOKEN, expecting '=' \registerOption oll-core.root #(this-parent) /home/simon/openlilylib/oll-core/internal/init.ily:66:1: error: unknown escaped string: `\registerOption' \registerOption loaded-packages #'(oll-core) /home/simon/openlilylib/oll-core/internal/init.ily:67:1: error: unknown escaped string: `\registerOption' \registerOption loaded-modules.oll-core #'() /home/simon/openlilylib/oll-core/internal/init.ily:67:41: error: syntax error, unexpected SCM_TOKEN, expecting '=' \registerOption loaded-modules.oll-core #'() /home/simon/openlilylib/oll-core/internal/init.ily:79:1: error: unknown escaped string: `\setLogLevel' \setLogLevel log ERROR: In procedure %resolve-variable: Unbound variable: getOption %%
Re: Openlilylib status
Thank you all for the supportive comments. They are more than sufficient justification to make it worthwhile to continue. I better knuckle down and reincarnate the website, the Discourse forum, and finally do the git repository refactoring. I set up a new server already. Andrew
Re: Openlilylib status
Hi Andrew, > nobody has noticed the loss of the website or forum, > which did have a few members, > so I wonder if this is worth pursuing anyway. +1 to everything Carl wrote. Here’s a little more personal perspective… I freely admit that I didn’t notice the loss of the website or forum. There are two main reasons for that, and I offer that neither suggests the project is not worth pursuing [by Someone™]: 1. When my life circumstances afford me the opportunity to focus on music composition, arrangement, and engraving, my projects are sufficiently mission-critical, my deadlines sufficiently overwhelming, and my skill with the existing libraries sufficiently good that I don’t upgrade my OLL packages *unless* there’s a bug that needs fixing or new feature that I must use in the current piece(s). During a period like that, I wouldn’t likely notice the loss of the OLL “infrastructure”. 2. During this pandemic (now in its 13th month here), I have had to take on the home-schooling of my two children in addition to taking on non-music projects to try to replace the income lost in the collapse of the live performing arts industry (which was my bread and butter). Which is to say that my life circumstances *don’t* currently afford me the opportunity to focus on music (see Point #1), and thus I have *even less* time or reason to notice the loss of the OLL infrastructure. That being said, OLL has been — and will, I imagine, continue to be — absolutely critical to my music career toolchain / workflow, and I hope the world recovers to the point that I can be composing and arranging and engraving again. Whenever that is, it would be devastating to discover that OLL had fallen off the cliff (frozen in its current state). I know I’m just another “Must have this, but aren’t contributing in any concrete way” voice… But perhaps hearing enough of us feebly shouting from the rear will convince you — and hopefully more Someones™ — to keep bearing the standard and dragging us forward to greater things. Thanks, and best wishes, Kieren. Kieren MacMillan, composer (he/him/his) ‣ website: www.kierenmacmillan.info ‣ email: kie...@kierenmacmillan.info
Re: Openlilylib status
Hi Lilyponders, Andrew, I feel your pain. I offered to help Urs a number of times but he was way out of my league with the coding side of things and I was virtually useless to help. I use the Edition Engraver and Scholarly sporadically. What I think is that Urs was way ahead of most of us, and he had projects and needs that most of us don't. I would like to see all his work continue because I think it's amazing and Lilypond is far better suited to some of those high-level demands and projects than the other engraving software. Other than share a virtual beer with you and sympathise I don't know what else I can do to help. All the best, Craig On Fri, 12 Mar 2021 at 03:12, Damian leGassick wrote: > Hi Andrew > > I was just waiting for an update (and feeling your pain about the server) > before using OLL in a ‘real’ project. I’ve gotten familiar with most of it > now and it is certainly worth keeping alive. I would use it but I worry > about fragility. My python skills are too limited for the deeper tasks, but > my offer for testing and documentation help stands. > > I hope that more help is forthcoming - it does strike me as too big for > one person. > > Best > > Damian > > > > > On 10 Mar 2021, at 22:21, Andrew Bernard > wrote: > > > > Hello All, > > > > Some time ago I took over the management of the Openlilylib project from > Urs Liska, who was forced to cease the work for personal reasons. I created > a server to host a new website, a Git repository and a Discourse forum and > Openlilylib specific mailing list. The old git repository remains > untouched, but it is no longer taking pull requests. I was in the process > of refactoring the whole git repo to make it easier to use, but have not > yet completed that work. > > > > To cut to the point, in a moment of complete stupidity I deleted the > server this was running on without thinking to take a backup of the OLL > systems. So the work has currently been put on hold until I make a new > server and setup all the work again. Sadly, nobody has noticed the loss of > the website or forum, which did have a few members, so I wonder if this is > worth pursuing anyway. > > > > Just letting you know where we are with OpenLilyLib. > > > > If anybody else is interested in taking over the work, please write and > let me know. > > > > > > Andrew > > > > > > > > > > > >
Re: Openlilylib status
Hi Andrew I was just waiting for an update (and feeling your pain about the server) before using OLL in a ‘real’ project. I’ve gotten familiar with most of it now and it is certainly worth keeping alive. I would use it but I worry about fragility. My python skills are too limited for the deeper tasks, but my offer for testing and documentation help stands. I hope that more help is forthcoming - it does strike me as too big for one person. Best Damian > On 10 Mar 2021, at 22:21, Andrew Bernard wrote: > > Hello All, > > Some time ago I took over the management of the Openlilylib project from Urs > Liska, who was forced to cease the work for personal reasons. I created a > server to host a new website, a Git repository and a Discourse forum and > Openlilylib specific mailing list. The old git repository remains untouched, > but it is no longer taking pull requests. I was in the process of refactoring > the whole git repo to make it easier to use, but have not yet completed that > work. > > To cut to the point, in a moment of complete stupidity I deleted the server > this was running on without thinking to take a backup of the OLL systems. So > the work has currently been put on hold until I make a new server and setup > all the work again. Sadly, nobody has noticed the loss of the website or > forum, which did have a few members, so I wonder if this is worth pursuing > anyway. > > Just letting you know where we are with OpenLilyLib. > > If anybody else is interested in taking over the work, please write and let > me know. > > > Andrew > > > > >
Re: Openlilylib status
Andrew, I would love to get to grips with Openlilylib (specifically, scholarLy) but when I tried to register to its new home when you first announced it, I couldn't get in. Can't remember the precise details now, and there wasn't time to pursue it back then. But I suspect there might be an element of "suppressed demand" for the new site. My first attempts to use Openlilylib in the past came to nought, for lack of understanding. But it remains on my do-list, and I'd be sorry to see the loss of it. with apologies for leading from the rear! -- Graham > > On 3/10/21, 3:21 PM, "lilypond-user on behalf of Andrew Bernard" > andrew.bern...@gmail.com> wrote: > >Hello All, > >Some time ago I took over the management of the Openlilylib project from >Urs Liska, who was forced to cease the work for personal reasons. I >created a server to host a new website, a Git repository and a Discourse >forum and Openlilylib specific mailing list. The old git repository >remains untouched, but it is no longer taking pull requests. I was in >the process of refactoring the whole git repo to make it easier to use, >but have not yet completed that work. > >To cut to the point, in a moment of complete stupidity I deleted the >server this was running on without thinking to take a backup of the OLL >systems. So the work has currently been put on hold until I make a new >server and setup all the work again. Sadly, nobody has noticed the loss >of the website or forum, which did have a few members, so I wonder if >this is worth pursuing anyway. >
Re: Openlilylib status
On 3/10/21, 3:21 PM, "lilypond-user on behalf of Andrew Bernard" wrote: Hello All, Some time ago I took over the management of the Openlilylib project from Urs Liska, who was forced to cease the work for personal reasons. I created a server to host a new website, a Git repository and a Discourse forum and Openlilylib specific mailing list. The old git repository remains untouched, but it is no longer taking pull requests. I was in the process of refactoring the whole git repo to make it easier to use, but have not yet completed that work. To cut to the point, in a moment of complete stupidity I deleted the server this was running on without thinking to take a backup of the OLL systems. So the work has currently been put on hold until I make a new server and setup all the work again. Sadly, nobody has noticed the loss of the website or forum, which did have a few members, so I wonder if this is worth pursuing anyway. Andrew, I think that what is going on right now is that there are people who use openlilylib, but don't need the latest updates or the forum or website. I do believe, however, that there is interest in eventually improving OpenLilyLib. If we are to sell OpenLilyLib to the uninitiated, we probably need the website. If we are to help the uninitiated use OpenLilyLib, we probably need the forum. Bottom line -- the lack of the website means it's unlikely that the uninitiated will even interact with OLL. And the lack of novices using OLL means the need for the forum is low. But that is NOT the ideal situation. I know that there are at least a few power users who LOVE OLL. It would be a shame to have OLL disappear from anything but a git repository. But I recognize that there are real costs to recreating the forum and the website. And I'm not prepared to invest the time to recreate it, so I have no business telling you that you should. I don't think the lack of "notice" of the loss of the website or forum means they have no value. It probably DOES mean they have relatively little value to the LilyPond/OLL expert. I hope you'll be able to muster the effort to resurrect these items! Thanks, Carl
Openlilylib status
Hello All, Some time ago I took over the management of the Openlilylib project from Urs Liska, who was forced to cease the work for personal reasons. I created a server to host a new website, a Git repository and a Discourse forum and Openlilylib specific mailing list. The old git repository remains untouched, but it is no longer taking pull requests. I was in the process of refactoring the whole git repo to make it easier to use, but have not yet completed that work. To cut to the point, in a moment of complete stupidity I deleted the server this was running on without thinking to take a backup of the OLL systems. So the work has currently been put on hold until I make a new server and setup all the work again. Sadly, nobody has noticed the loss of the website or forum, which did have a few members, so I wonder if this is worth pursuing anyway. Just letting you know where we are with OpenLilyLib. If anybody else is interested in taking over the work, please write and let me know. Andrew
Re: [OpenLilyLib] looking for collaborator(s) on stylesheet package/system
Hello again, I got a few private responses to this post — which were appreciated — but was really hoping to get a discussion going about how such a system could be implemented. Perhaps the word “collaborator(s)” in the subject is too strong and scary? ;) To be clear: my “problem” is never about not knowing how to [potentially] solve a given puzzle. My “problem” is my ability to come up with TOO MANY ways to [potentially] solve a given puzzle. I’m hoping one or more (!) Excellent Minds™ out there in the ’Pond is willing to help me separate the wheat from the chaff in my possible approaches/solutions, so that (a) I don’t get paralyzed by the choices, and (b) there’s an outside chance this project will actually move forward towards the goal line. Anyone up for such a discussion? Thanks, Kieren. > Hi all, > > Now that OLL is settling into its new home, and my own life has settled > enough > that I can focus on something other than mere survival, I wanted to revive > this > thread, and hopefully move the idea forward significantly in the near future. > > The intention of a stylesheet package/system would be to allow a Lilypond > (or, > at the very least, OLL) user to apply preset styles to their scores with > minimal effort. Say I want my piano music to look like mid-20th Century Henle > Beethoven scores. I want to put something like >\include "stylesheets.instrument.solo.piano.Henle.Beethoven.1952" > in my score and VOILA! it automagically looks like the attached (which I > generated in Lilypond). > > To whatever extent possible: > > 1. Stylesheets should handle notation fonts, sizes, tweaks, etc. (a.k.a. > Every > Possible Thing™). > > 2. Stylesheets should be modular (e.g., one should be able to easily choose > the > Peters 1940 choral format, but use a custom text font set). > > 3. Stylesheets should be able to include functions, macros, and other “active > code”. > > So… > > The first big question [thank you, Urs!] is: > > How could such a stylesheet system be organized a) in the ways e.g. CSS > > is organized and how a "publisher" might organize house styles (e.g. > > aesthetic styles, score types etc.) > > I would love to discuss this on-list with anyone who has good ideas to offer, > even if you’re not keen on being involved in working out the implementation. > > Thanks! > Kieren. Kieren MacMillan, composer (he/him/his) ‣ website: www.kierenmacmillan.info ‣ email: kie...@kierenmacmillan.info
Re: [OLL] openLilyLib news
In your debt, Andrew, Ralph On Thu, Oct 15, 2020 at 9:31 PM Andrew Bernard wrote: > What's happening with OLL, latest news. I have made a dedicated > website, https://openlilylib.space. > -- Ralph Palmer Brattleboro, VT USA (he, him, his) palmer.r.vio...@gmail.com
Re: [OLL] openLilyLib news
Nice, ƒg On Thu, Oct 15, 2020 at 9:31 PM Andrew Bernard wrote: > > What's happening with OLL, latest news. I have made a dedicated > website, https://openlilylib.space. > > I think OLL is distinct enough to have it's own mailing list, and I > don't want to clog the lilypond user list with technical OLL > development posts, so I am in the business of setting up a list, > probably using GNU Mailman 3 (not the greatest software, but I have > used it a lot before). > > OLL development is managed with Git. For personal and technical > reasons I have started a project on GitLab, and have copied the repos > there. I am not touching or changing the existing GitHub work, but I > am expecting that we move across to GitLab now. One reason for the > change is that I am refactoring the OLL repos into one single repo > (this is quite tricky in git if you want to keep the commit histories) > because I think this is far simpler for me to manage and far easier > for end users, to just clone one item. No criticism of the existing > structure, but I think that just grew. I'll provide the GitLab details > when I have done the refactoring, soonish. > > And by popular demand, I have corrected the capitalization of openLilyLib. :-) > > Andrew >
[OLL] openLilyLib news
What's happening with OLL, latest news. I have made a dedicated website, https://openlilylib.space. I think OLL is distinct enough to have it's own mailing list, and I don't want to clog the lilypond user list with technical OLL development posts, so I am in the business of setting up a list, probably using GNU Mailman 3 (not the greatest software, but I have used it a lot before). OLL development is managed with Git. For personal and technical reasons I have started a project on GitLab, and have copied the repos there. I am not touching or changing the existing GitHub work, but I am expecting that we move across to GitLab now. One reason for the change is that I am refactoring the OLL repos into one single repo (this is quite tricky in git if you want to keep the commit histories) because I think this is far simpler for me to manage and far easier for end users, to just clone one item. No criticism of the existing structure, but I think that just grew. I'll provide the GitLab details when I have done the refactoring, soonish. And by popular demand, I have corrected the capitalization of openLilyLib. :-) Andrew
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 are never affected by the strong copyleft effect of the GPL. That's good to hear. But I don't understand, why - under this circumstances - it should be garbage to add a respective clarifying statement (the 'include clause' or however you want to name it), if it is at least partially conceivable that such a position will be taken and if all of you do not want to use / establish its consequences. But that's my problem. >>> >>> >>> I would like to join in asking this question, namely what’s the >>> reason not to add such an ‘include clause’? (Am I correct in >>> gathering that LGPL basically means GPL + such an include clause?) > > 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. 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. So sometimes I feel it makes sense to add crucial information to them, even if the likelihood that the original participants care is pretty much zero. Admittedly, it happens more to discussions concerning vintage digital cameras, but there have been two or three occasions where I even did it with LilyPond. Typically somewhat facetiously when some long-requested feature or bug had finally been addressed, probably in the wake of structural changes making it possible in the first place. -- David Kastrup
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 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 don't understand, why - under this circumstances - it should be garbage to add a respective clarifying statement (the 'include clause' or however you want to name it), if it is at least partially conceivable that such a position will be taken and if all of you do not want to use / establish its consequences. But that's my problem. I would like to join in asking this question, namely what’s the reason not to add such an ‘include clause’? (Am I correct in gathering that LGPL basically means GPL + such an include clause?) Best, Simon
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 >> GPL. That's good to hear. But I don't understand, why - under this >> circumstances - it should be garbage to add a respective clarifying >> statement (the 'include clause' or however you want to name it), if >> it is at least partially conceivable that such a position will be >> taken and if all of you do not want to use / establish its >> consequences. But that's my problem. > > > I would like to join in asking this question, namely what’s the reason > not to add such an ‘include clause’? (Am I correct in gathering that > LGPL basically means GPL + such an include clause?) No, you are not correct. The LGPL has more lenient conditions. It also has a clause that allows it to be replaced by the GPL, and when combining a GPLed work with an LGPLed work to form a common whole, invoking that clause is the only way in which you can arrive at a redistributable whole. The main problem of adding _anything_ to a license of the GPL/LGPL flavor is that the result is incompatible to software licensed under GPL/LGPL without such an addition, defeating the significant goal of interoperability and reusability of the GNU code base. -- David Kastrup
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 don't understand, why - under this circumstances - it should be garbage to add a respective clarifying statement (the 'include clause' or however you want to name it), if it is at least partially conceivable that such a position will be taken and if all of you do not want to use / establish its consequences. But that's my problem. I would like to join in asking this question, namely what’s the reason not to add such an ‘include clause’? (Am I correct in gathering that LGPL basically means GPL + such an include clause?) Best, Simon
Ongoing openlilylib development
Since Urs has stepped down for personal reasons, I am willing to continue the maintenance and development of OLL, as well as promotion and improvement of documentation and information. My understanding (perhaps incorrect) is that the Github repo is now orphaned. I propose to create and manage a new repository at Gitlab. Any comments or objections to this? I have not posted this to the devel list as I think it is out of scope. Andrew
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-documentation/main-site/ Thanks!
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 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 Hi Urs, Well, for me it's rather that I was initally willing to reply but the side track turned me off. I need to admit I have never really tried openLilyLib, mostly because it requires always running LilyPond with some magic option. I think there is potential in LilyPond packaging, as the LSR evidences. (What strikes me most in openLilyLib is its package for alternate notation fonts.) I have long had the project of a kind of mix between the LSR and openLilyLib's snippets repository, to combine the Git workflow and a web interface. I will raise this in my priority list. Kind regards, Jean PS: Those few who know more about the background shouldn't worry too much about the final character of this statement ... No clue what you meant here. Is 'character' as in novels, or strings? PPS: I see you shut down openlilylib.org. Is the source archived somewhere so I can better understand openLilyLib?
Re: openLilyLib git
Am 07.10.20 um 02:18 schrieb 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 > Hi Andrew, I would appreciate it, if you would take over the management. Let me know, when created your own fork. Jan-Peter
openLilyLib git
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
Urs, I am unable to email you at openlilylib.org. Is there another way to contact you off list? Andrew
Re: Future of openLilyLib
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<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 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, 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
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
\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
>> \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 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: 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 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
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
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 > >
