Re: How to submit a feature request (issue)

Le dimanche 02 juillet 2023 à 23:25 -0700, Curt McDowell a écrit : > > I don't think it's tenable to expect anyone to keep a separate version of > LilyPond for each unique \version called for by all the scores in their > library. In the current system, that would be the only way to guarantee > co

Re: How to submit a feature request (issue)

I don't think it's tenable to expect anyone to keep a separate version of LilyPond for each unique \version called for by all the scores in their library. In the current system, that would be the only way to guarantee correct and consistent output. I'd hesitate to call the LilyPond version sys

Re: How to submit a feature request (issue)

Le samedi 01 juillet 2023 à 11:30 -0700, Curt McDowell a écrit : > I tend not to use convert-ly because I feel upgrading a file version > would unfairly force anyone who wants to compile my music to upgrade > their LilyPond installation. Upgrading might not be straightforward when > using a stan

Re: How to submit a feature request (issue)

how to submit a feature request issue. I'd like to request the following change to the LilyPond parser: One feature that would be useful is for the LilyPond parser to output the following version numbers: The LilyPond version, e.g. 2.24.1; The source file "\version", e.g. 2.22.0. If

Re: How to submit a feature request (issue)

Le samedi 01 juillet 2023 à 12:46 +0200, Valentin Petzel a écrit : > Maybe Lilypond should also give a warning if it on a lower language version. > The assumption here is that lower language versions are generally compatible > with higher program versions, but this is not true. So basically we on

Re: How to submit a feature request (issue)

Maybe Lilypond should also give a warning if it on a lower language version. The assumption here is that lower language versions are generally compatible with higher program versions, but this is not true. So basically we only guarantee that a specific language version will be working with the s

Re: How to submit a feature request (issue)

Le vendredi 30 juin 2023 à 15:36 -0700, Stu McKenzie a écrit : > > I'm not sure how to submit a feature request issue. > > I'd like to request the following change to the LilyPond parser: > > One feature that would be useful is for the LilyPond parser to output >

How to submit a feature request (issue)

I'm not sure how to submit a feature request issue. I'd like to request the following change to the LilyPond parser: One feature that would be useful is for the LilyPond parser to output the following version numbers: The LilyPond version, e.g. 2.24.1; The source file "

Re: Need help using math in markup command definition, and a feature request.

Le mardi 09 mai 2023 à 08:14 +, Werner LEMBERG a écrit : > Yes, evaluated, sorry. It is evaluated when baz is executed. ``` (define (foo bar) (define (baz) (if bar "yes" "no")) (set! bar #t) (baz)) (foo #f) ⇒ "yes" ``` signature.asc Description: This is a digitally signed mess

Re: Need help using math in markup command definition, and a feature request.

>> >> D'oh, this should be >> >> ``` >> (define (foo bar) >>   (define (baz) >>     ... >>     (if bar)    ; Is 'bar' visible here?  If yes, when is >>   ...   ; 'bar' expanded?  At the time 'baz' is >>     ; defined? At the time 'baz' is executed? >> ``` > > I do

Re: Need help using math in markup command definition, and a feature request.

On 5/9/23 03:22, Jean Abou Samra wrote: Le lundi 08 mai 2023 à 22:55 -0400, dfro a écrit : Jean, I think \translate-scaled will work for me! This is a wonderful tool.  In the following example, \concat allows me to get the symbols closer together. The -.2 values for x in /translate-scaled o

Re: Need help using math in markup command definition, and a feature request.

On 5/9/23 03:22, Jean Abou Samra wrote: Le lundi 08 mai 2023 à 22:55 -0400, dfro a écrit : Jean, I think \translate-scaled will work for me! This is a wonderful tool.  In the following example, \concat allows me to get the symbols closer together. The -.2 values for x in /translate-scaled o

Re: Need help using math in markup command definition, and a feature request.

Le lundi 08 mai 2023 à 22:55 -0400, dfro a écrit : > > Jean, > > I think \translate-scaled will work for me! This is a wonderful tool.  In the > following example, \concat allows me to get the symbols closer together. The > -.2 values for x in /translate-scaled on the third \markup example d

