Re: Pedal cautionary after a line break (current status and improvements)

On Tue, Jun 23, 2020 at 10:32 PM Kieren MacMillan < kieren_macmil...@sympatico.ca> wrote: > Hi Paolo, > > > I don't understand what you mean exactly, in the choral pieces. > > A cappella choral pieces don’t include piano music, and therefore don’t > include any piano pedal markings, and therefore

Re: Pedal cautionary after a line break (current status and improvements)

On Tue, Jun 23, 2020 at 10:13 PM Kieren MacMillan < kieren_macmil...@sympatico.ca> wrote: > Hi Paolo, > > > This issue is not *important for me*. It is an *essential* feature for > any score. > > At best, one could argue that it‘s "an essential feature" for any score > with multiple pedal

Re: Pedal cautionary after a line break (current status and improvements)

On Tue, Jun 23, 2020 at 9:53 PM Jean Abou Samra wrote: > Paolo, > > > I really think Carl did not intend to be harsh. He even explicitely tried > to > avoid making you taking it as an offence: > > > I'm trying not to be mean in this answer, but to explain the way > > LilyPond development works.

Re: Pedal cautionary after a line break (current status and improvements)

On Tue, Jun 23, 2020 at 9:32 PM Jean Abou Samra wrote: > Hi Paolo, > > Le 23/06/2020 à 21:09, Carl Sorensen a écrit : > > Paolo, > > > > On Tue, Jun 23, 2020 at 12:33 PM Paolo Prete > wrote: > >> 2) Considering that a Pedal cautionary is *essential*

Re: Pedal cautionary after a line break (current status and improvements)

On Tue, Jun 23, 2020 at 9:09 PM Carl Sorensen wrote: > Paolo, > > On Tue, Jun 23, 2020 at 12:33 PM Paolo Prete wrote: > > > > > > > 2) Considering that a Pedal cautionary is *essential* in *every* serious > > score, I really encourage the developers to fix t

Re: Pedal cautionary after a line break (current status and improvements)

On Tue, Jun 23, 2020 at 6:36 PM Pierre Perol-Schneider < pierre.schneider.pa...@gmail.com> wrote: > Hi Paolo, > See: http://lsr.di.unimi.it/LSR/Item?id=1023 > Cheers, > PIerre > > Hi Pierre, I already saw your workaround but, as said in the previous email, it has unwanted side effects. The

Re: Pedal cautionary after a line break (current status and improvements)

On Tue, Jun 23, 2020 at 3:47 PM Kieren MacMillan < kieren_macmil...@sympatico.ca> wrote: > Hi Paolo, > > > It is very important, IMHO, to have a sustain pedal cautionary after a > line break. > > Did you look at the LSR? > > > Does that not do what you

Re: Fine tuning of MetronomeMark's expression

