Re: How to detect SpanBar from inside a make-bar-line definition?

general software-design advice based on a hasty > > consideration of your post, so I'm not really surprised. > > > > > To give a different example, let's look at make-dotted-bar-line (afaik > > > it's your code). > > > There you have a `making-span-bar?'-con

Re: How to detect SpanBar from inside a make-bar-line definition?

ised. > > > To give a different example, let's look at make-dotted-bar-line (afaik > > it's your code). > > There you have a `making-span-bar?'-condition, obviously you want a > > span bar a little different than bar line. > > Yes, I remember that there w

Re: How to detect SpanBar from inside a make-bar-line definition?

On 2024-03-13 20:09, Thomas Morley wrote: I don't understand what you propose. My advice was general software-design advice based on a hasty consideration of your post, so I'm not really surprised. To give a different example, let's look at make-dotted-bar-line (afaik

Re: How to detect SpanBar from inside a make-bar-line definition?

Am Mi., 13. März 2024 um 23:56 Uhr schrieb Dan Eble : > > On 2024-03-13 17:35, Thomas Morley wrote: > > > currently I'm attempting to improve dashed/dotted bar lines wrt to > > changed staff-space and span bars. > > We use both definitions for BarLine _a

Re: How to detect SpanBar from inside a make-bar-line definition?

On 2024-03-13 17:35, Thomas Morley wrote: currently I'm attempting to improve dashed/dotted bar lines wrt to changed staff-space and span bars. We use both definitions for BarLine _and_ SpanBar, but then SpanBar is frequently a little off. It would be nice to have a possibility to d

How to detect SpanBar from inside a make-bar-line definition?

Hi, currently I'm attempting to improve dashed/dotted bar lines wrt to changed staff-space and span bars. We use both definitions for BarLine _and_ SpanBar, but then SpanBar is frequently a little off. It would be nice to have a possibility to detect whether a definition is used for span

Re: Tick bar from font

On May 5, 2023, at 06:14, Jean Abou Samra wrote: > > Le jeudi 04 mai 2023 à 22:51 -0400, Dan Eble a écrit : >> >> >> I thought it would be nice to be able to draw a tick BarLine from a font >> glyph in lieu of the default rounded rectangle. I have a working prototype >> that uses a new prope

Re: Tick bar from font

Le jeudi 04 mai 2023 à 22:51 -0400, Dan Eble a écrit : > I thought it would be nice to be able to draw a tick BarLine from a font > glyph in lieu of the default rounded rectangle.  I have a working prototype > that uses a new property BarLine.tick-font-glyph- > name to enable the behavior, but I

Tick bar from font

Divisio.font-size = #-2. In order to make a tick BarLine that looks about the same, I could override BarLine.font-size = #-2. That would be fine for the tick, but it would also shrink other font glyphs (dots, bracket tips, segno and kievan bar lines). I'm not sure what to do. * add an

Re: Bar lines in mensural notation (request for interpretation)

I hope to understand whether to regard the bar lines in the > rest of the book as a normal part of the notation that this author > is teaching, or rather as a learning aid that he expects the reader > not to carry over into his work. > > More context might be required. The book is

Bar lines in mensural notation (request for interpretation)

Everything I know about 16th-Century Italian I learned from 20th-Century Spanish. I hope that someone here is able and willing to check my guesses about this. The following text seems to follow an introduction to mensural rests, and it surrounds a figure of a single bar line and a double bar

Re: \bar "|.|"

Le 04/06/2022 à 19:31, Dan Eble a écrit : Does anyone know the use case for bar type "|.|"? Is it intended as a variation of ":|.|:" without dots? I have a feeling that it should decompose at a line break as repeat bar types do. It currently appears as "|.|" at

\bar "|.|"

Does anyone know the use case for bar type "|.|"? Is it intended as a variation of ":|.|:" without dots? I have a feeling that it should decompose at a line break as repeat bar types do. It currently appears as "|.|" at the end of a line. Thanks, — Dan

Re: Bar lines in hymns

On Jan 16, 2022, at 15:36, Dan Eble wrote: > > I have a mind to generalize the commands for Gregorian divisiones so that > they create breathing signs, bar lines, or scripts over bar lines, according > to context properties. That will serve this case and more, and requir

Re: LilyPond | Improve dotted bar line placement (!1173)

On 2022-02-05 19:52, Dan Eble (@eble) wrote: Dan Eble commented on a discussion : The open thread says that I created a ticket to track an issue. I left it open because I wanted it to be vi

Re: Bar lines in hymns

On Dec 20, 2021, at 19:03, Dan Eble wrote: > > On Dec 20, 2021, at 16:46, Karlin High wrote: >> >> On 12/19/2021 1:44 PM, Dan Eble wrote: >>> Does anyone know a term for this bar line or practice? >> >> From a music tradition based on older American hy

Re: Bar lines in hymns

On Dec 20, 2021, at 16:46, Karlin High wrote: > > On 12/19/2021 1:44 PM, Dan Eble wrote: >> Does anyone know a term for this bar line or practice? > > From a music tradition based on older American hymnals, I know this as a > "phrase bar." Thank you. Tha

Bar lines in hymns

There is a type of bar line that looks the same as a section bar line but is used where a mid-measure break coincides with a line break in the text. Example: https://hymnary.org/hymn/GRH1911/6 (systems 2 and 4) Does anyone know a term for this bar line or practice? Thank you, — Dan

Re: Written-end bar line

not the end of the piece" (Behind Bars, p.240). > >The statement is in the context of repeated sections: D.S. al Fine, etc. > >I'm pretty sure that this is easy to implement. Is there any reason not > to make this a default? >— >Dan > > II

Re: Written-end bar line

ctions: D.S. al Fine, etc. I'm pretty sure that this is easy to implement. Is there any reason not to make this a default? — Dan II do not want it to be a default. I want to have control of the bar lines. Ossia staffs do not have thin double bars, as far as I can see. The e

Written-end bar line

Gould writes that "[a] thin double barline ... marks the written end of the music when this is not the end of the piece" (Behind Bars, p.240). The statement is in the context of repeated sections: D.S. al Fine, etc. I'm pretty sure that this is easy to implement. Is there any reason not to mak

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

On Nov 15, 2020, at 10:01, Joram Noeck wrote: > > 1. putting the bar number over the measure it belongs just makes sense > (-> Gould) . . . > 3. In particular at the start of a line, the number is moved up by every > treble clef, i.e. we have an exception by collision avoid

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

On 15/11/20 15:14, Werner LEMBERG wrote: > As Jonas said, this is a completely different issue, but yes, I think > there implementing bar-centered bar numbers would need a completely > different implementation. IF this is seriously considered, can I throw in my thing often encountere

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

On 15/11/20 14:53, Werner LEMBERG wrote: > >> I appreciate that you have given a nuanced response. Practically >> speaking, the vast majority of scores only have bar numbers at the >> beginning of a line, so I will simplistically categorise your response >> as in f

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

On 15/11/20 13:37, Graham King wrote: > I think Gould's positioning looks _slightly_ better, except at > line-beginnings where I definitely prefer lilypond's. Moreover, the position > immediately after a bar line is heavily-contested real-estate, as your > examples mak

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

nstead of forcing people to >>>> (ab)use MeasureCounter]… >>>> >>>> Is there any technical reason the main BarNumber code can’t be >>>> improved to allow users to have bar numbers centred within the >>>> measure? >>> >>&

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

Hi all, > Looks like my recollection was wrong here: In most *classical* scores. > The medleys of film music that I played in (hobby) orchestras mostly > use rehearsal marks and / or bar numbers *below* bar lines. Yes. >> Measure-centred bar numbers are fairly standard in film

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

; > > > > > Is there any technical reason the main BarNumber code can’t be > > > improved to allow users to have bar numbers centred within the > > > measure? > > > > I think that's a totally different topic and not actually related to > > p

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

Am Sonntag, den 15.11.2020, 10:14 -0500 schrieb Kieren MacMillan: > Hi Jonas, > > > I think that's a totally different topic and not actually related to > > positioning the usual bar numbers that are above the bar line in all > > scores that I ever played from.

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

At 15:01 on 15 Nov 2020, Joram Noeck wrote: > Hi, > > I like the change in the bar number alignment. I have some comments to > your proposal. (The current solution has similar issues, so most of > these are not speaking against proposed changes.) > > The -> denotes the so

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

> Those are included in the examples purely for the sake of completeness. > Gould has nothing to say about such bar numbers and I would surprised if > any scores included them. But is it possible that they have a different alignment with the current code? In case a user turns them on, t

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

Hi Jonas, > I think that's a totally different topic and not actually related to > positioning the usual bar numbers that are above the bar line in all > scores that I ever played from. Why? We’re talking about selecting the position of usual bar numbers, right? I think the user

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

to > (ab)use MeasureCounter]… > > Is there any technical reason the main BarNumber code can’t be > improved to allow users to have bar numbers centred within the > measure? As Jonas said, this is a completely different issue, but yes, I think there implementing bar-centered bar numbers would

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

s >> made me wonder if it’s possible to roll measure-centred measure >> numbers into the actual BarNumber code [instead of forcing people to >> (ab)use MeasureCounter]… >> >> Is there any technical reason the main BarNumber code can’t be >> improved to allow users

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

> numbers into the actual BarNumber code [instead of forcing people to > (ab)use MeasureCounter]… > > Is there any technical reason the main BarNumber code can’t be > improved to allow users to have bar numbers centred within the > measure? I think that's a totally diffe

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

MeasureCounter]… Is there any technical reason the main BarNumber code can’t be improved to allow users to have bar numbers centred within the measure? Thanks, Kieren. Kieren MacMillan, composer (he/him/his) ‣ website: www.kierenmacmillan.info ‣ email: kie

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

> I would very much like that LilyPond has the ability of automatically > adjusting the horizontal position of some grobs, in particular dynamic > signs, bar numbers, and rehearsal marks. The idea is that a large > delta from the optimum vertical position would make LilyP

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

Hi, I like the change in the bar number alignment. I have some comments to your proposal. (The current solution has similar issues, so most of these are not speaking against proposed changes.) The -> denotes the solution for which that is an argument. 1. putting the bar number over the meas

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

t; position immediately after a bar line is heavily-contested > > real-estate, as your examples make clear. Therefore it would be good > > to retain the option to preserve the status quo, especially where > > convert-ly might otherwise cause skyline changes to existing scores. >

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

> I appreciate that you have given a nuanced response. Practically > speaking, the vast majority of scores only have bar numbers at the > beginning of a line, so I will simplistically categorise your response > as in favour of keeping LilyPond's current behaviour. I would ve

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

On Sun, Nov 15, 2020 at 01:37:34PM +, Graham King wrote: > I think Gould's positioning looks _slightly_ better, except at > line-beginnings where I definitely prefer lilypond's. Moreover, the > position immediately after a bar line is heavily-contested > real-estate,

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

ss. Gould has nothing to say about such bar numbers and I would surprised if any scores included them. Kevin

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

I think Gould's positioning looks _slightly_ better, except at line-beginnings where I definitely prefer lilypond's. Moreover, the position immediately after a bar line is heavily-contested real-estate, as your examples make clear. Therefore it would be good to retain the option t

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

On Sun, Nov 15, 2020 at 6:11 AM Michael Käppler wrote: > > Am 15.11.2020 um 12:36 schrieb Werner LEMBERG: > >> I will be the first responder and say that, of the options in the > >> pdf, I think Gould is the most appropriate. > > Yep. > +1 > > > > > > Werner > > > > Another vote for Gould.

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

Am 15.11.2020 um 12:36 schrieb Werner LEMBERG: I will be the first responder and say that, of the options in the pdf, I think Gould is the most appropriate. Yep. +1 Werner

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

> I will be the first responder and say that, of the options in the > pdf, I think Gould is the most appropriate. Yep. Werner

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

On Sun, Nov 15, 2020 at 11:02:52AM +, Kevin Barry wrote: > - if you have a preference for one of the four, please indicate which I will be the first responder and say that, of the options in the pdf, I think Gould is the most appropriate. Kevin

Alignment and style of bar numbers

Hi all, LilyPond currently aligns all bar numbers on their right side,  like in this example (output attached): \layout {   \context {     \Score     \override BarNumber.break-visibility = #all-visible   } } \repeat unfold 10 { c'1 } I have found this to be confusing for musicians d

Re: musicxml2ly: Emit bar checks for all voices (issue 553620043 by jonas.hahnf...@gmail.com)

) and n != voice._elements[0]: On 2020/03/10 00:20:12, Dan Eble wrote: > Is the purpose of n != voice._elements[0] to avoid printing a bar check at the > beginning of the first measure? If so, I would have been less puzzled if the > comment were "print a bar check at the beginning of

musicxml2ly: Emit bar checks for all voices (issue 553620043 by jonas.hahnf...@gmail.com)

._elements[0]: Is the purpose of n != voice._elements[0] to avoid printing a bar check at the beginning of the first measure? If so, I would have been less puzzled if the comment were "print a bar check at the beginning of every measure after the first" or simply "print bar checks between m

Re: Midi block gives errors with bar number checks

On Nov 27, 2019, at 14:19, Dan Eble wrote: > > On Nov 27, 2019, at 12:06, Carl Sorensen wrote: >> >> From the user point of view, the ideal solution would be that if a score >> that includes bar number checks was handled by a midi block , the bar >>

Re: Midi block gives errors with bar number checks

On Nov 27, 2019, at 12:06, Carl Sorensen wrote: > > From the user point of view, the ideal solution would be that if a score that > includes bar number checks was handled by a midi block , the bar number > checks would be ignored. That's probably easily achievable. I

Re: Midi block gives errors with bar number checks

On 11/27/19, 9:55 AM, "Dan Eble" wrote: On Nov 27, 2019, at 11:35, Carl Sorensen wrote: > > It’s not bar checks causing the problem, it's bar number checks. Oh, thanks for the correction. It doesn't look difficult to add a context

Re: Midi block gives errors with bar number checks

On Nov 27, 2019, at 11:35, Carl Sorensen wrote: > > It’s not bar checks causing the problem, it's bar number checks. Oh, thanks for the correction. It doesn't look difficult to add a context property to deactivate bar number checks. Would that be the ideal solution? — Dan

Re: Midi block gives errors with bar number checks

ks >> using variables and use my favorite texteditor it really isn't that much >> extra work and it is a usable workaround for Lilypond's restrictions. >> >> Sometimes even \unfoldRepeats doesn't do the trick. I haven't used

Re: Midi block gives errors with bar number checks

extra work and it is a usable workaround for Lilypond's restrictions. >> >> Sometimes even \unfoldRepeats doesn't do the trick. I haven't used bar checks. Have you tried setting the ignoreBarChecks property? If you don't know what that means, and if you are willing to post a minimal example of the problem, I am willing to try setting it for you. — Dan

Re: Midi block gives errors with bar number checks

On 11/27/19, 7:20 AM, "lilypond-devel on behalf of James Lowe" wrote: Hello, On Wed, 27 Nov 2019 10:51:15 +0100 (CET), Martin Tarenskeen wrote: > > > On Wed, 27 Nov 2019, Peter Toye wrote: > > > I'm not sure how many LP user use the MIDI output anywa

Re: Midi block gives errors with bar number checks

Hello, On Wed, 27 Nov 2019 10:51:15 +0100 (CET), Martin Tarenskeen wrote: > > > On Wed, 27 Nov 2019, Peter Toye wrote: > > > I'm not sure how many LP user use the MIDI output anyway, given its > > restrictions. Personally, I use it for proof-reading only, so lack of > > repeats isn't an is

LSR-snippet "Incrementing bar numbers in volta repeats"

Hi, I had a look into the unapproved LSR-snippet "Incrementing bar numbers in volta repeats" lsr.di.unimi.it/LSR/Item?u=1&id=1080 Imho, the output is plain wrong. Valentin, it's obviously your snippet, may I ask you to fix it. For now I added [needs correction] to th

Improve make-bracket-bar-line (issue 339670043 by thomasmorle...@gmail.com)

Reviewers: , Description: Improve make-bracket-bar-line The previously used ly:stencil-scale -1 1 resulted in wrongly positioned SpanBars in certain cases. Replaces ly:stencil-scale by flip-stencil. Please review this at https://codereview.appspot.com/339670043/ Affected files (+1, -1 lines

Re: BUG: Lilypond forgets to draw barline spanner after \bar ""

Knut Petersen writes: > Am 19.09.2016 um 14:29 schrieb Simon Albrecht: >> Sorry, Knut, but this is a totally inacceptable report. It’s not >> clear what you want, and you come up with an example of 300+ lines >> of code. > > There are times where you cannot see the wood for the trees. I posted >

Re: BUG: Lilypond forgets to draw barline spanner after \bar ""

Am 19.09.2016 um 14:29 schrieb Simon Albrecht: Sorry, Knut, but this is a totally inacceptable report. It’s not clear what you want, and you come up with an example of 300+ lines of code. There are times where you cannot see the wood for the trees. I posted the original mail because I was una

Re: BUG: Lilypond forgets to draw barline spanner after \bar ""

Am 19.09.2016 um 14:29 schrieb Simon Albrecht: Sorry, Knut, but this is a totally inacceptable report. It’s not clear what you want, and you come up with an example of 300+ lines of code. There are times where you cannot see the wood for the trees. I posted the original mail because I was unab

Re: BUG: Lilypond forgets to draw barline spanner after \bar ""

On 20/09/16 10:58, Simon Albrecht wrote: > On 19.09.2016 17:12, Wols Lists wrote: >> On 19/09/16 13:29, Simon Albrecht wrote: >>> On 19.09.2016 14:17, Knut Petersen wrote: >>>> Hi everybody! >>>> >>>> As far as I understand after \ba

Re: BUG: Lilypond forgets to draw barline spanner after \bar ""

On 19.09.2016 17:12, Wols Lists wrote: On 19/09/16 13:29, Simon Albrecht wrote: On 19.09.2016 14:17, Knut Petersen wrote: Hi everybody! As far as I understand after \bar "" a \break is permitted in the middle of a bar. Lilypond is supposed to engrave the next barline at the proper

Re: BUG: Lilypond forgets to draw barline spanner after \bar ""

2016-09-19 14:17 GMT+02:00 Knut Petersen : > Hi everybody! > > As far as I understand after \bar "" a \break is permitted in the middle of > a bar. > Lilypond is supposed to engrave the next barline at the proper place. > > At the marked places ( FIXME/ BUG) in the a

Re: BUG: Lilypond forgets to draw barline spanner after \bar ""

sorry for the noise. 2016. szept. 19. 18:46 ezt írta ("David Kastrup" ): > Benkő Pál writes: > > >> c2 \bar "" \break c2 c4 > >> > >> That should be two bars with a barline in the middle. > > > > I think not; \bar "

Re: BUG: Lilypond forgets to draw barline spanner after \bar ""

Benkő Pál writes: >> c2 \bar "" \break c2 c4 >> >> That should be two bars with a barline in the middle. > > I think not; \bar "" starts a new bar (after issuing a warning for the > incomplete bar). Seriously, does anybody these days bother test

Re: BUG: Lilypond forgets to draw barline spanner after \bar ""

At 17:39 on 19 Sep 2016, Benkő Pál wrote: >> c2 \bar "" \break c2 c4 >> >> That should be two bars with a barline in the middle. > >I think not; \bar "" starts a new bar (after issuing a warning for the >incomplete bar). Is it really so hard to t

Re: BUG: Lilypond forgets to draw barline spanner after \bar ""

On 19/09/16 16:39, Benkő Pál wrote: >> c2 \bar "" \break c2 c4 >> >> That should be two bars with a barline in the middle. > > I think not; \bar "" starts a new bar (after issuing a warning for the > incomplete bar). > Ummm ... but if that&#x

Re: BUG: Lilypond forgets to draw barline spanner after \bar ""

> c2 \bar "" \break c2 c4 > > That should be two bars with a barline in the middle. I think not; \bar "" starts a new bar (after issuing a warning for the incomplete bar). p ___ lilypond-devel mailing list lilypond-devel@

Re: BUG: Lilypond forgets to draw barline spanner after \bar ""

On 19/09/16 13:29, Simon Albrecht wrote: > On 19.09.2016 14:17, Knut Petersen wrote: >> Hi everybody! >> >> As far as I understand after \bar "" a \break is permitted in the >> middle of a bar. >> Lilypond is supposed to engrave the next barline at t

Re: BUG: Lilypond forgets to draw barline spanner after \bar ""

On 19.09.2016 14:17, Knut Petersen wrote: Hi everybody! As far as I understand after \bar "" a \break is permitted in the middle of a bar. Lilypond is supposed to engrave the next barline at the proper place. At the marked places ( FIXME/ BUG) in the attached score lilypond n

BUG: Lilypond forgets to draw barline spanner after \bar ""

Hi everybody! As far as I understand after \bar "" a \break is permitted in the middle of a bar. Lilypond is supposed to engrave the next barline at the proper place. At the marked places ( FIXME/ BUG) in the attached score lilypond needs to be forced to print a barline ... I think

Re: Clearify ending of hairpins at bar line in NR (issue 301550043 by thomasmorle...@gmail.com)

. Either "A hairpin ending on a downbeat stops at the bar line immediately preceding it." or (because the word 'immediately' seems redundant to me); "A hairpin ending on a downbeat will stop at the preceding bar line." https://co

Clearify ending of hairpins at bar line in NR (issue 301550043 by thomasmorle...@gmail.com)

Reviewers: , Description: Clearify ending of hairpins at bar line in NR Please review this at https://codereview.appspot.com/301550043/ Affected files (+4, -1 lines): M Documentation/notation/expressive.itely Index: Documentation/notation/expressive.itely diff --git a/Documentation

Re: Multi-rest with automatic bar number before and after it

(m-m-r-stop >>(/ (ly:moment-main >> (grob::when (ly:spanner-bound (car mmr) >> RIGHT))) >> fraction))) > > Oh good grief, this sucks. Guess what happens with met

Re: Multi-rest with automatic bar number before and after it

ief, this sucks. Guess what happens with meter changes. You need to use 'rhythmic-location rather than 'when but even then, this only gives you the value of internalBarNumber which is fine for calculating the total number of bars but does not help all that much with the actual bar num

Re: repeating bar numbers and rehearsal marks in frenched score

At 18:24 on 01 Aug 2016, Trevor Daniels wrote: >Mark, you wrote Monday, August 01, 2016 6:03 PM >> At 14:21 on 01 Aug 2016, Phil Holmes wrote: >>>If you create an account on SourceForge and let us have the details, >>>I'll add you to the tracker users. >> >> username: mkdev >> email: m...@opus11

Re: repeating bar numbers and rehearsal marks in frenched score

Mark, you wrote Monday, August 01, 2016 6:03 PM > At 14:21 on 01 Aug 2016, Phil Holmes wrote: > >>If you create an account on SourceForge and let us have the details, >>I'll add you to the tracker users. > > username: mkdev > email: m...@opus11.net You're now a developer AFA SourceForge is con

Re: repeating bar numbers and rehearsal marks in frenched score

At 14:21 on 01 Aug 2016, Phil Holmes wrote: >If you create an account on SourceForge and let us have the details, >I'll add you to the tracker users. username: mkdev email: m...@opus11.net Thanks! -- Mark Knoop ___ lilypond-devel mailing list lilypon

Re: repeating bar numbers and rehearsal marks in frenched score

- Original Message - From: "Mark Knoop" To: "Simon Albrecht" Cc: Sent: Monday, August 01, 2016 12:36 PM Subject: Re: repeating bar numbers and rehearsal marks in frenched score At 13:22 on 01 Aug 2016, Simon Albrecht wrote: Am 01.08.2016 um 10:49 schrieb Mark K

Re: repeating bar numbers and rehearsal marks in frenched score

At 13:22 on 01 Aug 2016, Simon Albrecht wrote: >Am 01.08.2016 um 10:49 schrieb Mark Knoop: > > James, could you test this patch for review please? > > Please create a tracker issue following the CG instructions, with > yourself as owner and Patch:new, and upload the patch for review on > Rietve

Re: [Spamverdacht] Re: repeating bar numbers and rehearsal marks in frenched score

Am 01.08.2016 um 10:49 schrieb Mark Knoop: > James, could you test this patch for review please? Please create a tracker issue following the CG instructions, with yourself as owner and Patch:new, and upload the patch for review on Rietveld. Then James will test it. Best, Simon

Re: repeating bar numbers and rehearsal marks in frenched score

At 21:21 on 31 Jul 2016, David Kastrup wrote: >Mark Knoop writes: >> OK. Attached are two patches and a test case. The patches are two >> alternate methods of approaching the problem. >> >> Keep a staff alive with multiple layers >> --- >> >> This changes the re

Re: repeating bar numbers and rehearsal marks in frenched score

Mark Knoop writes: > On 29/07/16 18:09, Mark Knoop wrote: >> I still think the easiest and most logical way to do this is with >> the Keep_alive_together_engraver. >> >> Prior to the fix for issue 3518 (support for temporary divisi >> staves), the Keep_alive_together_engraver was useful only in >

Re: repeating bar numbers and rehearsal marks in frenched score

On 29/07/16 18:09, Mark Knoop wrote: > I still think the easiest and most logical way to do this is with > the Keep_alive_together_engraver. > > Prior to the fix for issue 3518 (support for temporary divisi > staves), the Keep_alive_together_engraver was useful only in > Frenched scores, i.e. in co

Re: repeating bar numbers and rehearsal marks in frenched score

At 11:06 on 30 Jul 2016, James Lowe wrote: >On 29/07/16 18:09, Mark Knoop wrote: >> At 16:41 on 29 Jul 2016, David Kastrup wrote: >>> I remember that the decision to sort the remove-layers numerically >>> was based on the desire not to have logical circles: with this sort >>> of ordering, the beh

Re: repeating bar numbers and rehearsal marks in frenched score

Hello, On 29/07/16 18:09, Mark Knoop wrote: At 16:41 on 29 Jul 2016, David Kastrup wrote: I remember that the decision to sort the remove-layers numerically was based on the desire not to have logical circles: with this sort of ordering, the behavior of lower numbers does not depend on that of

Re: repeating bar numbers and rehearsal marks in frenched score

tch to split staves is done only at line breaks such that all complex passages are rendered in separate staves." } boring = \set Staff.keepAliveInterfaces = #'() tricky = \unset Staff.keepAliveInterfaces violI=\relative d' { \boring \repeat unfold 100 d4 \tricky 2 \boring \repeat

Re: repeating bar numbers and rehearsal marks in frenched score

Mark Knoop writes: > At 14:11 on 29 Jul 2016, David Kastrup wrote: > >>Hm, so your take is that alignAboveContext is more for establishing >>order rather than a connection to the particular named context. Maybe. > > The documentation seems pretty clear on this: > > http://lilypond.org/doc/v2.19/

Re: repeating bar numbers and rehearsal marks in frenched score

At 14:11 on 29 Jul 2016, David Kastrup wrote: >Mark Knoop writes: >> At 11:26 on 29 Jul 2016, David Kastrup wrote: >>>Mark Knoop writes: At 22:09 on 28 Jul 2016, David Kastrup wrote: >What you are looking for, however, is a >class of simple omission problems. Maybe we can solv

Re: repeating bar numbers and rehearsal marks in frenched score

Mark Knoop writes: > At 11:26 on 29 Jul 2016, David Kastrup wrote: >>Mark Knoop writes: >>> At 22:09 on 28 Jul 2016, David Kastrup wrote: What you are looking for, however, is a class of simple omission problems. Maybe we can solve this completely differently? Like using "alignAbove

Re: repeating bar numbers and rehearsal marks in frenched score

At 11:26 on 29 Jul 2016, David Kastrup wrote: >Mark Knoop writes: >> At 22:09 on 28 Jul 2016, David Kastrup wrote: >>>What you are looking for, however, is a >>>class of simple omission problems. Maybe we can solve this >>>completely differently? Like using "alignAboveContext" being given >>>the

Re: repeating bar numbers and rehearsal marks in frenched score

Mark Knoop writes: > At 22:09 on 28 Jul 2016, David Kastrup wrote: >>Mark Knoop writes: >>> I'm sorry, I am trying to progress this and respond to your >>> suggestions, but it would be nice to receive some proper criticism of >>> my (working) code which amounts to more than just "I don't like >>

Re: repeating bar numbers and rehearsal marks in frenched score

At 22:09 on 28 Jul 2016, David Kastrup wrote: >Mark Knoop writes: >> I'm sorry, I am trying to progress this and respond to your >> suggestions, but it would be nice to receive some proper criticism of >> my (working) code which amounts to more than just "I don't like >> it". > >It makes stuff m

Re: repeating bar numbers and rehearsal marks in frenched score

ff.keepAliveInterfaces = #'() tricky = \unset Staff.keepAliveInterfaces violI=\relative c'' { \boring \repeat unfold 50 c4 \tricky 2 \boring \repeat unfold 48 c4 \boring 2 \boring \repeat unfold 98 c4 \bar "|." } violII=\relative g' { \boring \repe

Re: repeating bar numbers and rehearsal marks in frenched score

Mark Knoop writes: > At 21:03 on 28 Jul 2016, David Kastrup wrote: >>Mark Knoop writes: >>> I'm also unclear as to why you feel that this is unsuitable to be >>> done by the Keep_alive_together_engraver without further nesting. >>> After all, the documentation for this engraver states: >>> >>>

Re: repeating bar numbers and rehearsal marks in frenched score

one only at line breaks such that all complex passages are rendered in separate staves." } boring = \set Staff.keepAliveInterfaces = #'() tricky = \unset Staff.keepAliveInterfaces violI=\relative c'' { \boring \repeat unfold 50 c4 \tricky 2 \boring \repeat unfold 48 c4 \tric

Re: repeating bar numbers and rehearsal marks in frenched score

At 21:03 on 28 Jul 2016, David Kastrup wrote: >Mark Knoop writes: >> I'm also unclear as to why you feel that this is unsuitable to be >> done by the Keep_alive_together_engraver without further nesting. >> After all, the documentation for this engraver states: >> >> These spanners are then ti

  1   2   3   4   5   6   7   >