Re: Need help using math in markup command definition, and a feature request.

Le mardi 09 mai 2023 à 04:26 +, Werner LEMBERG a écrit : > > D'oh, this should be > > ``` > (define (foo bar) >   (define (baz) >     ... >     (if bar)    ; Is 'bar' visible here?  If yes, when is >   ...   ; 'bar' expanded?  At the time 'baz' is >     ; defin

Re: Need help using math in markup command definition, and a feature request.

> BTW, I suggest to cover one more issue with local variables, namely > whether arguments to a function are seen in sub-functions, which are > IMHO a very good addition to `let` and `let*` to write clean and > readable code – often much more readable than anonymous lambda > expressions. > > Examp

Re: Need help using math in markup command definition, and a feature request.

> Second, you need to use `let` here, not `define`. See > > https://extending-lilypond.gitlab.io/en/scheme/local-variables.html BTW, I suggest to cover one more issue with local variables, namely whether arguments to a function are seen in sub-functions, which are IMHO a very good addition to `l

Re: Need help using math in markup command definition, and a feature request.

On 5/8/23 21:06, Jean Abou Samra wrote: Le lundi 08 mai 2023 à 20:55 -0400, dfro a écrit : Fellow music engravers, I have a feature request. Perhaps, this has been discussed already. Sometimes, I would like the spacial formatting in a \markup command to respond to changes in fontsize, so

Re: Need help using math in markup command definition, and a feature request.

Le lundi 08 mai 2023 à 20:55 -0400, dfro a écrit : > Fellow music engravers, > > I have a feature request. Perhaps, this has been discussed already. > > Sometimes, I would like the spacial formatting in a \markup command to > respond to changes in fontsize, so that all of t

Need help using math in markup command definition, and a feature request.

Fellow music engravers, I have a feature request. Perhaps, this has been discussed already. Sometimes, I would like the spacial formatting in a \markup command to respond to changes in fontsize, so that all of the \markup spacing will change proportional to the change in fontsize. I think

Re: Feature request: Fix cascading error messages

>> This sounds sensible; maybe this suppression of processing `\score` >> blocks can be implemented in Scheme so that LilyPond with a special >> command line option acts as a syntax checker. > > Have you actually tried? Apart from scores placed in explicit books > and bookparts, LilyPond alread

Re: Feature request: Fix cascading error messages

Le 29/03/2022 à 09:31, Werner LEMBERG a écrit : In this context I could imagine a paramater that kind of highlights the first few error messages (or only shows the first N error messages) being very forthcoming to some people without a dev background. Or maybe at the end of the compilation output

Re: Feature request: Fix cascading error messages

> > This sounds sensible; maybe this suppression of processing `\score` > > blocks can be implemented in Scheme so that LilyPond with a special > > command line option acts as a syntax checker. > That would be an improvement. It's still however not what the OP's

Re: Feature request: Fix cascading error messages

Ah, mea culpa. www.martinrinconbotero.com > > On Mar 29, 2022 at 12:58 PM, mailto:d...@gnu.org)> wrote: > > > > Martín Rincón Boterowrites: > >> Since > TeX is predominantly employed for compiling LaTeX sources, that >> speaks > more

Re: Feature request: Fix cascading error messages

Martín Rincón Botero writes: > >> Since TeX is predominantly employed for compiling LaTeX sources, that >> speaks more about the LaTeX implementation than TeX itself. > > Because I'm under the impression that Lilypond is more similar to > LaTeX than to TeX, It totally isn't, neither in

Re: Feature request: Fix cascading error messages

Werner LEMBERG writes: >> Why make the user wait so long to make him fix a misspelled word or >> make him put a curly brace? A first pass should be done without >> \score blocks and abort (or at least ask if you want to continue!) >> if this first pass produces errors. > > This sounds sensible; m

Re: Feature request: Fix cascading error messages