On Fri, Jun 19, 2020 at 10:44 PM Valentin Villenave wrote: > On 6/19/20, Paolo Prete wrote: > > Is there a way, for the above metronome indication " (quarter = 120) " > of > > the above MetronomeMark to apply the same font parameters (\abs-fontsize, > > \b

Fine tuning of MetronomeMark's expression

Hello, Given: \tempo \markup {\abs-fontsize #16 \bold "Allegro" } 4 = 120 c' Is there a way, for the above metronome indication " (quarter = 120) " of the above MetronomeMark to apply the same font parameters (\abs-fontsize, \bold etc.) specified in the \markup expression? Thanks! P

Overriding outside-staff-padding of a PianoPedalBracket

Hello, Is it possible to \override the outside-staff-padding property of a PianoPedalBracket, in some way? Of course it is doable on a Sustain/Sostenuto/UnaCorda-PedalLineSpanner, but this causes to have the result only for the horizontal line of the bracket, and not for the __/\__

Vertical gap between two pedals (again)

Hello, I'm still fighting against the problem of setting a vertical gap between two pedal spanners. Or, in general, between two spanners. I find *very* strange there's not such a feature in Lilypond, which is IMHO very important and it currently can be implemented only (in a uncomfortable way)

Pedal cautionary after a line break (current status and improvements)

Hello, It is very important, IMHO, to have a sustain pedal cautionary after a line break. Otherwise, when we use two simultaneous pedal brackets the music becomes absolutely unreadable. Looking at this thread:

Re: Vertical gap between two simultaneous pedals

On Sun, Jun 14, 2020 at 5:36 PM Paolo Prete wrote: > > > Hi Kieren and all, > > I elaborated this solution, meanwhile, which works well but needs to be > improved in the scheme part. > Then I firstly ask to all the gurus how could I arrange the \sustainOnII > and \so

Re: Vertical gap between two simultaneous pedals

On Sun, Jun 14, 2020 at 3:15 PM Kieren MacMillan < kieren_macmil...@sympatico.ca> wrote: > Hi all, > > > However, I would like to avoid the Dynamics layer, because it introduces > redundancy. > > Is there a way to achieve the same result without that layer? > > If you want to really make Lilypond

Re: Vertical gap between two simultaneous pedals

On Sun, Jun 14, 2020 at 9:49 AM Pierre Perol-Schneider < pierre.schneider.pa...@gmail.com> wrote: > Hi Paolo, > How about: > > \score { > << > \new Staff { > c'4 c' c' c' > r1 \break > c'4 c' c' c' > r1 > } > \new Dynamics > \with { \override

Vertical gap between two simultaneous pedals

Hello, Is there a way to set a *minimum* vertical gap between two simultaneous pedals (Sostenuto and Sustain)? It has to work regardless of the vertical order of the pedals (sustain above sostenuto or viceversa) and we can assume that: 1) no other grob is placed between them. 2) no other grob

Re: Filtering chunks of the score so to speed up the compiling time

On Sat, Jun 13, 2020 at 8:39 PM Kieren MacMillan < kieren_macmil...@sympatico.ca> wrote: > Hi Paolo, > > > In order to speed up the compiling time, I wonder if Lilypond has a > preprocessor that can filter all the parts of the score which aren't marked > by a specific tag. > > Have you looked

Filtering chunks of the score so to speed up the compiling time

Hello, In order to speed up the compiling time, I wonder if Lilypond has a preprocessor that can filter all the parts of the score which aren't marked by a specific tag. So, for example, the following code could be compiled only for the chunks included between \START and \END tags:

Re: Making Lilypond faster

> Hi Paolo, > > today I tried to compile LilyPond with guile-3. > > > > Guile-3 was compiled from their repo with: > > sh autogen.sh > ./configure > make > sudo make install > > giving me "3.0.2.124-e7398") > > > > For compiling LilyPond I used: > > sh autogen.sh --noconfigure > mkdir -p

Re: How to modify the gap between the clef or time signature and the first note/chord/pause/skip in the bar

entation/internals/timesignature > Cheers, > Pierre > > Le sam. 13 juin 2020 à 01:01, Paolo Prete a écrit : > >> Hello, >> >> How can I modify the horizontal gap between the clef or time signature >> and the first note/chord/pause/skip in the bar? >> >> Thanks! >> >

How to modify the gap between the clef or time signature and the first note/chord/pause/skip in the bar

Hello, How can I modify the horizontal gap between the clef or time signature and the first note/chord/pause/skip in the bar? Thanks!

Re: How to pass a fraction as a parameter for a Scheme function

On Fri, Jun 12, 2020 at 1:15 PM Aaron Hill wrote: > . If all that was needed was > to specify a duration, then it might not matter since four quarters is > the same as two halves. However then, David's suggestion of using > ly:duration? would make much more sense. > > > I agree, but my last

Re: Text above a vertically shifted MultiMeasureRest

On Thu, Jun 11, 2020 at 7:03 PM Thomas Morley wrote: > > > { > \override MultiMeasureRest.Y-offset = #-5 > %% probably apply padding or Y-offset > %\override MultiMeasureRestText.padding = 2 > \override MultiMeasureRestText.staff-padding = #'() > \override

Text above a vertically shifted MultiMeasureRest

Hello, How can I put a text above a MultiMeasureRest, and not above the staff? This would be useful for cross-staff MultiMeasureRests; for them I normally use the Y-offset property in order to shift them down, as shown in the below code: { \override MultiMeasureRest.Y-offset = #-5 \time 2/4

Collision on tremolo

Hello, as you can see in Lilybin's output, the below expression produces a collision: { \repeat tremolo 8 { aes'16 bes' } } http://lilybin.com/tmdugu/1 What's wrong and how can I fix it? Thanks!

Re: How to pass a fraction as a parameter for a Scheme function

> Alternately, you can use the rational? type predicate so the value is > numeric. However, you will then need to use Scheme syntax for the > input: #1/16 instead of 1/16. > > Thank you and thanks to David. When I looked at the list of predicates...;

How to pass a fraction as a parameter for a Scheme function

Hello, I don't understand how to use a fraction as a parameter for a scheme function. More specifically, this gives me an error: proportionalNotationDur = #(define-music-function (parser location frac) (scheme?) #{ \set Score.proportionalNotationDuration =

Increase/decrease space after barline or after time signature

Hello, how can I increase/decrease the horizontal gap between 1) the time signature and the first note of the bar 2) the barline and the first note of the bar ...? Thanks!

Re: Hidden dynamic that can be heard on midi ouput

> > > > > Use an event function, or add a direction indicator. The explanation is > here > https://lilypond.org/doc/v2.20/Documentation/extending/event-functions > > -- > Thanks!

Re: Hidden dynamic that can be heard on midi ouput

On Mon, Jun 8, 2020 at 6:33 PM Paolo Prete wrote: > Hello, > > it can be useful to create dynamics that can be heard only in the midi > output. Then I used the below procedure. However, if I try to make a > function with the same command, there's a syntax error. How can I f

Hidden dynamic that can be heard on midi ouput

Hello, it can be useful to create dynamics that can be heard only in the midi output. Then I used the below procedure. However, if I try to make a function with the same command, there's a syntax error. How can I fix it? Thanks! %% midiDynamic = #(define-music-function (parser

Re: Breath with fermata

On Sun, Jun 7, 2020 at 9:01 PM Pierre Perol-Schneider < pierre.schneider.pa...@gmail.com> wrote: > Hi Paolo, > How about: > > breatheWithFermata = #(define-music-function (parser location offs) > (number?) > #{ > \override BreathingSign.Y-offset = $offs > \override BreathingSign.text =

Breath with fermata

Hello, I'm trying to create a breath with a fermata (quite common in contemporary music). Here is what I tried: % breatheWithFermata = #(define-music-function (parser location offs) (number?) #{ \override BreathingSign.Y-offset = $offs \override BreathingSign.text = \markup {

Re: Hairpin which ends at the beginning of a measure

On Sun, Jun 7, 2020 at 4:16 PM Martin Neubauer wrote: > > Try: > \override Hairpin.to-barline = ##f > > > Thank you, it solved all

Hairpin which ends at the beginning of a measure

Hello, As you can see in the following example, a hairpin is not connected to its final dynamic if this dynamic is at the beginning of a measure, but it stops at the end ot the previous measure: { c'\pp\< c' c' c' c'\f r2. \break r1 } I'm not sure that this default is the proper one in common

Re: Changing the text of a TimeSignature

On Fri, Jun 5, 2020 at 4:07 PM David Kastrup wrote: > Paolo Prete writes: > > > Hello, > > > > Is there a way to change displayed text in the TimeSignature's fraction, > > without changing the effective value? > > > > for example, if I have > >

Changing the text of a TimeSignature

Hello, Is there a way to change displayed text in the TimeSignature's fraction, without changing the effective value? for example, if I have { \time 3/4 c' c' c' } I would like to display "Foo / Bar" instead of "3 / 4", while preserving the inner 3/4 structure. Thanks! Best, P

Re: Making Lilypond faster

> > > Hi Paolo, > > The suggestion to focus on guile-3 makes no sense at the moment, > because it is not broadly in the distros, afaict. > > > Hello Harm, what about this?

Making Lilypond faster

Hello, after using 2.19.84 for a while, it seems to me that it is quite faster than the previous one (2.19.83). 1) Now I wonder if there are some later versions (or git snapshots) even faster: do you have any feedback about this? 2) Also: is there a way to optimize (when compiling a snapshot)

