Re: String at the bottom of a cover page without using \markup
Hello Valentin On Friday, December 17, 2021, Valentin Petzel wrote: > Hello Paolo, > That is to be expected, as the copyright field is simply used in the > default > footer markup (as I’ve hinted before). Still, is there any reason not to > use > the footer markup for that one? > Because this would be a hack. I don't like to put hacks in my code, and I use them only if I really don't have alternatives. Hacks break readibility of the code and cause problems when the code has to be reused in the future. That said, I'm noting that there are limitations in LP regarding the format of the introductory pages of the score. This is normal, because LP is a program for writing scores, not books. Therefore, I think that the best way to obtain what I need is to edit these pages with another program and then append them to the generated PDF of the score through a script. Best, P > >
Re: String at the bottom of a cover page without using \markup
On Fri, Dec 17, 2021 at 8:32 AM Valentin Petzel wrote: > Hello Paolo, > as far as I'm concerned there is nothing hacky about using footer markup > for its intended purpose, that is placing stuff at the bottom of the page. > Rather any other method would probably involve lots of volatile hacks. In > my book a hack would be abusing some functionality in some unintended way > to get unsupported functionality. Using footer markup does not seem like > such a thing. Of course you could change Lilypond's whole page layout > system to effectively have two footer markups, but pretty much the same can > be achieved with setting the footer markup to something that matches what > you want. > > Indeed, Lilypond's text processing capabilities are rather limited. > > Hello Valentin, I'm still convinced it is a hack. Commonly, the "hack" term is used for indicating a work-around with some emphasis. In the case we are talking about, David's suggestion would be a simple work-around (---> improper use of a label to bypass the problem). But the copyright field has an issue (which should be reported to Gitlab, I think: feedback are welcome, so I can report it): it is coupled to the footer but it is not necessarily a footer. In fact, a footer is not simply an element that is placed on the bottom of a page. It also has to be recurrent in order to be a footer. And a copyright field is not required to be recurrent. Therefore, using a footer (and not the copyright field) as a non-recurrent string, so to align an element at a desired position is more than a work-around. I normally use two labels in my code (which is a common choice too): FIXME (for issues and hacks) and WORKAROUND for work-arounds. If I used the hack, I would write a FIXME label in the code: but it is likely it won't be fixed in the future, because the LP tools for cover pages have some expected limits that I think should be overcome with tools focused on text typography. Note too that the "footer" solution has unwanted side effects: for example, I normally print page numbers on the header of the page; but another good choice would be to print them centered on the footer as page X/totPages. I should have the flexibility to switch on the fly from one choice to another, which is expected in a header + body + footer template, therefore this template should not be polluted by mixing body with footer. As said before, an improper use of the copyright field would be an acceptable compromise, but it has the issue I wrote above. Therefore, I conclude that using a tool for text typography (for cover pages) in addition to LilyPond is an exahustive choice for managing a complete score. Cheers, Paolo
Re: String at the bottom of a cover page without using \markup
On Fri, Dec 17, 2021 at 6:48 PM Paolo Prete wrote: > > > It also has to be recurrent in order to be a footer. And a copyright > field is not required to be recurrent. > More precisely: the recurrence of the copyright (if it is recurrent) and that of the footer should not be coupled.
Re: String at the bottom of a cover page without using \markup
On Fri, Dec 17, 2021 at 6:57 PM Kieren MacMillan < kie...@kierenmacmillan.info> wrote: > Hi Paolo, > > > In fact, a footer is not simply an element that is placed on the bottom > of a page. It also has to be recurrent in order to be a footer. > > To be precise, it has to *have the potential* to recur: a footer on a > one-page document doesn't recur, but it's still a footer. > > Yes, that's more or less what I wrote later. > As I see it, the problem here is that the documentation isn't clear that > "copyright" is simply a property that happens to be "pre-defined", in the > sense that it's referenced somewhere [specifically titling-init.ly > > oddFooterMarkup] in the standard distro. It could just as easily been > called 'kieren' or anything else. > > Put another way: The copyright property isn't a footer, nor is it coupled > with the footer in any way *except* that the default titling includes it on > the first page [only]. > > This behavior is a bit ambiguous, IMHO. I still prefer to have these fields totally decoupled. I think it's reasonable that the copyright appears at the bottom, as default, but I don't understand the choice to couple it to the footer of the first page. Best, P
Re: String at the bottom of a cover page without using \markup
On Fri, Dec 17, 2021 at 7:14 PM Kevin Barry wrote: > > I'm still convinced it is a hack. Commonly, the "hack" term is used for > indicating a work-around with some emphasis. > > In the case we are talking about, David's suggestion would be a simple > work-around (---> improper use of a label to bypass the problem). > > I think you're overthinking things here: think of copyright as a name > for any text you might want to put at the bottom of the first page. > It's not important what I think, it is important what can be read on the code at a glance. If I write copyright = "Composed in 2021", then I have to add a comment note above that line as memo for explaining that the copyright field was used for another purpose. Not a clean code, IMHO.
Re: String at the bottom of a cover page without using \markup
On Fri, Dec 17, 2021 at 7:23 PM Kieren MacMillan < kie...@kierenmacmillan.info> wrote: > Hi Paolo, > > > I still prefer to have these fields totally decoupled. > > The fields *are* totally decoupled… > > No, they are not. They are coupled on the first page. Then they are partially decoupled, not totally decoupled. > > I think it's reasonable that the copyright appears at the bottom, as > default, but I don't understand the choice to couple it to the footer of > the first page. > > 1. I don't understand how you would include the copyright field > information in the footer [of any page] without referencing the > field/property in the footer definition. > I don't understand what you mean, sorry. Copyright IMHO should not be coupled with the footer, as a field, even if it appears at the bottom of the page. It can appear on the top of the page as well. But it is reasonable that its default is to appear at the bottom. > > 2. I don't believe I've ever used a text/page layout application which > allowed multiple footers on a single page. > > Please explain how you would like to see the "issue" resolved, > specifically in light of those two points. > > (just a first idea) This can be solved by having a footer with separate user settable fields. For example: footer.text1, footer.text2 etc. Then you don't have to use a "copyright" field at all. Best, P On Fri, Dec 17, 2021 at 7:23 PM Kieren MacMillan < kie...@kierenmacmillan.info> wrote: > Hi Paolo, > > > I still prefer to have these fields totally decoupled. > > The fields *are* totally decoupled… > > > I think it's reasonable that the copyright appears at the bottom, as > default, but I don't understand the choice to couple it to the footer of > the first page. > > 1. I don't understand how you would include the copyright field > information in the footer [of any page] without referencing the > field/property in the footer definition. > > 2. I don't believe I've ever used a text/page layout application which > allowed multiple footers on a single page. > > Please explain how you would like to see the "issue" resolved, > specifically in light of those two points. > > Thanks, > Kieren.
Re: String at the bottom of a cover page without using \markup
On Fri, Dec 17, 2021 at 7:46 PM Kieren MacMillan < kie...@kierenmacmillan.info> wrote: > Hi Paolo, > > > This can be solved by having a footer with separate user settable > fields. For example: footer.text1, footer.text2 etc. Then you don't have to > use a "copyright" field at all. > > You can do that right now — that's literally what I've been suggesting you > do. > > As explained before, I don't want to proceed in this way. The string that I have to write at the bottom of the page is part of the *body*, not of the footer. I don't want to mess up the template. Best, P
Re: String at the bottom of a cover page without using \markup
On Fri, Dec 17, 2021 at 7:49 PM Kieren MacMillan < kie...@kierenmacmillan.info> wrote: > Hi again, > > >> The fields *are* totally decoupled… > > No, they are not. They are coupled on the first page. Then they are > partially decoupled, not totally decoupled. > > There is absolutely no coupling: > 1. I can have any value I want in the "copyright" field and have it appear > nowhere in my score; and > 2. I can have the information in the "copyright" field/property appear > wherever I want in the score. > > This is what you wrote in the past post: "The copyright property isn't a footer, nor is it coupled with the footer in any way *except* that the default titling includes it on the first page" ---> then yourself wrote that they are not totally decoupled > There is zero "coupling" involved. > > > I don't understand what you mean, sorry. Copyright IMHO should not be > coupled with the footer > > It's not. It's a property that may be given a value in the \header block > (see my other email for possible discussion about renaming that!). I'm not > sure how much clearer I can make it for you — it may be a language issue. > Yes, I'm seeing it is a language issue. I think you misunderstood the meaning of "coupling" in computer programming. See (absolutely not intended to be polemic, just a clarification) https://en.wikipedia.org/wiki/Coupling_(computer_programming)#:~:text=In%20software%20engineering%2C%20coupling%20is,of%20the%20relationships%20between%20modules . Best, P > > Cheers, > Kieren.
Re: String at the bottom of a cover page without using \markup
Hello again Kieren ;-) On Fri, Dec 17, 2021 at 7:57 PM Kieren MacMillan < kie...@kierenmacmillan.info> wrote: > Hi Paolo, > > > As explained before, I don't want to proceed in this way. The string > that I have to write at the bottom of the page is part of the *body*, not > of the footer. > > I don't want to mess up the template. > > Then just place it as an additional markup, between the last system of > music and the footer, on whichever page(s) you want. > I guess I don't understand the problem… > > As said in the first post of the thread, I don't know how to make it appear at the bottom of the page of the first page (no score)... Cheers, P > Cheers, > Kieren.
Re: String at the bottom of a cover page without using \markup
On Fri, Dec 17, 2021 at 8:21 PM Kieren MacMillan < kie...@kierenmacmillan.info> wrote: > Hi Paolo, > > > > https://en.wikipedia.org/wiki/Coupling_(computer_programming)#:~:text=In%20software%20engineering%2C%20coupling%20is,of%20the%20relationships%20between%20modules > > "In software engineering, coupling is the degree of interdependence > between software modules; a measure of how closely connected two routines > or modules are;[1] the strength of the relationships between modules." > > So you're trying to apply the definition of "routines and modules" to > describe data and how it's referenced in a layout application? ;) > > No. I'm applying it in its *natural* context (the programming code of LP, that couples two functions, and this appears to me as an issue. I could be wrong, but it deserves to be discussed, IMHO, and this is not offending anyone) > I can't spend any more time on this thread — I hope you figure out your > solution soon, and stop blaming Lilypond for something it's not actually > doing. > > I'm not blaming *anything*/*anyone*. Please, go on in saying nonsense things: I'll just ignore you! Cheers P
Re: String at the bottom of a cover page without using \markup
Check the attached pdf. Nor "author", nor "title", nor "motto" should be part of the header/footer. They are part of the body and author and motto have a fixed and equal offset respectively from the top and the bottom. THANKS for your help ! On Fri, Dec 17, 2021 at 8:08 PM Carl Sorensen wrote: > > > > > *From: *lilypond-user gmail@gnu.org> on behalf of Paolo Prete > *Date: *Friday, December 17, 2021 at 12:06 PM > *To: *Kieren MacMillan > *Cc: *Valentin Petzel , Lilypond-User Mailing List < > lilypond-user@gnu.org> > *Subject: *Re: String at the bottom of a cover page without using markup > > > > Hello again Kieren ;-) > > > > On Fri, Dec 17, 2021 at 7:57 PM Kieren MacMillan < > kie...@kierenmacmillan.info> wrote: > > Hi Paolo, > > > As explained before, I don't want to proceed in this way. The string > that I have to write at the bottom of the page is part of the *body*, not > of the footer. > > I don't want to mess up the template. > > Then just place it as an additional markup, between the last system of > music and the footer, on whichever page(s) you want. > I guess I don't understand the problem… > > > > As said in the first post of the thread, I don't know how to make it > appear at the bottom of the page of the first page (no score)... > > > > A minimal example that shows your problem would help people answer your > question appropriately. > > > > Carl > page.pdf Description: Adobe PDF document
Re: String at the bottom of a cover page without using \markup
On Fri, Dec 17, 2021 at 8:32 PM Kieren MacMillan < kie...@kierenmacmillan.info> wrote: > Hi Paolo, > > > No. I'm applying it in its *natural* context (the programming code of > LP, that couples two functions > > Since \header (where the data resides) is not a *function*, I'll be > interested to hear how you defend that claim. > > I'm sorry, as said before, I'm not interested in explaining to you in detail what is obvious and you don't understand, and I'm not interested in talking with you at all. I'm just going to ignore you. Cheers! [To the participants of this thread] That said, if among the readers of this thread there is someone interested in further clarification of the discussed problem, including the "coupling" concept, just ask me and I'll try to go into details (but I don't think it should be necessary)
Send program changes to non general-midi soundfont
Hello, which is the best way to send program changes to non general-MIDI soundfonts? Should I wrap \set Staff.midiInstrument = "general-midi-instr-name" with a custom command or is there a (lower-level) way to send program changes by number? Thanks!
Re: String at the bottom of a cover page without using \markup
Hello Valentin, Of course I can put a global flag for swapping header content to footer content and vice-versa. But what if I put the non-recurring "motto" of my previous example in a recurring footer and preserve easy swapping? I would have to do something like this (pseudo-code), in order to swap: header-content = page-numbers footer-content = motto-on-first-page to header-content = nothing footer-content = motto-on-first-page + page-numbers As you can see this is not a simple swap: additional logic is required, because motto and page-numbers have two different recurrence settings (no recurrence for motto and recurrence for page-numbers). This happens because I'm coupling what should be in the body with what should be in the footer. Instead, a clean or basic template IMHO doesn't need additional logic: just set the recurrence values for the header and for the footer and you have done. And this is how, AFAIK, a basic typography template does work. When I write such a page with LibreOffice, I don't need any additional logic or plugin for swapping the elements. In addition: It is true that a footer doesn't necessarily have to be recurring; however, as you can note, it is recurring as *default*. This default has a precise meaning: recurring is the rule, non-recurring is the exception. When you have to use an exception, you should firstly evaluate if you have a proper field for managing it. And the proper field for this case is the Body part, which is non-recurring as default. This is why I would use an alternative tool for cover/introductory pages of a score, in case they don't fit with the LP template. And this is absolutely not intended for "blaming" LP: instead, it is the contrary. IMHO, having an all-in-one program, especially for open-source programs, is not possible and it would not be reasonable either. LP is excellently focused on score engraving and that is enough. All-in-one programs are better for closed source stuff, not for open-source systems. And putting together different open source programs so to have an exhaustive system should be a normal routine. Hope my message is clear. Best, Paolo On Fri, Dec 17, 2021 at 11:00 PM Valentin Petzel wrote: > Hello Paolo, > > as already pointed out you can customize the footer markup to contain > anything you want, including custom header fields (also you can implement > stuff like swapping of page number position depending on global flags or > something). > > Then a footer does not need to be recurring. A footer is just something > printed below the actual content. > > So I'd consider using footer markup as a quite clean way of doing such > things. > > Valentin > > 17.12.2021 19:20:27 Paolo Prete : > > > > On Fri, Dec 17, 2021 at 7:14 PM Kevin Barry wrote: > >> > I'm still convinced it is a hack. Commonly, the "hack" term is used for >> indicating a work-around with some emphasis. >> > In the case we are talking about, David's suggestion would be a simple >> work-around (---> improper use of a label to bypass the problem). >> >> I think you're overthinking things here: think of copyright as a name >> for any text you might want to put at the bottom of the first page. >> > > It's not important what I think, it is important what can be read on the > code at a glance. > If I write copyright = "Composed in 2021", then I have to add a comment > note above that line as memo for explaining that the copyright field was > used for another purpose. Not a clean code, IMHO. > > > > > > >
Re: String at the bottom of a cover page without using \markup
On Sat, Dec 18, 2021 at 1:00 AM Valentin Petzel wrote: > Hello Paolo, > > I think you underestimate Lilypond. Hi Valentin, this is not true. I well know, and stated several times, that LilyPond has the power of a nuclear reactor. And I'm sure too that with customizations you can do whatever you want in the cover/introductory pages. What I meant is different. For these pages I don't want to add or expose logic. This is not how I intend typography for such pages. The example Aaron showed already added *logic* to the template, and so your example does: \on-the-fly #part-first-page \fromproperty #'header:copyright (etc.) (of course thanks again Aaron and you for your examples, which are precious: they clarify to me how LP works) But, IMHO, such pages should not have logic, unless you don't have alternatives. Normally, I would prefer another approach, which I consider *standard* for these things: have a set of templates, pick one of them and do NO customization at all, unless you don't have alternatives. Your example would fit my requirements if it was wrapped by a template, but it is currently not. This is how you can have a *readable* code (don't misunderstand me: your code is excellent, what I mean is different). Of course I could wrap it, but for future different cases I would have to do the same procedure, which is tedious. Hope that what I mean is clear, now. In any case, this discussion is interesting and I think it deserves further insights. Thanks for your contribution! Best, Paolo
Re: String at the bottom of a cover page without using \markup
> > > > Also you are wrong, recurring footers are not the rule. Many footers or > headers for example include page numbering, which tends to be different on > each page. > > (in addition to my previous message) This is not what I meant. The fact that page numbering is different on each page doesn't mean that the header is not recurring. What has to be recurring is the rule, not the content of the string. And the recurrence is the rule for footers and headers. Best, Paolo
Re: String at the bottom of a cover page without using \markup
On Saturday, December 18, 2021, Aaron Hill wrote: > On 2021-12-17 4:28 pm, Paolo Prete wrote: > >> The example Aaron showed already added *logic* to the template [...] >> > > To be fair, all I showed was the default setting for oddFooterMarkup from > titling-init.ly. Nothing added; that is simply how LilyPond works out of > the box. > > Hello Aaron, this is not what I meant with "added logic to the template". I just noted that you used some logic for defining a spefic behavior of the basic template. And this is what I would like to avoid, unless I wrap it. Therefore, when you write: > Your original query was about placing something at the bottom of a page, > and the response you have received is to leverage oddFooterMarkup as the > most direct and minimally disruptive method. > > > ... This is not right. My original query was not simply "how to place something at the bottom of the page". I explicitily added a constraint: "without using the footer markup". For the reasons I explained later. I prefer to set properties of a class/structure which hides details for this kind of stuff, instead of adding/exposing customizations/logic. This is how I proceed, when programming. From what I see, your approach is a low-level approach, therefore it should be wrapped (so to shorten the code and improve the readibility). But wrapping has some other disadvantages, as I explained later. Then I concluded that, in my general case, the best thing is to use multiple tools (which has disadvantages too, of course, but I consider it a better compromise) Best, P > -- Aaron Hill >
Re: String at the bottom of a cover page without using \markup
On Saturday, December 18, 2021, Paolo Prete wrote: > > > On Saturday, December 18, 2021, Aaron Hill > wrote: > >> On 2021-12-17 4:28 pm, Paolo Prete wrote: >> >>> The example Aaron showed already added *logic* to the template >> >> > > > > . This is how I proceed, when programming. From what I see, your approach > is a low-level approach, > (for Valentin too) Please note too that this is the reason for which it s not true what Valentin said that I "underestimate LilyPond. Instead, the opposite is true: low level tools such the one you showed, reveal how LP is powerful. But I don't want to use lower level tool for cover or introductory pages, nor I would like to spend time in wrapping them. > > > > >> -- Aaron Hill >> >
Re: String at the bottom of a cover page without using \markup
On Sat, Dec 18, 2021 at 11:57 AM Valentin Petzel wrote: > Hello Paolo, > > Please note that default values are intended to be changed if required. Hello Valentin, as said before I don't want this kind of customization: I think it reduces readability of the code (unless it is wrapped, but this would be not practical) and it is not easy to maintain. I just want to set simple fields, without any logic, without any coupling, cross-link and/or low level functions. This is what I do with LibreOffice (GUI) or with predefined templates (LaTex, WordPress etc.). I really don't know how to explain this better: please, refer to Jean's last post. It will help to understand how to focus the problem. Best, P
Re: String at the bottom of a cover page without using \markup
On Sat, Dec 18, 2021 at 10:25 AM Jean Abou Samra wrote: > Hi, > > Okay, I'll let myself sucked in this (in my opinion > unnecessarily) heated thread I really thank you for this post. It not only explains what I had in mind regarding the technical side of the thread; it also highlights a bigger problem: unnecessary heated mood. And I add that it is not only unnecessary: when there are flames without fire, it is nonsense and ridiculous too. I'm sorry if I use this harsh words, but this is what I see in all this discussion. I would like to invite the participants to note that I absolutely did NOT say any word against LP. Nor directly, nor indirectly, nor explicitly, nor in a hidden or subtle way. At the same time, I invite them (Including the helpful Aaron and Valentin) to focus on what I really tried to explain (as you did) instead of negating any assertion that seems (but it is really not) intended to reduce the LP value. Best, Paolo >
Re: String at the bottom of a cover page without using \markup
On Sat, Dec 18, 2021 at 1:38 PM Valentin Petzel wrote: > Nothing really heated here, but probably some communication issue. I try > to > listen to what you try to explain, but I hardly get anything about your > actual > problem and mostly critique how the solutions are not clean enough for you > without really reasoning why this would be that way. > > I’ve sent you an example of how we basically can get what Jean described > (which involves adding some functionality to the header and footer markups > which can be put into an include and then on line overrides (which can > also be > put into includes). You’ve then dismissed this as too much logic (when > this > actually just requires a very miniscule amount of additional > functionality. > Then when you talked about cover pages I gave you an example of a markup > function that spreads markups vertically over the page (which can then be > used > to push stuff to the bottom). > > I’m spending lots of my time trying my best to help you, and it’s really > frustrating then to get told to focus on „what you tried to explain”, > especially when you give core specifications like "I just want to set > simple > fields” randomly in the end. And this really takes away a lot of > motivation > for trying to help people on the mailing list. > > Please don't misunderstand my words: I stated many and many times that your (and Aaron's ones) examples HELPED me A LOT. Including these last ones, with which I could understand how the footer and header do work, and how they can be customized. Then you can easily understand the value of your contribution. And, of course, without these examples, I would not have focused the problem we are discussing. What I meant is different. It appears to me that when I say something, it is seen as a criticism against LP. This is absolutely not true. I just try to focus a problem which, IMHO, deserves to be discussed. That said, forgive me if I speak frankly: it appears strange to me that you and Aaron (both have huge experience with LP coding) really say that *any* of my objections is wrong. Or that you systematically start from this assumption. Probably I'm wrong with this perception, but maybe I'm not totally wrong and, in any case, this is my perception. Why do I have this perception? Let me explain. I well know and I'm sure that you have huge experience and knowledge of LP and coding. At the same time, my objections regarding the customization of headers and footers were very simple. No logic or coupling or low-level stuff at all is required. This is how stylesheets and templates do work. Therefore, no matter if you add tiny or huge logic to add. I just talked about additional logic, in the previous posts. So: why all these objections? If you add tiny logic to this method, then you corrupt it. But I'm sure that you already know this, because you surely know how stylesheets do work. This is not a "random" specification given at the end. This is the reason for which I stated from the beginning that I did not want to work on the footer, nor to couple different elements of the template. Instead of saying: "you're wrong, you're wrong, you're wrong etc." (and then I have systematically to answer: "no, it's you who are wrong", "no, it's you who are wrong" etc.) please, read with another perspective my observations. That said, I see with real regret that you loose motivation in this. I well know what it means. Of course feel free to ignore my questions (and I still thank you for your help so far) but, I would not use this behavior in general with other people. As a personal thought, I can say that my contribution to LP are totally independent of the general feedback received, as you can see when I publish an ANN of a new release of my editor (which costs to me lot of work, obviously): I simply do what I think is good to do. And I hope you'll do the same (which completely takes away possible frustration). Best, P > Valentin > > Am Samstag, 18. Dezember 2021, 12:47:34 CET schrieb Paolo Prete: > > On Sat, Dec 18, 2021 at 10:25 AM Jean Abou Samra > wrote: > > > Hi, > > > > > > Okay, I'll let myself sucked in this (in my opinion > > > unnecessarily) heated thread > > > > I really thank you for this post. It not only explains what I had in mind > > regarding the technical side of the thread; it also highlights a bigger > > problem: unnecessary heated mood. And I add that it is not only > > unnecessary: when there are flames without fire, it is nonsense and > > ridiculous too. I'm sorry if I use this harsh words, but this is what I > see > > in all this discussion. I would like to invite the participants to note > > that I absolutely did NOT
Re: String at the bottom of a cover page without using \markup
On Sat, Dec 18, 2021 at 4:44 PM Valentin Petzel wrote: > And please don't feel offended by my last mail, I'm not in the best shape, > as a friend of mine killed himself recently. > > Hello Valentin, This is really sad news, especially if it happens at a time of pandemic, which in itself is hard. As a personal advice I tell you: dedicate your time as much as possible to programming in these months, this will help you to distract yourself. Don't worry about me, I didn't feel offended at all. I was just sorry to see a so helpful and active helper/contributor like you being unmotivated to participate in discussions. > > I did not mean a random specification, but a very important core > specification at a random point. > If you read again my posts, you will find the core specification, with a specific word, since the very first posts of this thread, not at a random place. And I repeated it several times. The magic word is: *template*. At a certain point, Jean highlighted the fact that LP currently lacks the ability of stylesheeting in an easy way; then you focused the problem. But the big picture is that LP currently lacks the ability of easy-templating (and the stylesheet is only a part of this context). Currently, LP supports only one generic template out of the box (header, body, footer), which therefore needs to be customized (and its customization is somewhat uncomfortable) for any variation. Customizing a template, as a general procedure, is not a good idea, for several reasons, including readability of the code and maintenance. Therefore, typography programs offer a *set* of templates: then you pick the one that is closest to your specs, and do customizations only if you really need to. Then your code is *clean*. To be even more clear: the kind of customization you wanted to do is a hackish and messy one. In fact, you violate the template rule by putting what should be part of the body in the footer, by swapping it from the header (!) ad using a non pertinent field (copyright) (with low-level functions). This is not how I would proceed. I would avoid hacks at all on templates. And I would customize templates only for dummy things (for example: swapping header with footer) and only if I really need to. I really don't know how to explain it better. But in any case, please read again the previous posts with these observations. Hold on for the bad period. I'm sure it will go away, after some time. And consider this thread a way to get distracted from it... Best, Paolo
Re: String at the bottom of a cover page without using \markup
On Sat, Dec 18, 2021 at 6:57 PM David Kastrup wrote: > Paolo Prete writes: > > > If you read again my posts, you will find the core specification, with > > a specific word, since the very first posts of this thread, not at a > > random place. And I repeated it several times. The magic word is: > > *template*. > > That's a buzzphrase that doesn't concern _what_ you want to do but _how_ > you want to get it done. > > Not really. I expressed as a spec that I wanted to obtain my result without touching the template since the first post (---> avoid touching footer). Then, this phrase simply repeats that initial statement, where "what I want to do" has already the constraint "get it done in that way" > In essence you are complaining that you do not see a proper "On" switch > on an axe and you consider it a hack to move the axe towards wood rather > than move the wood to the cutting device. > Not really. I'm not complaining anything/anyone. The hack I highlighted has nothing to do with this example. There's already a proper "On switch" on the LP template and I see it and its rule. I just don't want to violate it, because when you have a _rule_ and you violate it for obtaining your result, I call it a "hack". > > You need to accept that your wish to do things in a certain manner is > not something others will automatically figure out just by repeatedly > hearing in essence "no, that's wrong". You will need to more actively > participate in defining what will and what will not be a manner of > arriving at a page layout that you deem acceptable. > That is what exactly I tried to do, in a *very active way*: I defined my specs since the first post, and I went into detail for them multiple times (readability, maintenance of the code etc.) . TBH I donì't understand what you are talking about. > > -- > David Kastrup >
Re: String at the bottom of a cover page without using \markup
Hello Valentin On Sat, Dec 18, 2021 at 7:35 PM Valentin Petzel wrote: > Hello Paolo, > > That is not exactly true. The first time you used the word template was > quite > some way in when you assumed that you’d need to set the markups > differently > for any possible configuration (which is where I answered you’d be > underestimating Lilypond as you do NOT need to do that. My example showed > a > way you can have ONE header/footer markup producing different results on > global flags (these could also be put inside the header block or a paper > block), basically showing you how to create a simple interface like you > wanted > (although by that point it was not clear to me that you wanted that)). > > ... but, if you pick up again that message, you will find that the interface you created did not meet my specs. Here are my words: "I should have the flexibility to switch on the fly from one choice to another, which is expected in a header + body + footer template, therefore this template should not be polluted by mixing body with footer.". In fact you redefined the template without wrapping it. Then, it should not be considered a template with the flexibilty to switch from one choice to another, but rather a customization of a template that doesn't offer that easy switch. Even if you do the easy switch as a result, this can't be used as template because you did not wrap it. And this has disadvantages, as I tried to explain, adding that I could wrap it in my own project, so to meet my specs, but this procedure would have disadvantages too. > The technical problem here is that there is no clear border between body, > header and footer (unless we are taking full control of the page, for > which I > gave you a way to do this without footer (as I said before, I did not > realize > we were talking about cover pages before that, even though it says so in > the > subject. I was expecting a first page with music on it)). This is not true, and this is what I added in my explanation later. There is such clear border: it is given by the template defaults. These are the rules for body, header and footer. When you decide to modify these rules, then you are creating a grey area, then it is needed to wrap your customization, so to create new defaults (and, consequently, a new template). When you violate this rule by modifying two instances of two implementations (footer and header) of an interface, instead of creating new instances, then you are doing a hack which makes the code even dirtier, then a wrap is doubly needed. In the example we are discussing, the motto is logically part of the body. Then, given that the LP template doesn't meet this specs, a new template should be created by wrapping a customization of the original one. Then you have clean code and you can have new clear borders. As you can see, this is a tedious procedure, and this is why I prefer to use alternative tools. > But let’s be specific about the problem: So your aim here is to create > templates? Or do just want to create a cover page with something at the > bottom? my aim (which is not what I asked at the beginning of the thread, though) is not to create templates (I don't have time for now), but to have a way to have them for the next future. And I got this result with the alternative tool. And, of course, with the help of your (and Aaron's) examples, which made me understand how the things works in LP. Therefore you are wrong when you feel unmotivated for the things you read. You should consider the opposite... Please note that there's nothing strange in using an alternative tool for this. And I would leave the LP code totally untouched for these tasks. IMHO LP doesn't need to have such sophisticated tools for cover pages, as Jean wished. It would be totally beyond its scope. Therefore I find ridiculous (and pathetic at the same time) when my words appear as a blame. Best, Paolo
Re: String at the bottom of a cover page without using \markup
The vertical-fill method does exactly what I asked in the very first post. But soon after, thanks to this thread, I saw some limitations in a pure-LilyPond approach, which I did not know: therefore I stated, *before* you made this example: "I well know, and stated several times, that LilyPond has the power of a nuclear reactor. And I'm sure too that with customizations you can do whatever you want in the cover/introductory pages. What I meant is different. For these pages I don't want to add or expose logic. " As you can see, your example adds a hard customization for a task that should be easy in creating cover pages. If I sum all the effort for doing such easy things on cover pages I realize that it is better to have an easier and faster tool for creating such pages, instead of growing the code with work-arounds, custom functions etc. In addition, you would not have to bother in case you are stuck in similar future situations, nor it's required that you learn low-level LP. Please note that you wrote the example *after* I decided to use this alternative, and after I stated that in my case the problem was already solved. "From what I see, your approach is a low-level approach, therefore it should be wrapped (so to shorten the code and improve the readibility). But wrapping has some other disadvantages, as I explained later. Then I concluded that, in my general case, the best thing is to use multiple tools (which has disadvantages too, of course, but I consider it a better compromise) " That said, the thread continued because it highlighted interesting points that deserved to be discussed. What I want to say is that you already gave me the solution of the problem, indirectly, by making me learn how the stuff works. Best, Paolo On Sat, Dec 18, 2021 at 10:15 PM Valentin Petzel wrote: > Hello Paolo, > > Yes, that makes sense. This was never meant as some full working > implementation but just as an example. > > Still, what problems did you have with the vertical-fill method? This > should > work quite well for cover pages and such. > > Cheers, > Valentin > > Am Samstag, 18. Dezember 2021, 21:13:57 CET schrieb Paolo Prete: > > Hello Valentin > > > > On Sat, Dec 18, 2021 at 7:35 PM Valentin Petzel > wrote: > > > Hello Paolo, > > > > > > That is not exactly true. The first time you used the word template was > > > quite > > > some way in when you assumed that you’d need to set the markups > > > differently > > > for any possible configuration (which is where I answered you’d be > > > underestimating Lilypond as you do NOT need to do that. My example > showed > > > a > > > way you can have ONE header/footer markup producing different results > on > > > global flags (these could also be put inside the header block or a > paper > > > block), basically showing you how to create a simple interface like you > > > wanted > > > (although by that point it was not clear to me that you wanted that)). > > > > ... but, if you pick up again that message, you will find that the > > interface you created did not meet my specs. Here are my words: > > "I should have the flexibility to switch on the fly from one choice to > > another, which is expected in a header + body + footer template, > therefore > > this template should not be polluted by mixing body with footer.". In > fact > > you redefined the template without wrapping it. Then, it should not be > > considered a template with the flexibilty to switch from one choice to > > another, but rather a customization of a template that doesn't offer that > > easy switch. Even if you do the easy switch as a result, this can't be > used > > as template because you did not wrap it. And this has disadvantages, as I > > tried to explain, adding that I could wrap it in my own project, so to > meet > > my specs, but this procedure would have disadvantages too. > > > > > The technical problem here is that there is no clear border between > body, > > > header and footer (unless we are taking full control of the page, for > > > which I > > > gave you a way to do this without footer (as I said before, I did not > > > realize > > > we were talking about cover pages before that, even though it says so > in > > > the > > > subject. I was expecting a first page with music on it)). > > > > This is not true, and this is what I added in my explanation later. There > > is such clear border: it is given by the template defaults. These are the > > rules for body, header and footer. When you decide to modify these rules, > > then you are creating
Re: String at the bottom of a cover page without using \markup
On Sat, Dec 18, 2021 at 11:09 PM Paolo Prete wrote: > The vertical-fill method does exactly what I asked in the very first post. > But soon after, thanks to this thread, I saw some limitations in a > pure-LilyPond approach, which I did not know: therefore I stated, *before* > you made this example: > > "I well know, and stated several times, that LilyPond has the power of a > nuclear reactor. > And I'm sure too that with customizations you can do whatever you want in > the cover/introductory pages. > What I meant is different. For these pages I don't want to add or expose > logic. " > > As you can see, your example adds a hard customization for a task that > should be easy in creating cover pages. If I sum all the effort for doing > such easy things on cover pages I realize that it is better to have an > easier and faster tool for creating such pages, instead of growing the code > with work-arounds, custom functions etc. In addition, you would not have to > bother in case you are stuck in similar future situations, nor it's > required that you learn low-level LP. > Please note that you wrote the example *after* I decided to use this > alternative, and after I stated that in my case the problem was already > solved. > > "From what I see, your approach is a low-level approach, therefore it > should be wrapped (so to shorten the code and improve the readibility). But > wrapping has some other disadvantages, as I explained later. Then I > concluded that, in my general case, the best thing is to use multiple tools > (which has disadvantages too, of course, but I consider it a better > compromise) " > > That said, the thread continued because it highlighted interesting points > that deserved to be discussed. What I want to say is that you already gave > me the solution of the problem, indirectly, by making me learn how the > stuff works. > > One last thing: I would like to encourage Valentin to push his fill-vertical-line function to the main repo. it's not important that it doesn't cover my general case: what is important is that it fills a hole in standard LP, because a fill-vertical-line is IMHO required for several cases in basic cover or introductory pages. A fill-line is already in standard LP: so, why not a fill-vertical-line too? Best, P > Best, > Paolo > > > > On Sat, Dec 18, 2021 at 10:15 PM Valentin Petzel > wrote: > >> Hello Paolo, >> >> Yes, that makes sense. This was never meant as some full working >> implementation but just as an example. >> >> Still, what problems did you have with the vertical-fill method? This >> should >> work quite well for cover pages and such. >> >> Cheers, >> Valentin >> >> Am Samstag, 18. Dezember 2021, 21:13:57 CET schrieb Paolo Prete: >> > Hello Valentin >> > >> > On Sat, Dec 18, 2021 at 7:35 PM Valentin Petzel >> wrote: >> > > Hello Paolo, >> > > >> > > That is not exactly true. The first time you used the word template >> was >> > > quite >> > > some way in when you assumed that you’d need to set the markups >> > > differently >> > > for any possible configuration (which is where I answered you’d be >> > > underestimating Lilypond as you do NOT need to do that. My example >> showed >> > > a >> > > way you can have ONE header/footer markup producing different results >> on >> > > global flags (these could also be put inside the header block or a >> paper >> > > block), basically showing you how to create a simple interface like >> you >> > > wanted >> > > (although by that point it was not clear to me that you wanted that)). >> > >> > ... but, if you pick up again that message, you will find that the >> > interface you created did not meet my specs. Here are my words: >> > "I should have the flexibility to switch on the fly from one choice to >> > another, which is expected in a header + body + footer template, >> therefore >> > this template should not be polluted by mixing body with footer.". In >> fact >> > you redefined the template without wrapping it. Then, it should not be >> > considered a template with the flexibilty to switch from one choice to >> > another, but rather a customization of a template that doesn't offer >> that >> > easy switch. Even if you do the easy switch as a result, this can't be >> used >> > as template because you did not wrap it. And this has disadvantages, as >> I >> > tried to explain,
ANN: Spontini-Editor version 1.12-alfa
Hello, I have published a new version of Spontini-Editor (1.12-alpha): it is still in the testing phase and therefore not available in the list of releases, but it is already working and it can be downloaded from the main project page. https://github.com/paopre/Spontini The important features of this version are: 1) support for PDF output, in order to speed up the compilation of scores. Thanks to the PDF mode, instead of SVG, the compilation time drastically decreases: once the score has been sketched it is possible to switch to SVG mode, in order to complete it through tweaks with the mouse. 2) MIDI input: it is now possible to enter notes / chords via a MIDI device, using the Web MIDI API on both Chrome and Firefox. It is also possible to insert these notes automatically in the tables for the creation of piano / cross-staff music. In this case the notes are automatically inserted in the upper staff, but they can then be quickly moved to the lower staff (or vice versa) with the arrow keys of the keyboard (see the image below) https://github.com/paopre/Spontini/blob/master/documentation/images/midiInput.gif https://github.com/paopre/Spontini/blob/master/documentation/miscellaneous.md HTH, P.
Re: ANN: Spontini-Editor version 1.12-alfa
Thanks for these infos. 1) once I download a development snapshot, how can I test it? 2) Is there a plan of when it will be included into a released version? 3) Is it already well working, or is it in unstable/buggy state? Cheers, P On Friday, February 11, 2022, Jean Abou Samra wrote: > Le 11/02/2022 à 00:33, Paolo Prete a écrit : > >> 1) support for PDF output, in order to speed up the compilation of >> scores. Thanks to the PDF mode, instead of SVG, the compilation time >> drastically decreases: once the score has been sketched it is possible to >> switch to SVG mode, in order to complete it through tweaks with the mouse. >> > > > For your information, a new backend for LilyPond has been developed > over the last year, based on the Cairo library, which solves this > problem (it makes PDF output a bit faster and brings SVG on par > with PDF in speed). This is just a heads-up, since it not enabled > in released versions yet. > > Best, > Jean > > >
Re: ANN: Spontini-Editor version 1.12-alfa
Hello, I tested the editor on macOS Catalina, with LilyPond 2.22.0 from unofficial 64-bit app bundles and had no problems. 1) Which browser are you using? 2) Please can you paste the complete log of the SpontiniServer window on the issues page of GitHub https://github.com/paopre/Spontini/issues (or pm to my email)? thanks On Fri, Feb 11, 2022 at 11:18 AM Thomas Scharkowski < t.scharkow...@t-online.de> wrote: > > > > Am 11.02.2022 um 00:33 schrieb Paolo Prete : > > > > Hello, > > > > I have published a new version of Spontini-Editor (1.12-alpha): it is > still in the testing phase and therefore not available in the list of > releases, but it is already working and it can be downloaded from the main > project page. > > > > https://github.com/paopre/Spontini > > > > The important features of this version are: > > > Hello, > > after installation I get an application window at > localhost:8000/spontini-editor/, but cannot use it: > > "Error while connecting to SpontiniServer.“ > > Did I miss something? > > Thomas > > macOS Monterey 12.1 > LilyPond 2.23.6 > >
Re: ANN: Spontini-Editor version 1.12-alfa
Thanks, I was not aware of it and I'll surely test it ASAP Cheers, P On Fri, Feb 11, 2022 at 1:10 PM Jean Abou Samra wrote: > > Le 11/02/2022 11:07, Paolo Prete a écrit : > > > > > > Thanks for these infos. > > > > > > 1) once I download a development snapshot, how can I test it? > > > If you mean an unstable release, you cannot, since these > aren't built with Cairo yet -- the switch to Guile 2 > and the new infrastructure for binaries was already enough > for a single release. So if you want to test it (which > will be very much appreciated if you can report any > problems you find), you have to compile LilyPond yourself > by following the procedure described in > > http://lilypond.org/doc/v2.23/Documentation/contributor/compiling > > To enable Cairo, you have to configure with > > ../configure --enable-cairo-backend > > and then you run with Cairo using > > lilypond --svg -dbackend=cairo file.ly > > (if you use --svg, -dbackend=cairo must be last). > > > > 2) Is there a plan of when it will be included into a released version? > > I haven't followed this story very closely, but I guess > it will be included at some point in this development > series. When it will become the default is another question. > > > > 3) Is it already well working, or is it in unstable/buggy state? > > Working quite well overall. > > Best, > Jean >
Question about cairo backend
Hello, I'm testing the cairo backend on SVG output. However, it doesn't seem to support metadata through output-attributes, nor point-and-click links. After reading this thread https://www.mail-archive.com/lilypond-devel@gnu.org/msg77712.html ... it appears to me that the lack of hyperlinks is in the TODO list. But what about metadata (output-attributes)? Are they in the TODO list as well? Best, P
Re: ANN: Spontini-Editor version 1.12-alfa
Hello Jan-Peter, thanks for your contribution! There's already a docker setup for the editor, similar to yours, together with other very useful setups (ly2video, fonts etc.), made by Alexis: https://github.com/jeandeaual/docker-lilypond/pulls However, it's not pushed yet because we have to find a practical way to solve an issue which appears in your setup too: the need to use the 0.0.0.0 address with HTTP, which could be unsafe. It is possibile, with Spontini, to use certs, so to switch to HTTPS and avoid this issue: https://github.com/paopre/Spontini/blob/master/documentation/webserver.md However, this could be a bit cumbersome with docker, because the user would have to create certs and then push them to the container through some command. If we find a shorter way to obtain a HTTPS setup it would be much better. I don't know if a sort of duckdns plugin can be a solution... Please let me know if you have any idea about this. Cheers Paolo On Saturday, February 19, 2022, Jan-Peter Voigt wrote: > Hello Paolo, > > I really like Spontini and created a docker setup to test it. I just > started it again. It takes some time to build, but then one can use it > from http://localhost:8000/spontini-editor/. > > Best > Jan-Peter > > Am 11.02.22 um 00:33 schrieb Paolo Prete: > > Hello, > > > > I have published a new version of Spontini-Editor (1.12-alpha): it is > > still in the testing phase and therefore not available in the list of > > releases, but it is already working and it can be downloaded from the > > main project page. > > > > https://github.com/paopre/Spontini > > > > The important features of this version are: > > > > 1) support for PDF output, in order to speed up the compilation of > > scores. Thanks to the PDF mode, instead of SVG, the compilation time > > drastically decreases: once the score has been sketched it is possible > > to switch to SVG mode, in order to complete it through tweaks with the > > mouse. > > > > 2) MIDI input: it is now possible to enter notes / chords via a MIDI > > device, using the Web MIDI API on both Chrome and Firefox. It is also > > possible to insert these notes automatically in the tables for the > > creation of piano / cross-staff music. > > In this case the notes are automatically inserted in the upper staff, > > but they can then be quickly moved to the lower staff (or vice versa) > > with the arrow keys of the keyboard (see the image below) > > > > https://github.com/paopre/Spontini/blob/master/documentation/images/ > midiInput.gif > > > > https://github.com/paopre/Spontini/blob/master/ > documentation/miscellaneous.md > > > > HTH, > > P. > >
Re: About cross-staff beaming in voiceTwo
Hello, for complex cross-staff music I would suggest you to try this: https://github.com/paopre/Spontini/blob/master/documentation/tabular.md You can save much time while improving the readability of the code. Cheeers On Monday, February 28, 2022, Rip _Mus wrote: > Hello everyone, > here's a problem I am encountering: > [image: image.png] > > So, with the "\change" construct put in voiceTwo, there's no automatic > kneed-beam. > Also tried to override the Beam.auto-knee-gap value, but no way to obtain > the knee. > Hope there is a way to get what I'm looking for. > > Thank you > > Rip_mus >
Re: Lilybin?
Hello, FYI this editor completely works over the web: https://github.com/paopre/Spontini I hope someone will decide to host it... Best, P On Wednesday, June 1, 2022, Kevin Cole wrote: > I hadn't heard of either LilyBin or HacLily. > > So... Basically Frescobaldi over the web, yes? > > Other than the collaborative, distributed nature -- which I can see as > advantageous in some situations -- do they have features that Frescobaldi > doesn't have? > >
Re: Lilybin?
On Friday, June 3, 2022, Knute Snortum wrote: > On Wed, Jun 1, 2022 at 4:55 AM Paolo Prete wrote: > > > > Hello, > > > > FYI this editor completely works over the web: > > > > > > https://github.com/paopre/Spontini > > > > > > I hope someone will decide to host it... > > Too buggy for Prime Time. Can't save a file, > Of course you can. Just do: 1) File -> save / save as Or 2) ctrl + s > can't pick which folder > to save in, > Of course you can. Just do: options -> set workspace > > > can't engrave a file (says I must save), > > If you don't want to save before engraving just fork the file > > etc. ?
Invisible midi layer for specific measures
Hello,
please, consider this snippet:
http://lilybin.com/ttlid3/1
I would like to add an invisible midi layer of notes to the previous ones so
that I can obtain, when required, effects (for example: the tremolo) that are
not provided by default, without using the "articulate" script.
In the previous snippet I want to generate the following midi notes for measure
2:
\repeat unfold 4 {d'32 f'} g'4 g' g'
And I want the default generated midi for the other measures.
Is there a way/hack to obtain that? I remember that someone else asked a
similar question in the past, but I can't find the post...
Many thanks for your help.
Paolo
Re: Invisible midi layer for specific measures
Thank you Karl for your help.
However, in the way you suggested, I have to repeat the music of the first
\score block into the second \score block for the first and third measure of my
snippet. I would like to avoid this redundancy, and I would like to specify the
notes of "custom" generated midi only for for a subset of specific measures.
Il lunedì 11 novembre 2019, 20:37:34 CET, k...@aspodata.se
ha scritto:
Paolo:
...
> I would like to add an invisible midi layer of notes to the
> previous ones
...
Use this template:
\score {
<<
% displayed music
>>
\layout {
}
}
\score {
\unfoldRepeats
<<
% midi music
>>
\midi { }
}
Re: Invisible midi layer for specific measures
Thanks Aaron,
it worked perfectly.
Il lunedì 11 novembre 2019, 21:29:36 CET, Aaron Hill
ha scritto:
On 2019-11-11 12:16 pm, Paolo Prete wrote:
> Thank you Karl for your help.
> However, in the way you suggested, I have to repeat the music of the
> first \score block into the second \score block for the first and
> third measure of my snippet. I would like to avoid this redundancy,
> and I would like to specify the notes of "custom" generated midi only
> for for a subset of specific measures.
Variables and tags are helpful. Consider:
\version "2.19.83"
asdf = \fixed c' {
| c4 d e2
| \tag #'display { 1_\trill }
\tag #'midi { \repeat unfold 4 { f8 g } }
| a4 b c'2
}
\score { \keepWithTag #'display \asdf \layout {} }
\score { \keepWithTag #'midi \asdf \midi { \tempo 1 = 60 } }
-- Aaron Hill
Cross-staff notes using only one music expression
Hello, in the following snippet, I can obtain a cross-staff tremolo: http://lilybin.com/y4csd8/1 However, in this way, I'm forced to fill the "up" staff with invisible rests ( in this case: s4. ) for the duration of the tremolo. Is there a way to avoid this and use only one music expression for the cross-staff notes? Thanks
Display the control points of a slur
Hello,
please consider this snippet:
\relative c'' { \shape #'((0 . -1) (5.5 . -0.5) (-5.5 . -10.5) (0 . -5.5))
PhrasingSlur c8\( e b f d' a e g\)}
Is there a helper function or some script for displaying the control points of
the slur (for example with a red color)? Is it possible to display the
coordinates near the points too?
I found that:
openlilylib/oll-misc
|
|
|
| | |
|
|
|
| |
openlilylib/oll-misc
Miscellaneous tools and functions for LilyPond. Contribute to
openlilylib/oll-misc development by creating an ac...
|
|
|
But I can't figure how to use it in the previous snippet...
Thanks
Re: Display the control points of a slur
Hello,
I wonder if is there a script or a snippet for doing that without using
Frescobaldi
Il mercoledì 13 novembre 2019, 15:29:45 CET, Urs Liska
ha scritto:
Frescobaldi provides this with the Tools=>Layout Control mode. However chances
are that it's broken in a versio accessible to you.
Urs
Am 13. November 2019 15:22:05 MEZ schrieb Paolo Prete :
Hello,
please consider this snippet:
\relative c'' { \shape #'((0 . -1) (5.5 . -0.5) (-5.5 . -10.5) (0 . -5.5))
PhrasingSlur c8\( e b f d' a e g\)}
Is there a helper function or some script for displaying the control points of
the slur (for example with a red color)? Is it possible to display the
coordinates near the points too?
I found that:
openlilylib/oll-misc
|
|
|
| | |
|
|
|
| |
openlilylib/oll-misc
Miscellaneous tools and functions for LilyPond. Contribute to
openlilylib/oll-misc development by creating an ac...
|
|
|
But I can't figure how to use it in the previous snippet...
Thanks
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: Display the control points of a slur
Thanks very much Aaron,
I propose to include your snippet in a new release of Lilypond because it's
very useful.
Il mercoledì 13 novembre 2019, 16:19:29 CET, Aaron Hill
ha scritto:
On 2019-11-13 7:00 am, Aaron Hill wrote:
> On 2019-11-13 6:32 am, Paolo Prete wrote:
>> Hello,
>> I wonder if is there a script or a snippet for doing that without
>> using Frescobaldi
>
> Probably not perfect, but here's something you can fiddle with:
Updated to ensure the stencil's extents are the same as the original
also using a slightly cleaner approach:
\version "2.19.83"
showControlPoints = #(grob-transformer 'stencil (lambda (grob orig)
(define (draw-control-point pt)
#{ \markup \translate $pt \with-color #red \draw-circle #0.2 #0 ##t
#})
(define (draw-control-segment pt1 pt2)
(let ((delta (cons (- (car pt2) (car pt1)) (- (cdr pt2) (cdr
pt1)
#{ \markup \translate $pt1 \with-color #'(1 .5 0) \draw-line
$delta #}))
(let* ((pts (ly:grob-property grob 'control-points))
(dots (map draw-control-point pts))
(lines (map draw-control-segment pts (cdr pts
(grob-interpret-markup grob #{
\markup \with-dimensions-from \stencil $orig \overlay {
\overlay { $@lines } \overlay { $@dots } \stencil $orig } #}
\layout { \context { \Voice
\override PhrasingSlur.stencil = #showControlPoints
\override Slur.stencil = #showControlPoints
\override Tie.stencil = #showControlPoints
} }
\fixed c' { e4\( b2._~ | b2( e'8 c') a4\) }
-- Aaron Hill
system-system-spacing
Hello,
the following syntax was good for some old version of lilypond but obsolete for
2.19:
\paper { system-system-spacing #'basic-distance = #28 ...
How can I replace it?
Thanks
How to color objects that cause collision
Hello, I think that a very useful function would be a way to highlight or change the color for all the objects that are causing a collision.Is there already some code for that?Look for example at the two slurs in the following snippet: LilyPond Score | | | | LilyPond Score LilyPond Score made using LilyBin. | | | When there are many and many graphic objects on a score, it's easy to ignore some of these errors relying on observation only...
Re: How to color objects that cause collision
I don't think it's a bug. It's a snippet from the official documentation.Look at the first snippet in the following page, there's a collision as well: LilyPond Learning Manual: 4.6.3 Real music example | | | | LilyPond Learning Manual: 4.6.3 Real music example LilyPond Learning Manual: 4.6.3 Real music example | | | A function that helps in discovering these things would be really useful... Il venerdì 15 novembre 2019, 11:01:14 CET, Malte Meyn ha scritto: Am 15.11.19 um 01:50 schrieb Paolo Prete: > > I think that a very useful function would be a way to highlight or > change the color for all the objects that are causing a collision. > Is there already some code for that? > Look for example at the two slurs in the following snippet: > > […] > > When there are many and many graphic objects on a score, it's easy to > ignore some of these errors relying on observation only... If LilyPond knew that there was a collision it wouldn’t engrave it that way so IMO that’s a bug. Without knowing about a collision LilyPond cannot tell you about it ;)
Set a temporary tempo change
Hello,
is it possible to revert a tempo change to the previous tempo setting, without
explicitly writing this previous one?
Something like (pseudo-code):
\tempo 4 = 120 { ...some music } \temporaryTempo 4 = 160 { ... some other
music } \unset \temporaryTempo
This would be useful for the midi output...
Thanks
Problem on the dynamics of the midi output
Hello.
I can't find a way to have a single sequence of dynamics that affects both
upper and lower piano staves in the MIDI output.I tried the following snippet
but I can't hear any variation of the dynamics in the midi file.
%%%
\score {<< \new PianoStaff << \new Staff="up" { c'4 c' r r } \new
Dynamics { s4\fff s s\ppp s} \new Staff="down" { r4 r c' c' }
\layout { }\midi { }}
%
In addition, I wonder if is there a way to obtain the same result without
having to add a "Dynamics" separate context...
thanks
Re: Set a temporary tempo change
Aaron,
that's great.I propose to the ML to add the function to the official release.
It's very helpful when you want to make the midi output more realistic, with
frequent tempo changes
Il lunedì 18 novembre 2019, 00:11:29 CET, Aaron Hill
ha scritto:
On 2019-11-17 12:38 pm, Paolo Prete wrote:
> Hello,
> is it possible to revert a tempo change to the previous tempo setting,
> without explicitly writing this previous one?
> Something like (pseudo-code):
> \tempo 4 = 120 { ...some music } \temporaryTempo 4 = 160 { ...
> some other music } \unset \temporaryTempo
Not sure if this is really the right way to do things:
\version "2.19.83"
#(define tempoStack '())
pushTempo = #(define-music-function () ()
(define (pushTempoHelper ctx)
(let ((tempo (ly:context-property ctx 'tempoWholesPerMinute #f)))
(set! tempoStack (cons tempo tempoStack
#{ \context Score \applyContext $pushTempoHelper #})
popTempo = #(define-music-function () ()
(define (popTempoHelper ctx)
(let ((tempo (car tempoStack)))
(ly:context-set-property! ctx 'tempoWholesPerMinute tempo)
(set! tempoStack (cdr tempoStack
#{ \context Score \applyContext $popTempoHelper #})
\score {
{
\markLengthOn
\bar "||" \tempo "Andante" 4=90
\repeat unfold 2 { b'4 4 4 4 }
\bar "||" \pushTempo \tempo "Allegro" 4=140
\repeat unfold 2 { b'4 4 4 4 }
\bar "||" \popTempo \tempo "a tempo"
\repeat unfold 2 { b'4 4 4 4 }
}
\layout {} \midi {}
}
-- Aaron Hill
Bug on MIDI dynamics
Hello, Regarding my previous question, I just checked that there's a bug on the dynamics of the produced midi output for a piano staff.The bug can be reproduced on the 2.19 version. Please, check this snippet ( from http://lsr.di.unimi.it/LSR/Item?id=357 ), with Lilybin http://lilybin.com/eg700v/1 The same error doesn't occur if you compile the snippet with 2.18 version. 1) Is there a workaround for that?2) Is there a particular version of the 2.19 branch that doesn't cause the bug? ThanksPaolo
Re: Bug on MIDI dynamics
It appears to happen because the 2.19 version seems to associate the MIDI output per-voice instead of per-staff. As a (ugly) workaround I used this (setting and soon after unsetting a voice): LilyPond Score | | | | LilyPond Score LilyPond Score made using LilyBin. | | | It works, but I wonder if is there something better for fixing the problem, even as a workaround... Il lunedì 18 novembre 2019, 17:00:36 CET, Paolo Prete ha scritto: Hello, Regarding my previous question, I just checked that there's a bug on the dynamics of the produced midi output for a piano staff.The bug can be reproduced on the 2.19 version. Please, check this snippet ( from http://lsr.di.unimi.it/LSR/Item?id=357 ), with Lilybin http://lilybin.com/eg700v/1 The same error doesn't occur if you compile the snippet with 2.18 version. 1) Is there a workaround for that?2) Is there a particular version of the 2.19 branch that doesn't cause the bug? ThanksPaolo
Re: Bug on MIDI dynamics
Thanks Thomas. Your note fixed all.
I found the per-voice association casually, then I even googled "lilypond
dynamics per-voice" but could not find anything specific for 2.19: then,
without your suggestion, given that this default behaviour is not documented
and the official snippets use another default behaviour, it seemed a bug.
Il lunedì 18 novembre 2019, 22:09:49 CET, Thomas Morley
ha scritto:
Am Mo., 18. Nov. 2019 um 17:00 Uhr schrieb Paolo Prete :
>
> Hello,
>
> Regarding my previous question,
Please link to it.
> I just checked that there's a bug on the dynamics of the produced midi output
> for a piano staff.
> The bug can be reproduced on the 2.19 version. Please, check this snippet (
> from http://lsr.di.unimi.it/LSR/Item?id=357 ), with Lilybin
>
> http://lilybin.com/eg700v/1
>
>
> The same error doesn't occur if you compile the snippet with 2.18 version.
>
> 1) Is there a workaround for that?
> 2) Is there a particular version of the 2.19 branch that doesn't cause the
> bug?
>
> Thanks
> Paolo
I don't see any bug- nor error-description...
Dynamics are associated per Voice since 2.19.x.
In a Dynamics-context usually spacers are used, so it's pure graphic.
The voice-association seems to be a reasonable default.
If you want it different, add the "Dynamic_performer" to the context
of your choice in \midi {}
Probably a documentation-issue.
Cheers,
Harm
Re: Problem on the dynamics of the midi output
Thanks. One more question: is it possible to associate both the dynamics of
the upper and lower staves to the same voice without the "\new Dynamics {...}"
token?
For example, if I have:
\new PianoStaff << \new Staff="up" { c'4 c' r r }
\new Staff="down" { r4\ppp r c'\fff c' } >>
I would like to display "ppp" below the rest on the lower staff, but apply it
to c'4 in the midi output of the upper staff too. In other terms: a "global"
dynamics line with dynamics that affect both the staves and that I can choose
to place below the upper or the lower one.
ThanksIl lunedì 18 novembre 2019, 22:01:00 CET, Thomas Morley
ha scritto:
Am Mo., 18. Nov. 2019 um 02:37 Uhr schrieb Paolo Prete :
>
> Hello.
>
> I can't find a way to have a single sequence of dynamics that affects both
> upper and lower piano staves in the MIDI output.
> I tried the following snippet but I can't hear any variation of the dynamics
> in the midi file.
>
> %%%
>
> \score {
> <<
> \new PianoStaff <<
> \new Staff="up" { c'4 c' r r }
> \new Dynamics { s4\fff s s\ppp s}
> \new Staff="down" { r4 r c' c' }
> >>
> >>
> \layout { }
> \midi { }
\midi {
\context {
\Staff
\consists "Dynamic_performer"
}
}
> }
>
> %
Cheers,
Harm
How to obtain the same midi channel for both the staves of a PianoStaff
Hello,
in the following snippet the same midi channel is assigned to both the voices
inside the same staff
% upper = { a'4 b' r r}
lower = { r\ppp r\fff c''4 d''}
\score { \new Staff << \new Voice { \upper } \new Voice {
\lower } >> \layout { } \midi { \context { \Staff
\consists "Dynamic_performer" } } }
%
If I use a PianoStaff, instead of the above two voices inside "\newStaff", how
can I assign the same midi channel for both the upper and lower staves as well?
... \new PianoStaff << \new Staff = "up" { \upper } \new Staff
= "down" { \lower } >>...
ThanksPaolo
Re: How to obtain the same midi channel for both the staves of a PianoStaff
According to this post:
Re: MIDI assignment: two staffs to same channel
|
|
|
| | |
|
|
|
| |
Re: MIDI assignment: two staffs to same channel
|
|
|
I set the channelMapping for the same instrument (see the snippet below). But
it still produces two separate channels (tested with 2.19.82). What's wrong?
Note that the flute is correctly heard as the instrument...
\score { \new Staff << \new Staff { \set Staff.midiInstrument =
#"flute" a'4 b' r r } \new Staff { \set Staff.midiInstrument = #"flute"
r\ppp r\fff c''4 d'' } >> \layout { } \midi { \context {
\Score midiChannelMapping = #'instrument } } }
Il giovedì 21 novembre 2019, 01:22:18 CET, Paolo Prete
ha scritto:
Hello,
in the following snippet the same midi channel is assigned to both the voices
inside the same staff
% upper = { a'4 b' r r}
lower = { r\ppp r\fff c''4 d''}
\score { \new Staff << \new Voice { \upper } \new Voice {
\lower } >> \layout { } \midi { \context { \Staff
\consists "Dynamic_performer" } } }
%
If I use a PianoStaff, instead of the above two voices inside "\newStaff", how
can I assign the same midi channel for both the upper and lower staves as well?
... \new PianoStaff << \new Staff = "up" { \upper } \new Staff
= "down" { \lower } >>...
ThanksPaolo
replace a notehead with a centered text
Hello,
how can I replace a notehead with "some text" centered on the stem?
If I use:
customNotehead = {\once \override NoteHead.stencil = #ly:text-interface::print
\once \override NoteHead.text = \markup { \fontsize #6 "some text" }}
the notehead is always at the left or at the right of its stem...
thank youP
Generate pitches between pitches
Hello, given two pitches, for example: c' and c'', is there a way to automatically generate all the pitches between them? In three different ways: 1) all the "white keys" between them: d' e' f' g' a' b'2) all the "black keys" between them: des' ees' ges' aes' bes'3) all the pitches: des' d' ees' e' f' ges' g' aes' a' bes' b' This feature would be very useful for simulating (piano) glissandos with MIDI. thanks.
Display the name of the staff of a note/rest/chord/skip-event
Hello, given a note/rest/chord/skip-event is there a way to display the name of its staff? I need to check if it belongs to staff "UP" or "DOWN" of a piano-staff.What if I use map-some-music() function? (map-some-music (lambda (evt) (let ((name (ly:music-property evt 'name))) (cond ((or (eq? name 'NoteEvent )(eq? name 'EventChord) (eq? name 'RestEvent ) (eq? name 'SkipEvent )) %%% (display ?) % evt) (else #f ; => #f = continue, go deeper music) Thanks.
Set the size of the arrow of an arpeggio
Hello, how can I modify the size of the arrow of an \arpeggioArrowUp/Down object? Thanks
Re: Size of the arpeggio's arrow
Hi Thomas.Yes, I'm interested. I could not find any snippet for that, nor a corresponding property for "Arpeggio" in the "Lilypond Internals Reference"Thanks. Il giovedì 5 dicembre 2019, 16:22:12 GMT, Thomas Morley ha scritto: Am Do., 5. Dez. 2019 um 15:07 Uhr schrieb Paolo Pr : > > (I re-post this because it seems that mails from Yahoo services, like some of > my previous posts, are filtered as spam) > > Hello, > > how can I modify the size of the arrow of an \arpeggioArrowUp/Down object? > > Thanks > There is no builtin method to do so. You could create your own stencil, though. Interested in learning howto? Cheers, Harm
Request for a cross-staff easy function
Hi all,
I think this function would be very useful for solving the limitations of
the current cross-staff interface:
crossStaffExpr = #(define-music-function (parser location staffUpMusic
staffDownMusic beamPosition) (ly:music? ly:music? number?) .
Example:
\crossStaffExpr = { c '[ d'g' s}
{ s s f ' a'] } # 'BeamUp
(the third parameter can be: BeamUp, BeamDown, or BeamBetween, where
BeamBetween places the beam between the two staves; BeamBetween can only be
used if there are no cross-staff chords)
I ask you if there are any generous volunteers who want to implement it, in
case it requires not so many lines of code.
in case it requires many lines of code, is it worth opening a ticket in the
dev ml?
Thanks in advance
P
Re: A Javascript test code for modifying ties and slurs with mouse
Thanks Aaron, it did the trick. However, how can I make it work for multiple pages output? On Sat, Dec 14, 2019 at 4:26 AM Aaron Hill wrote: > On 2019-12-13 5:59 pm, Paolo Pr wrote: > > First of all, I need to add with Lilypond a tag to the svg > > file > > just before the ending tag in the following way: > > > > 1) > > > >