> > > Since TeX is predominantly employed for compiling LaTeX sources, that > > > > speaks more about the LaTeX implementation than TeX itself. > > > Because I'm under the impression that Lilypond is more similar to L

Re: Feature request: Fix cascading error messages

> Why make the user wait so long to make him fix a misspelled word or > make him put a curly brace? A first pass should be done without > \score blocks and abort (or at least ask if you want to continue!) > if this first pass produces errors. This sounds sensible; maybe this suppression of proce

Re: Feature request: Fix cascading error messages

Martín Rincón Botero writes: > I'm lucky to be able to work using Lilypond through Python. I never > compile the whole score I'm working on, but only the current "segment" > (around 2 pages) and the corresponding pages get updated in the > PDF. Compiling the whole thing is something I do only at

Re: Feature request: Fix cascading error messages

*I'll implement it. On mar. 29 2022, at 12:06 pm, Martín Rincón Botero wrote: > > Sometimes I want to see the output inspite of errors. Aborting > > immediately if there is a syntax problem is definitely not always the > > best solution. I fully agree with other people that it should be > > Fres

Re: Feature request: Fix cascading error messages

> Sometimes I want to see the output inspite of errors. Aborting > immediately if there is a syntax problem is definitely not always the > best solution. I fully agree with other people that it should be > Frescobaldi's job to jump to the first error message (in case it > doesn't do this already).

Re: Feature request: Fix cascading error messages

> But shouldn't Lilypond check first if the syntax is correct instead > of spending several seconds/minutes compiling a code that's doomed > to visually fail? Sometimes I want to see the output inspite of errors. Aborting immediately if there is a syntax problem is definitely not always the bes

Re: Feature request: Fix cascading error messages

> I strongly disagree :-) > When there is an error, the default should be to continue as long as > possible. For large projects where the compilation takes time, you want > to have some viewable output even if there is a glitch somewhere. I also > think you are overestimating the "developing effort

Re: Feature request: Fix cascading error messages

> In this context I could imagine a paramater that kind of highlights > the first few error messages (or only shows the first N error > messages) being very forthcoming to some people without a dev > background. Or maybe at the end of the compilation output a clearly > marked: "First (few?) Error(

Re: Feature request: Fix cascading error messages

I think most developers are used to having a full error log - which is definitely the right default behaviour for lilypond. On the other hand I can fully understand that especially for users that aren't used to software development a full error log can be quite a mess to the (untrained) eye. In th

Re: Feature request: Fix cascading error messages

Le 29/03/2022 à 08:46, Martín Rincón Botero a écrit : +1. I think making it customizable (with a --cascade-level parameter) wouldn't add much value considering developing effort, though. Lilypond, like Python f. ex., should simply report the first error (and ideally immediately abort compilatio

Re: Feature request: Fix cascading error messages

+1. I think making it customizable (with a --cascade-level parameter) wouldn't add much value considering developing effort, though. Lilypond, like Python f. ex., should simply report the first error (and ideally immediately abort compilation). —Martín. www.marti

Re: Feature request: Fix cascading error messages

On Mon, Mar 28, 2022 at 4:58 PM David Kastrup wrote: > > Christopher Heckman writes: > > > I have a request concerning Lilypond that has bothered me for a while, > > but which I haven't seen any one else complain about. It is the > > cascade of error messages you get when you leave out a right-br

Re: Feature request: Fix cascading error messages

Christopher Heckman writes: > I have a request concerning Lilypond that has bothered me for a while, > but which I haven't seen any one else complain about. It is the > cascade of error messages you get when you leave out a right-brace or > some other symbol. > > Maybe this could be added as an o

Re: Feature request: Fix cascading error messages

+1 From: lilypond-user on behalf of Christopher Heckman Date: Monday, March 28, 2022 at 7:11 PM To: lilypond-user@gnu.org Subject: Feature request: Fix cascading error messages I have a request concerning Lilypond that has bothered me for a while, but which I haven't seen any one

Feature request: Fix cascading error messages