Re: Absolute font-size for TextScript

On Wed, Jun 3, 2020 at 12:01 AM Aaron Hill wrote: > > As is tradition, I am almost certainly over-engineering here. However, > would the following approach be of any use: > > > \version "2.20.0" > > transformText = > #(define-music-function >(grob-path proc) >((key-list?

Re: Absolute font-size for TextScript

On Tue, Jun 2, 2020 at 11:18 PM Kieren MacMillan < kieren_macmil...@sympatico.ca> wrote: > Hi Paolo, > > > how exactly do I have to call \absFontSize > > > \version "2.19.83" > > allowGrobCallback = > #(define-scheme-function (parser location syms) (symbol-list?) >(let ((interface (car

Re: Absolute font-size for TextScript

On Tue, Jun 2, 2020 at 8:57 PM Kieren MacMillan < kieren_macmil...@sympatico.ca> wrote: > Hi Paolo, > > > is it possible to set an absolute font-size for *all* the TextScript > objects? > > I use this (from an include file): > > > allowGrobCallback = > #(define-scheme-function (parser

Absolute font-size for TextScript

Hello, is it possible to set an absolute font-size for *all* the TextScript objects? I saw this thread: http://lilypond.1069038.n5.nabble.com/feature-request-abs-fontsize-available-for-all-text-grobs-td148053.html Which is old, and I don't understand if there is a working solution in it; nor I

Re: Error while trying to put a Text above a notehead

On Tue, Jun 2, 2020 at 4:41 PM Kieren MacMillan < kieren_macmil...@sympatico.ca> wrote: > Hi Paolo, > > > it's of course _erroneous_ output, because it leads to what in common > programming is called UB: > > It’s perfectly defined behaviour: > >

Re: Error while trying to put a Text above a notehead

On Tue, Jun 2, 2020 at 4:09 PM Kieren MacMillan < kieren_macmil...@sympatico.ca> wrote: > Hi Paolo, > > > I just verified that your previous snippet produces erroneous output > > It’s only "erroneous output" if you don’t know what it’s supposed to put > out… ;) > > Hi Kieren, In my humble

Re: Error while trying to put a Text above a notehead

On Tue, Jun 2, 2020 at 3:53 PM Robin Bannister wrote: > > > Is there an alternative for it? > > It is defaulting to another font. > To avoid this, say > text \markup \normal-text "Some text" > > > Cheers, > Robin > Thanks Robin, BTW, how can I override font-family and font-series in a

Error while trying to put a Text above a notehead

Hello David (and Lilypond people), I just verified that your previous snippet produces erroneous output on pdf and a compiler error with -dbackend=svg: (look at : http://lilybin.com/7derud/1 ) Tested on 2.19.84 and 2.19.45 (Lilybin) { \override Fingering.staff-padding = #'() \stemDown

Re: Text above a notehead or rest regardless of collisions with staff

Thanks David On Mon, Jun 1, 2020 at 11:51 PM David Kastrup wrote: > Paolo Prete writes: > > > Hello, > > > > is it possible to place "some text" above a notehead (or a rest) > regardless > > of collisions with the staff? Maybe a start could be to use

Text above a notehead or rest regardless of collisions with staff

Hello, is it possible to place "some text" above a notehead (or a rest) regardless of collisions with the staff? Maybe a start could be to use the Fingering object, but I don't know how to change "1" to "some text" { \override Fingering.staff-padding = #'() \stemDown c'-1 } Thanks! Best, P

Re: Changing the size of the arpeggio's arrow

Thank you Harm, it would be great if we can track this. Unfortunately Google seems to index only the previous version of your code. What about a repository for snippets for 2.19? best, P

Changing the size of the arpeggio's arrow

Hello. The following code uses a (very, very, very helpful) function that Harm wrote some months ago. Unfortunately, it causes a compiler's error if the size of the arrow is too big (in the following snippet the error is obtained when the size (my-scale) is >= 2). Harm (or anyone else), please

Re: Unwanted warnings/errors on pedals for multiple voices

Hi Kieren, > I was simply using your code, and eliminating the spaces to make my point. if you eliminate the spaces, then the example becomes the opposite of what it demonstrates. In order to align pedals, you don't have to look at that example, but you have to check the last one, which shows of

Re: Unwanted warnings/errors on pedals for multiple voices

On Wed, Apr 8, 2020 at 1:07 AM Mark Stephen Mrotek wrote: > Paolo, > > > > “I suspect it has been made, in the past, for an old fashioned style (not > used in professional engraving, though).” > > Looking though my Paderewski Edition of Chopin’s Piano works I find all > the pedaling indications

Re: Unwanted warnings/errors on pedals for multiple voices

On Tue, Apr 7, 2020 at 11:31 PM Aaron Hill wrote: > On 2020-04-07 1:55 pm, Paolo Prete wrote: > > Look at this example (again: messy code that could be improved, and I > > gently ask Harm and/or Aaron to have a check if they can): > > For starters, I would seek to eliminat

Re: Unwanted warnings/errors on pedals for multiple voices

On Tue, Apr 7, 2020 at 9:41 PM Kieren MacMillan wrote: > Hi Paolo, > > > I don't think so. Please have a look at this http://lilybin.com/8ufzza/1 > : > > Here’s an edited version, using your method: > > > \version "2.19.83" > > notesA = { c''4 4 4 4 } > notesB = { a4 4 4 4 } >

Re: Unwanted warnings/errors on pedals for multiple voices

On Tue, Apr 7, 2020 at 7:36 PM Noeck wrote: > Hi Paolo, > > well there are pros and cons both ways. > > Am 07.04.20 um 18:51 schrieb Paolo Prete: > > as said to Kieren, this is not a good rule. > > I know that you said it already but I disagree. I find it easier to

Re: Unwanted warnings/errors on pedals for multiple voices

On Tue, Apr 7, 2020 at 4:13 PM Noeck wrote: > Hi Paolo and Kieren, > > I am currently running into the same issues. I also find jumping pedal > marks irritating, even the Ped * variant. My preferred algorithm for > pedal spacing and alignment (not backed up by any notation standard) > would be

Re: Unwanted warnings/errors on pedals for multiple voices

On Tue, Apr 7, 2020 at 3:41 PM Kieren MacMillan wrote: > Hi Paolo, > > > As a general engraving rule/practice, pedals should be aligned only if > consecutive ones are enough close. > > Exactly. That’s what I’m doing — or, more accurately, letting the separate > context do automatically. > > Hi

Re: Unwanted warnings/errors on pedals for multiple voices

On Tue, Apr 7, 2020 at 3:56 AM Kieren MacMillan wrote: > Hi Paolo, > > > Why do you say they are visually distracting? > > Because as a pianist, it’s easier for me to read > > _/\ _/\ _/\ > > than > >_/\ > _/\

Unwanted warnings/errors on pedals for multiple voices

On Tuesday, April 7, 2020, Kieren MacMillan wrote: > Hi Paolo, > > > I don't think it would be useful to assign a layer to the pedal > information. It doesn't add any benefit in terms of visual clarity, it > doesn't save space and it adds redundancy (which is hard to manage when the > score

Re: Unwanted warnings/errors on pedals for multiple voices

On Tue, Apr 7, 2020 at 1:46 AM Kieren MacMillan wrote: > Hi Paolo, > > > All this considered, IMHO (and considered that I really got crazy with > this warnings for weeks): > > > > 1) The "Dynamics line" solution should be discouraged in the > documentation. I can be wrong but I really don't