I have a request concerning Lilypond that has bothered me for a while, but which I haven't seen any one else complain about. It is the cascade of error messages you get when you leave out a right-brace or some other symbol. Maybe this could be added as an option to lilypond? lilypond --cascade-le

Re: Feature request: Alternative G clef

Hi Jean, thank you for that font showcase! I’ll take a closer look at Profondo. However, its overly long bass clef looks quite unappealing to me. I wouldn’t use any of the others, as far as I can tell. About what pairs with what is certainly more of a matter of taste. I find Emmentaler’s trill

Re: Feature request: Alternative G clef

Le 24/10/2020 à 11:47, Martín Rincón Botero a écrit : Hello all, a few months ago in some forum I found the following snippet of a beautiful G clef (I think by Pierre Perol-Schneider) that I've been extensively using since then. Right now in the NR we have \clef G, \clef treble, \clef "G2" a

Re: Feature request: Alternative G clef

Thank you Simon for your answer. As much as I applaud the efforts for making Lilypond work with other fonts, I find it a pity that more glyphs can’t be included in the core. It’s not rare to find alternative or “extra” glyphs in other fonts either (Maestro, Opus, etc.), so this wouldn’t be the f

Re: Feature request: Alternative G clef

Hi Martín, On 24.10.20 11:47, Martín Rincón Botero wrote: I wish Perol-Schneider's clef could be considered for inclusion into standard Lilypond, possibly named as "G2" (which would actually produce a "second" G clef) or as \clef varG. two things here: there has been a lot of work to making

Feature request: Alternative G clef

Hello all, a few months ago in some forum I found the following snippet of a beautiful G clef (I think by Pierre Perol-Schneider) that I've been extensively using since then. Right now in the NR we have \clef G, \clef treble, \clef "G2" and \clef violin, all producing what seems to be the exact sa

Possible Feature Request?

Right now we have ly:source-files which contains a list of all input files which have been opened up to the point of it’s call, but there is, so far as I can tell, no equivalent for output files. How difficult would it be to add such a scheme function/list? As I see it, LilyPond obviously know

Re: An unusual feature request concerning FiguredBass

Hi Kieren, Your version did help me enormously. Thank you very much. The whole score is now what it should be. I usually work with separate voices to be collected in the score, but with the extra BC-line I could not get it right. I spent most of this day wondering what the hell the error messa

Re: An unusual feature request concerning FiguredBass

Hi Robert, > Whatever I tried, it stubbornly kept "bass" for both staves. What am I doing > wrong? There’s a spurious instrument name setting. But given the structure of your code, it’s very hard to spot. Might I suggest putting all of your note code into variables, then building them togethe

Re: An unusual feature request concerning FiguredBass

Hello, I have finally managed to apply your recommendations in my score. On the whole they work out very well except for one error that I have not been able to get rid of: to change the staff name of the upper staff in "cantus". Whatever I tried, it stubbornly kept "bass" for both staves. What

Re: An unusual feature request concerning FiguredBass

Good morning, Many thanks for your quick reactions and helpful advice. Because it will take me a while to try these solutions in my score, and because at this moment I am in rural France where my internet connection is very buggy and unstable --- in a few minutes I may be disconnected till lat

Re: An unusual feature request concerning FiguredBass

On 4/28/2018 4:33 PM, Torsten Hämmerle wrote: Ahem, If you want to get rid of the "connecting line", it might helpful to know that this line is called SystemStartBar and it lives in the Score context. So, \omit Score.SystemStartBar will make it disappear without SVG manipulation. HTH, Torsten

Re: An unusual feature request concerning FiguredBass

Ahem, If you want to get rid of the "connecting line", it might helpful to know that this line is called SystemStartBar and it lives in the Score context. So, \omit Score.SystemStartBar will make it disappear without SVG manipulation. HTH, Torsten -- Sent from: http://lilypond.1069038.n5.na

Re: An unusual feature request concerning FiguredBass