Re: Unwanted warnings/errors on pedals for multiple voices

On Mon, Apr 6, 2020 at 8:02 PM Carl Sorensen wrote: > > > > > *From: *Paolo Prete > *Date: *Monday, April 6, 2020 at 11:25 AM > *To: *Carl Sorensen > *Cc: *Thomas Morley , Kieren MacMillan < > kie...@kierenmacmillan.info>, Lilypond-User Mailing List < >

Re: Unwanted warnings/errors on pedals for multiple voices

On Mon, Apr 6, 2020 at 6:17 PM Carl Sorensen wrote: > > To me, the ideal default is PianoStaff. > > > 1) (another example) In a 4 hands piano score this would be undesirable, because it would logically assign the pedal to *one* performer, while it can switch from performer1 to performer2. For

Re: Unwanted warnings/errors on pedals for multiple voices

On Mon, Apr 6, 2020 at 4:25 PM Thomas Morley wrote: > Am Mo., 6. Apr. 2020 um 16:03 Uhr schrieb Paolo Prete < > paolopr...@gmail.com>: > > > > > > > > On Mon, Apr 6, 2020 at 3:08 PM Kieren MacMillan < > kie...@kierenmacmillan.info> wrote:

Re: Unwanted warnings/errors on pedals for multiple voices

On Mon, Apr 6, 2020 at 3:08 PM Kieren MacMillan wrote: > Hi all, > > > You could move the Piano_pedal_performer from Voice to Staff level. > > Add or remove the \consists command to hear the difference. > > Is there some reason this shouldn’t be the default? > I can’t imagine Voice-independent

Re: Unwanted warnings/errors on pedals for multiple voices

On Sun, Apr 5, 2020 at 6:04 PM Timothy Lanfear wrote: > > You could move the Piano_pedal_performer from Voice to Staff level. Add > or remove the \consists command to hear the difference. > > \version "2.20.0" > > \midi { > \context { \Voice \remove Piano_pedal_performer } > \context {

Unwanted warnings/errors on pedals for multiple voices

Hello, I still experience unwanted warnings (and, consequently, unwanted behavior on midi) with pedals on PianoStaff with multiple voices. Consider this example (tested on 2.19.84): \version "2.19.84" upper = { << {c'8\sustainOn c' c'} \\ {r8 r r} >> << {c'8 c' r} \\ {r8

Re: Can't modify multiple shapes on a chord

On Thu, Mar 26, 2020 at 1:21 PM David Nalesnik wrote: > > > > > although it does the job I still wonder if the "tweak" (?) method > suggested by Mark can work too, so to have multiple shape commands > together, instead of a shapeColumn. > > > > Best, > > Paolo > > Won't work, hence the elaborate

Re: Can't modify multiple shapes on a chord

> > > In order to get at individual ties in a chord, you have to resort to > desperate measures. Use the code here: > > https://www.mail-archive.com/lilypond-devel@gnu.org/msg47432/shape-tie-columns.ly > > Hope this helps, > David > Thank you David, although it does the job I still wonder if

Re: Can't modify multiple shapes on a chord

> > I haven't seen this construction before ( \new Voice << { } { } >>). > You should either have two separate Voices or put a "\\" in between > the two music expressions, so that lilypond will split it into two > voices. Sorry but I can't figure what is the *right* expression for solving the

Re: Can't modify multiple shapes on a chord

On Wed, Mar 25, 2020 at 4:20 PM Mark Knoop wrote: > At 14:44 on 25 Mar 2020, Paolo Prete wrote: > > Hello. > > > > Please consider this (tested on 2.19.84): > > > > \new Voice << > > { \shape #'((0 . 0) (0 . 0) (0 . 0) (3 . 0)) Tie c' ~ c' } >

Can't modify multiple shapes on a chord

Hello. Please consider this (tested on 2.19.84): \new Voice << { \shape #'((0 . 0) (0 . 0) (0 . 0) (3 . 0)) Tie c' ~ c' } { \shape #'((0 . 0) (0 . 0) (0 . 0) (0 . 0)) Tie c'' ~ c'' } >> If I modify the shape on the first tie, changes are applied on the second tie. Is this a bug? If so, is

Question about stretchability (PianoStaff)

Hello, In case of a PianoStaff: \new PianoStaff << \new Staff { \clef treble r c } \new Staff { \clef bass c s } >> Is it possible, for a chosen note ( "c", in the above code), to not stretch the distance between staves, regardless if this causes a collision/overlay ? Thanks, Best P

Workarounds for cross-staff

Hello, I am doing some experiments with the cross-staff and I want to show you how some limits and collisions can be bypassed through some workarounds that I would like to automate. Cross-staff is achieved through two basic commands: 1) \change Staff 2) \crossStaff And I show you how both the

Re: Question on cross-staff

On Saturday, February 29, 2020, Mark Stephen Mrotek wrote: > Paolo, > > > > Looking at the referenced post, as a performer I have to ask “Why?” > > > > Mark > > > > > Because I experience these cross-staff collisions very frequently and, given that there won't be an improvement of that

Re: Question on cross-staff

On Sat, Feb 29, 2020 at 1:04 AM Andrew Bernard wrote: > Hello Paolo, > > I have experimented with this in the past. As far as I know it cannot be > done. You have to use the cross staff functions. > > What do you say is buggy? > > Hi Andrew, I just found a way to obtain this, through a hack. I

Question on cross-staff

Hello. Please look at the snippet below. A cross-staff behavior would be obtained with the "\change Staff" command. But given that this method is very buggy (not in this case, but in many other situations), I wonder if it can bypassed by adding "fake" stems on the rests on the upper staff (and

Question about collisions on multiple voices

Hello, given two voices, for example: \new Staff << \new Voice = "first" { \voiceOne c'8[ c'^> c' c']} \new Voice= "second" { \voiceTwo \stemUp c''8[ c'' c'' c''] } >> ... is it possible to make the script " ^>" avoid collisions on the other voice too? Thanks!

Re: Set the position(s) of a SustainPedal spanned in multiple staves

> > This is usually where \alterBroken comes into play. It works with > anything that is a Spanner, allowing you to specify the desired value > for each segment. > > > { >\set Staff.pedalSustainStyle = #'mixed >\alterBroken Y-offset #'(0 -16) Staff.SustainPedalLineSpanner >

Set the position(s) of a SustainPedal spanned in multiple staves

Hello, If the same SustainPedal belongs to more than one staff, how can I override its position only for a chosen staff? For example: { \set Staff.pedalSustainStyle = #'mixed c'2\sustainOn c' c'1 \break % DOESN'T WORK (I'm trying to override Y-offset only for the second staff)

Re: box-stencil (was: Drawing boxes around grobs)

On Mon, Feb 24, 2020 at 5:47 PM Paolo Prete wrote: > > >> >> This is pretty weird. It happens if I produce a SVG output and open it >> with Chrome/Chromium-browser... >> (no problem with Firefox) >> >> > It seems something associated with chrome/chr

Re: box-stencil (was: Drawing boxes around grobs)

> > This is pretty weird. It happens if I produce a SVG output and open it > with Chrome/Chromium-browser... > (no problem with Firefox) > > It seems something associated with chrome/chromium's default font, which is smaller than the Firefox default one (while the box dimensions remain the same)

Re: box-stencil (was: Drawing boxes around grobs)

On Mon, Feb 24, 2020 at 5:07 PM Thomas Morley wrote: Can't see any other padding than the specified 0.3 ... > > This is pretty weird. It happens if I produce a SVG output and open it with Chrome/Chromium-browser... (no problem with Firefox) Best, P

Re: box-stencil (was: Drawing boxes around grobs)

Thanks to Torsten and Harm Another issue seems to be in TextScript: { \override TextScript.stencil = #(make-stencil-boxer 0.1 0.3 ly:text-interface::print) c'4_"foo bar bar" } In 2.19.84, the box adds unwanted right padding, while 2.19.45 (Lilybin) doesn't. Any feedback/fix/workaround?

Re: box-stencil (was: Drawing boxes around grobs)

On Sun, Feb 23, 2020 at 12:54 PM Torsten Hämmerle wrote: > > A *pragmatic solution* to your problem would be to re-define the dynamics > definitions concerned, simply adding a wee bit of space to the left and to > the right, as in > > mf = #(make-dynamic-script (markup #:line (#:hspace 0.2

Re: box-stencil (was: Drawing boxes around grobs)

at 1:19 AM Paolo Prete wrote: > (This is for Aaron (and anyone who shows interest...) > > Hi Aaron, > > I need a little fix on the wonderful function you implemented. > As you can see, in case of dynamic, the box has a little unwanted overlay. > How we could avoid this? &

box-stencil (was: Drawing boxes around grobs)

(This is for Aaron (and anyone who shows interest...) Hi Aaron, I need a little fix on the wonderful function you implemented. As you can see, in case of dynamic, the box has a little unwanted overlay. How we could avoid this? Thanks, Best P \version "2.19.83" #(define (box-stencil

Re: An alternative outside-staff spacing method (new version)

I just fixed the typo highlighted by Aaron. It was responsible of the hairpin problem. I also added these two lines, which strengthen the snippet in case of slurs and hairpins \override Staff.TextScript.avoid-slur = #'ignore \override Staff.DynamicLineSpanner.outside-staff-padding = 0 Now all

Re: An alternative outside-staff spacing method (new version)

On Tue, Feb 11, 2020 at 9:15 PM Aaron Hill wrote: > On 2020-02-11 8:05 am, Paolo Prete wrote: > > thanks to the _great_ support of Aaron and Harm, I implemented this new > > version of the outside-staff spacing method I proposed some days ago. > > I am getting quite a fe

An alternative outside-staff spacing method (new version)

Hello all, thanks to the _great_ support of Aaron and Harm, I implemented this new version of the outside-staff spacing method I proposed some days ago. Please note that in this way you can order and pad outside staff objects in *any* combination you want, in a very easy way. And you can obtain

Re: Drawing boxes around grobs

On Sat, Feb 8, 2020 at 10:36 PM Thomas Morley wrote: > Am Sa., 8. Feb. 2020 um 22:20 Uhr schrieb Paolo Prete < > paolopr...@gmail.com>: > > > > > > > You could redefine box-stencil to take an additional color-argument. > Also stencil-boxer to take an option

Re: Drawing boxes around grobs

On Sat, Feb 8, 2020 at 9:06 PM Thomas Morley wrote: > Am Sa., 8. Feb. 2020 um 19:26 Uhr schrieb Paolo Prete < > paolopr...@gmail.com>: > > > > { > \override TextScript.stencil = > #(make-stencil-boxer 0.1 0.3 ly:text-interface::print) > > \override

Drawing boxes around grobs

Hello, The documentation shows this example: \override TextScript.stencil = #(make-stencil-boxer 0.1 0.3 ly:text-interface::print) c'4^"foo" (http://lilypond.org/doc/v2.19/Documentation/snippets/tweaks-and-overrides) Is it possible to adapt it for other grobs too? I would like to use it for

Re: Spacing grobs with an invisible object between them (hack)

On Fri, Feb 7, 2020 at 4:28 AM Aaron Hill wrote: > I have applied this logic to your code and made some changes [1]. > > [1]: http://lilybin.com/bt0t2d/11 > > That's great, Aaron! Now we have a very robust method for *easy* spacing *complex* vertical layouts. I would not even consider this a

Re: Spacing grobs with an invisible object between them (hack)

On Thu, Feb 6, 2020 at 6:04 PM Aaron Hill wrote: > On 2020-02-06 8:35 am, Paolo Prete wrote: > > I ask you if is it possible to remove the noisy default #OSSPW param > > as > > well, in the function call. > > Also: I'm seeing that it compiles well on 2.19.45 (l

Re: Spacing grobs with an invisible object between them (hack)

On Thu, Feb 6, 2020 at 6:04 PM Aaron Hill wrote: > > Another option would be to accept height and width in the same argument > using a custom type predicate: > > Thanks again. Here's the _complete_ version. http://lilybin.com/bt0t2d/10 I find it *very* useful. In this way you can easily add a

Re: Spacing grobs with an invisible object between them (hack)

On Thu, Feb 6, 2020 at 4:45 PM Aaron Hill wrote: > On 2020-02-06 6:10 am, Paolo Prete wrote: > > (code) > > A few comments on the code: > > Good, thanks Here's the improved version without the noisy syntax and better names (OS = Outside Staff) I ask you if is it possibl

Re: \fontsize in staff-space units

On Thu, Feb 6, 2020 at 2:41 AM Aaron Hill wrote: > > \version "2.19.83" > > #(define-markup-command >(staff-fontsize layout props size arg) >(number? markup?) >(let* ((staff-space (ly:output-def-lookup layout 'staff-space 1)) > (sten (interpret-markup layout props

Re: Spacing grobs with an invisible object between them (hack)

t; 1 2 \mf -\spacer "DOWN" 2 3 \sustainOn -\spacer "DOWN" 3 4 \sostenutoOn -\spacer "DOWN" 4 3 -\setPosition "TextScript" 4 _\markup { "Use pedal with care!"} c c)\sustainOff\sostenutoOff \ottava #0 } } On Thu, Feb 6, 2020 at 5:14 AM Andrew Bernard wrote: > Hello Paolo, > > What are you trying to achieve? > > Andrew > > On Thu, 6 Feb 2020 at 11:48, Paolo Prete wrote: > > > I just had this idea about a *new* method of spacing. >

Spacing grobs with an invisible object between them (hack)

Hello, I just had this idea about a *new* method of spacing. Maybe this is nuts, and it's almost a hack, but I'm seeing that it could work, so, please, leave me a feedback. The idea is create an invisible "obstacle", with a length set in staff-space units, between grobs. Then, assign a position

<    1   2   3   4   5   6   >