On 4/28/2018 1:08 PM, Noeck wrote: Dear Robert, I don't know this notation. So my advice is probably not the best solution. Entering FiguredBass1 and FiguredBass2 did not give me anything but error messages You mean \new FiguredBass1 ? You cannot just invent context names. But you can stack s

Re: An unusual feature request concerning FiguredBass

Robert, it's easier to help you if you provide a Minimal Working Example, otherwise it's hard to know what exactly you tried. Anyway: It's not problem at all to create multiple FiguredBass-environments. The line between them is a bit more tricky; I once used a rhythm staff with all bar lines

Re: An unusual feature request concerning FiguredBass

Dear Robert, I don't know this notation. So my advice is probably not the best solution. > Entering FiguredBass1 and FiguredBass2 did not give me anything but > error messages You mean \new FiguredBass1 ? You cannot just invent context names. But you can stack several contexts of the same type.

An unusual feature request concerning FiguredBass

Dear all, I am asked to add to psalm-setting two different figured bass lines, separated by a line and with, at the beginning of the first bar, the words "Pretonal" and "Tonal", as can be seen in the screenshot: Entering FiguredBass1 and FiguredBass2 did not give me anything but error messag

Re: feature request: stem length should scale for scaled/cue notes

Hi Harm, > in CueVoice stem length _is_ shortened. Well, that’s a relief! =) > But it in your example it has no effect, because 'no-stem-extend is #f Hmmm… Should that be the default? > Try it with Works great. Thanks! > For reduced sizes in a common Voice we nowadays have `magnifyMusic', >

Re: feature request: stem length should scale for scaled/cue notes

2016-02-07 17:11 GMT+01:00 Kieren MacMillan : > Hello all, > > I searched the issue tracker and LSR, but couldn’t find anything related to > this. > (Apologies if I missed it.) > > Please consider the output of following snippet: > > %%% BEGIN SNIPPET > \version "2.19.35" > > cees = { c'8 8 8 8 }

feature request: stem length should scale for scaled/cue notes

Hello all, I searched the issue tracker and LSR, but couldn’t find anything related to this. (Apologies if I missed it.) Please consider the output of following snippet: %%% BEGIN SNIPPET \version "2.19.35" cees = { c'8 8 8 8 } tinyteeny = { \time 2/4 \cees \tiny \cees \teeny \cees

Re: feature request: abs-fontsize available for all text grobs

Dear Kieren, sorry for the delay. I am organising school - holiday for my kids I think, mainly I have been distracted from preparing a patch. I feel a little bit like a minister of finance seeing debts grow ;-) So this mail serves pushing it on the agenda again. Regards, Jan-Peter Am 1. Feb

Re: feature request: abs-fontsize available for all text grobs

Dear David and Jan-Peter, It appears that the absFontSize feature I sponsored a few years ago — and employ in absolutely [ha!] every score I engrave — has not been rolled into the main Lilypond codebase. Is that true? If so, what is stopping it from being added? I think users could benefit fro

Re: Feature request for Nalesnik's rN.ly

> I've moved all development of this to a GitHub repository here: https://github.com/davidnalesnik/lilypond-roman-numeral-tool. There are significant improvements over what you'll find in the archives. Ability to do altered figures is one of the things I've added. It's exactly what I need! Thank y

Re: Feature request for Nalesnik's rN.ly

On Wed, Dec 9, 2015 at 6:21 PM, David Nalesnik wrote: > > > I've moved all development of this to a GitHub repository here: > https://github.com/davidnalesnik/lilypond-roman-numeral-tool. There are > significant improvements over what you'll find in the archives. Ability to > do altered figures i

Re: Feature request for Nalesnik's rN.ly

Hi Ferdinand, On Wed, Dec 9, 2015 at 5:23 PM, Ferdinand Grau wrote: > The problem is that I severely lack the ability to typest chords like the > ones in the attachment: II6/5/♭, II7/♭5, etc. Interestingly enough, > arbitrary number of inversion digits was supported by earlier version of > \rN (

Feature request for Nalesnik's rN.ly

The problem is that I severely lack the ability to typest chords like the ones in the attachment: II6/5/♭, II7/♭5, etc. Interestingly enough, arbitrary number of inversion digits was supported by earlier version of \rN (https://lists.gnu.org/archive/html/lilypond-user/2014-11/msg00470.html). but it

Re: [feature-request] optional duration for temporary

Hi James, > I have opened > https://sourceforge.net/p/testlilyissues/issues/4658/ Thanks. (I’m getting a 404 error at the moment, but I assume that’s temporary.) Cheers, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenm

Re: [feature-request] optional duration for temporary

On 11/11/15 02:58, Kieren MacMillan wrote: > Hello all, > > Rather than having to \revert an \override (or set of \override-s), might it > be possible to set an optional duration for which the override would be in > effect? e.g. > > \temporary #’(10 1/8) \override LyricText.extra-offset = #’(0

Re: [feature-request] optional duration for temporary

On 11.11.2015 14:08, Johan Vromans wrote: On Wed, 11 Nov 2015 13:42:58 +0100 David Kastrup wrote: But if you have to close the group anyway with a brace, where is the point in not just doing a music function doing { \temporary $xxx ... \undo $xxx } I do not see how to cope with the $xxx. Cou

Re: [feature-request] optional duration for temporary

Hi Kieren, et.al., David came up with a nice solution :) To get such a function with the edition-engraver, we will have to integrate some other piece. The proposed solution works horizontal in time, while the edition-engraver is triggered "vertically" in time. So there has to be an event, whic

Re: [feature-request] optional duration for temporary

Hi David, As always, a wonderful solution. Thank you! %%% SNIPPET BEGINS \version "2.19.30" ranged = #(define-music-function (overrides music) (ly:music? ly:music?) #{ \temporary $overrides #music \undo $overrides #}) { c d e f \ranged \override NoteHead.color = #red { c d e f } c d e

Re: [feature-request] optional duration for temporary

Kieren MacMillan writes: > Hi David, > >> But if you have to close the group anyway with a brace, where is the >> point in not just doing a music function doing >> >> { \temporary $xxx ... \undo $xxx } > > Wouldn’t one have to create a separate music function for each possible tweak? > If not, t

Re: [feature-request] optional duration for temporary

On Wed, 11 Nov 2015 13:42:58 +0100 David Kastrup wrote: > But if you have to close the group anyway with a brace, where is the > point in not just doing a music function doing > > { \temporary $xxx ... \undo $xxx } I do not see how to cope with the $xxx. Could you give an example imlememtation

Re: [feature-request] optional duration for temporary

Hi David, > But if you have to close the group anyway with a brace, where is the > point in not just doing a music function doing > > { \temporary $xxx ... \undo $xxx } Wouldn’t one have to create a separate music function for each possible tweak? If not, then there is, as you say, no point. Th

Re: [feature-request] optional duration for temporary

Kieren MacMillan writes: > Hi Johan, > >> I'd hate the counting of measures… > > Me, too… but…? > >> { \local LyricText.extra-offset = #’(0 . -1) … } > > Ah! Even better. That looks like \new Lyrics \with { \override LyricText.extra-offset = #'(0 . -1) } { ... } with the main Lyrics packed in

Re: [feature-request] optional duration for temporary

Hi Johan, > I'd hate the counting of measures… Me, too… but…? > { \local LyricText.extra-offset = #’(0 . -1) … } Ah! Even better. Thanks, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info _

Re: [feature-request] optional duration for temporary

On Tue, 10 Nov 2015 21:58:10 -0500 Kieren MacMillan wrote: > Rather than having to \revert an \override (or set of \override-s), might > it be possible to set an optional duration for which the override would > be in effect? e.g. > > \temporary #’(10 1/8) \override > > would lower the Lyric

[feature-request] optional duration for temporary

Hello all, Rather than having to \revert an \override (or set of \override-s), might it be possible to set an optional duration for which the override would be in effect? e.g. \temporary #’(10 1/8) \override LyricText.extra-offset = #’(0 . -1) would lower the LyricText(s) for exactly 10 meas

Re: [feature request:] fret diagrams with fingering indications and additional text

2015-11-08 16:15 GMT+01:00 BB : > I just tried your code but get a different PDF result? See attachement. > I get a warning in German: > > Warnung: staff-affinities sollten nur abnehmen > > Might mean something like > staff-affinities should always decrease > Did you use my test-file or other cod

Re: [feature request:] fret diagrams with fingering indications and additional text

2015-11-08 14:52 GMT+01:00 pls : > Thomas Morley writes: > >> 2015-11-08 12:23 GMT+01:00 pls : > >>> Hi Harm, >>> >>> I finally managed to test your code and I really, really like it! I >>> especially like the option to >>> turn the annotations on and off. >> >> Glad you like it. >> >> Ofcourse i

Re: [feature request:] fret diagrams with fingering indications and additional text

I just tried your code but get a different PDF result? See attachement. I get a warning in German: Warnung: staff-affinities sollten nur abnehmen Might mean something like staff-affinities should always decrease On 08.11.2015 12:23, pls wrote: Thomas Morley writes: Hi Patrick, I did some e

Re: [feature request:] fret diagrams with fingering indications and additional text

Thomas Morley writes: > 2015-11-08 12:23 GMT+01:00 pls : >> Hi Harm, >> >> I finally managed to test your code and I really, really like it! I >> especially like the option to >> turn the annotations on and off. > > Glad you like it. > > Ofcourse it's not in the source atm. > And there's the (l

Re: [feature request:] fret diagrams with fingering indications and additional text

2015-11-08 12:23 GMT+01:00 pls : > Thomas Morley writes: > >> Hi Patrick, >> >> I did some experiments, result attached. >> >> Please test. There is a README in it. >> >> Please be aware it's experimental code, not ready yet to put up a >> patch, although it compiles as far as I tested... >> (some

Re: [feature request:] fret diagrams with fingering indications and additional text

Thomas Morley writes: > Hi Patrick, > > I did some experiments, result attached. > > Please test. There is a README in it. > > Please be aware it's experimental code, not ready yet to put up a > patch, although it compiles as far as I tested... > (some debugging code is still present, most of it

Re: [feature request:] fret diagrams with fingering indications and additional text

Thomas Morley writes: > 2015-11-01 19:55 GMT+01:00 pls : >> Hey all, >> >> currently it's possible to add fingering indications (any character) inside >> of dots or "below" the strings. (In my attachment in landscape orientation >> it's rather to the right of the strings). Now I would like to b

Re: [feature request] getting \repeat percent to work in ChordNames

> I'm not sure if I was inspired by http://lsr.di.unimi.it/LSR/Item?id=460 >> or >> if I found the solution somewhere else. Probably someone was faster than >> me. >> >> Cheers, >> Klaus >> >> >> >> -- >> View this message i

Re: [feature request] getting \repeat percent to work in ChordNames

bble.com/file/n174400/Chord_sheet.ly> > I'm not sure if I was inspired by http://lsr.di.unimi.it/LSR/Item?id=460 > or > if I found the solution somewhere else. Probably someone was faster than > me. > > Cheers, > Klaus > > > > -- > View this message in

Re: [feature request] getting \repeat percent to work in ChordNames

ewhere else. Probably someone was faster than me. Cheers, Klaus -- View this message in context: http://lilypond.1069038.n5.nabble.com/feature-request-getting-repeat-percent-to-work-in-ChordNames-tp174393p174400.html Sent from the User mailing list archive at

Re: [feature request] getting \repeat percent to work in ChordNames

Hi Klaus, > you could also try Yes! Perfect. Embarassed that I didn’t think of it myself. Thanks, Kieren. ___ Kieren MacMillan, composer www: email: i...@kierenmacmillan.info ___ lilypond-user

Re: [feature request] getting \repeat percent to work in ChordNames

Hi Pierre, > http://lsr.di.unimi.it/LSR/Item?id=908 Thanks! That’ll do for now. Best, Kieren. ___ Kieren MacMillan, composer www: email: i...@kierenmacmillan.info ___ lilypond-user mailing list

Re: [feature request] getting \repeat percent to work in ChordNames

-- Cheers, Klaus -- View this message in context: http://lilypond.1069038.n5.nabble.com/feature-request-getting-repeat-percent-to-work-in-ChordNames-tp174393p174395.html Sent from the User mailing list archive at Nabble.com. __

Re: [feature request] getting \repeat percent to work in ChordNames

http://lsr.di.unimi.it/LSR/Item?id=908 2015-04-11 22:16 GMT+02:00 Kieren MacMillan : > Hi all, > > How can I get \repeat percent {} to print a percent sign in ChordNames? > > Thanks, > Kieren. > ___ > > Kieren MacMillan, composer > www: > ema

[feature request] getting \repeat percent to work in ChordNames

Hi all, How can I get \repeat percent {} to print a percent sign in ChordNames? Thanks, Kieren. ___ Kieren MacMillan, composer www: email: i...@kierenmacmillan.info ___ lilypond-user mailing lis

Re: the "perfect" break-engraver (was Re: [Feature Request] \compressFullBarRests improvement(s))

Hi Jay, > Some minor changes would be needed if a break is needed > mid-measure (something like \lineBreakAt 27 3/4). Yes. As I understand it, some less minor changes would be needed for that, too: currently (AFAIK), Lily won’t break mid-measure without an explicit \bar “”. > I think I'd still

Re: the "perfect" break-engraver (was Re: [Feature Request] \compressFullBarRests improvement(s))

On Fri, Dec 27, 2013 at 4:08 PM, Kieren MacMillan wrote: > I think the “perfect” break-engraver would admit coding like the following > (pseudocode; all numbers in measures): > > \lineBreakAt 27 > \lineBreaksAt (12 28 34 48) > \noLineBreaks (27-30) > \lineBreaksForbidAt 28 > \

the "perfect" break-engraver (was Re: [Feature Request] \compressFullBarRests improvement(s))

Further to this thread… > I just think it — or something like it — should be vetted and [the > improved/approved version] included with the regular distro. I think the “perfect” break-engraver would admit coding like the following (pseudocode; all numbers in measures): \lineBreakAt 27

Re: [Feature Request] \compressFullBarRests improvement(s)

Hi David, > A content-independent line- and page-breaking system is easy. > The content is what makes it complicated… Ah, the semantics cop is on the beat. ;) Let me put it another way: Using David’s engraver (which he graciously sent me off-list), I am happily adding manual breaks EXTERNAL TO

Re: [Feature Request] \compressFullBarRests improvement(s)

Kieren MacMillan writes: > Hi all, > >> How would it behave if \draftSkip were, instead of being changed, > tagged, and you ran lilypond with exclude-tag #draft? (I can't > remember the syntax off the top of my head, but I think that's > reasonably close.) > > It would be fine… but it’s still a b

Re: [Feature Request] \compressFullBarRests improvement(s)

Hi all, > How would it behave if \draftSkip were, instead of being changed, tagged, and > you ran lilypond with exclude-tag #draft? (I can't remember the syntax off > the top of my head, but I think that's reasonably close.) It would be fine… but it’s still a band-aid (um, Band-Aid™) solution.

Re: [Feature Request] \compressFullBarRests improvement(s)

How would it behave if \draftSkip were, instead of being changed, tagged, and you ran lilypond with exclude-tag #draft? (I can't remember the syntax off the top of my head, but I think that's reasonably close.) On Dec 27, 2013, at 1:38 AM, "Keith OHara" wrote: > On Thu, 26 Dec 2013 18:44:56

Re: [Feature Request] \compressFullBarRests improvement(s)

On Thu, 26 Dec 2013 18:44:56 -0800, Kieren MacMillan wrote: I look forward to stress-testing this in the very near future. One missing feature is that \mergeSkips doesn't look inside {...} to see if they are empty. I often set breaks for proofreading and then remove them by defining them

  1   2   3   4   5   >