Re: problem with \partcombine and dynamics/hairpins

Hi Alex, > I think I wrongly presumed the intention was to achieve a single hairpin in > the score while retaining both hairpins in the separate parts for part > production. That is *my* intention. In my opinion, the partcombiner should give the user the option… but it’s not currently that

Re: crossStaff beaming not connecting both staves

Am 28.09.2016 um 00:01 schrieb Malte Meyn: \version "2.19.47" \new PianoStaff \with { \consists #Span_stem_engraver } << \new Staff { a\harmonic } \new Staff { \crossStaff a } This looks like a Span_stem_engraver bug to me: The NoteHeads don’t share a stem because of the different

Re: problem with \partcombine and dynamics/hairpins

Hi Harm, Thank you - I think I wrongly presumed the intention was to achieve a single hairpin in the score while retaining both hairpins in the separate parts for part production. To achieve this aim one might use tagging, I suppose, but is there another way in this situation of achieving a

Re: crossStaff beaming not connecting both staves

Am 27.09.2016 um 23:05 schrieb Ryan Michael: The problem is the stem does not connect the two staves. Here is the complete piece: Are you serious? 290 lines of code producing a three page score? Please always give a minimal working example and include a version statement. This time I made

Re: Video generation, bash script, keeps sync in spite of tempo changes

Dear all, > [comparison of Knut Petersen's mkvideo vs. > ly2video] There is also another python script written by me and mentioned in a message in this group from March 6th. Funnily it seems to be a mixture of the approaches of Knut Petersen and ly2video. Advantages: + runs on _any_

Re: problem with \partcombine and dynamics/hairpins

2016-09-27 22:56 GMT+02:00 Alex Voice : > Hi Harm, > > I'm not familiar with the partcombiner, though, below a very bad > workaround, found deep, deep in the quick n' dirty junk room. > > \version "2.19.48" > > terminateHairpin = > #(define-music-function (ctx-name

crossStaff beaming not connecting both staves

I am following the lilypond documentation for cross Staff beaming: http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-keyboards#cross_002dstaff-stems I have the following in my lower voice: %% r8 r32 \autoBeamOff \voiceOne \crossStaff{ des,32-> \tuplet 4/3{

Re:problem with \partcombine and dynamics/hairpins

Hi Harm, > I'm not familiar with the partcombiner, though, below a very bad > > workaround, found deep, deep in the quick n' dirty junk room. > > > > > \version "2.19.48" > > > > > terminateHairpin = > > #(define-music-function (ctx-name mus)(string? ly:music?) > > #{ << $mus

Re: Extracting symbol location

Hi Urs, On Tue, Sep 27, 2016 at 3:58 AM, Urs Liska wrote: > > > Am 26.09.2016 um 20:13 schrieb David Nalesnik: >> The link you cite mentions looking at SVG output, and I suppose that >> would be the best way. I can't think of another method to get the >> actual print

Re: Question: Cross compilation

On 27 Sep 2016 18:31, "Jan Nieuwenhuizen" wrote:. > > > A Lilypond build tool for all platforms to which someone's added half > > a dozen extra unrelated targets (possibly very large ones such as > > OpenOffice) = a terrible idea. > > Thanks! GUB was the first to be so generic

Re: Extracting symbol location

Hey David, thank you so much! I am fairly sure that i'll be able to extend this file in a similar fashion to cope with other types of simbols... regards Lukas David Nalesnik schrieb am Di., 27. Sep. 2016 um 17:35 Uhr: > On Tue, Sep 27, 2016 at 10:33 AM, David

Re: Question: Cross compilation

Chris Yate writes: > At a brief look over GUB, the really big question in my mind is why on > earth it seems to want to build *everything*.  That's mostly fault. > A Lilypond build tool for all platforms = a great idea. Thanks. I developed GUB together with Han-Wen and it was our 4th

Re: Extracting symbol location

Hi Lukas, On Tue, Sep 27, 2016 at 8:21 AM, Lukas Tuggener wrote: > Tanks to this \assignIDs function and the information in the svg its pretty > easy to find the correct location of a given symbol. > > The problem im stuck with right now is creating meaningful labels. The way

Re: Extracting symbol location

On Tue, Sep 27, 2016 at 10:33 AM, David Nalesnik wrote: > In the attachment... And now for the file... David \version "2.19.46" % angle brackets cause SVG error so reformat: % # becomes [Mom 1] #(define (reformat-moment mom) (let* ((mom (format #f "~a" mom))

Embedded repeats

Hello folks, This sample is compiled and drawn alright (with a confusing look to it, though). Is this just unsupported, or are there use cases for such an embedding? \version "2.19.44" { \repeat volta 2 { c \repeat volta 2 { d \repeat volta 2 { e } } }

Re: Horizontal alingment of lyrics hyphens?

Am 27.09.2016 um 16:34 schrieb David Kastrup: > Urs Liska writes: > >> But in general the advantage of a feature being solvable in the Scheme >> domain is that it can be done in the "user space", that is, without >> having to compile LilyPond yourself. This is not only

Re: lilypond-book: Processing multiple lytex files with a single command

tapani writes: > I managed to tweak this to make it work for my project. Thank you very much > indeed! > > A further question: > > The way I have built my project is to have lots (100+) individual .lytex > files, which are compiled and the resulting .tex files are included in

Re: Horizontal alingment of lyrics hyphens?

Urs Liska writes: > But in general the advantage of a feature being solvable in the Scheme > domain is that it can be done in the "user space", that is, without > having to compile LilyPond yourself. This is not only lowering the > entry barrier but actually makes it

Re: lilypond-book: Processing multiple lytex files with a single command

I managed to tweak this to make it work for my project. Thank you very much indeed! A further question: The way I have built my project is to have lots (100+) individual .lytex files, which are compiled and the resulting .tex files are included in a master .tex file (using \input). However, for

Re: Horizontal alingment of lyrics hyphens?

Am 27.09.2016 um 15:22 schrieb Simon Albrecht: >> Advantages of this solution: All that could be done in c / c++ / >> postscript, no need for scheme. >> As there is no need to understand and change the blackbox lilypond >> it's much easier and faster >> to implement. > > That’s an interesting

Re: Horizontal alingment of lyrics hyphens?

On 27.09.2016 14:45, Knut Petersen wrote: Am 25.09.2016 um 11:34 schrieb Simon Albrecht: Simon showed how to whiteout barlines, but Krzysztof also asked about aligning hyphens in verses. Have a look at the attached pdf and compare Lilyponds output to the hand-engraved original. Seems like

Re: Extracting symbol location

Tanks to this \assignIDs function and the information in the svg its pretty easy to find the correct location of a given symbol. The problem im stuck with right now is creating meaningful labels. The way the ID is constructed right now is Name+Momentum?+RelativeLocation. And i am not able to tell

Re: Horizontal alingment of lyrics hyphens?

On 20.09.2016 12:11, Simon Albrecht wrote: On 19.09.2016 17:48, kmg wrote: From what I read, hyphens are always centered between syllables, so my question: is there a way to avoid them getting into barlines, I use the following in my standard style sheet: For the record, this is

Re: Horizontal alingment of lyrics hyphens?

Am 25.09.2016 um 11:34 schrieb Simon Albrecht: Simon showed how to whiteout barlines, but Krzysztof also asked about aligning hyphens in verses. Have a look at the attached pdf and compare Lilyponds output to the hand-engraved original. Seems like a good feature request. Could you please

Re: Extracting symbol location

Am 26.09.2016 um 20:13 schrieb David Nalesnik: > The link you cite mentions looking at SVG output, and I suppose that > would be the best way. I can't think of another method to get the > actual print positions of objects. > Hm, but at some point LilyPond *has* to know where objects are

Re: Extracting symbol location

Hi David Many thanks, this will help me greatly, when parsing the .svg files. Upcoming patches will not be an issue, because i will have to run this just once. Thanks again and have a good day Lukas David Nalesnik schrieb am Mo., 26. Sep. 2016 um 20:13 Uhr: > Hi

Re: Question: Cross compilation

- Original Message - From: "Richard Shann" To: "Phil Holmes" Cc: "David Kastrup" ; "Lilypond-User Mailing List" Sent: Tuesday, September 27, 2016 8:54 AM Subject: Re: Question: Cross compilation On

Re: Question: Cross compilation

- Original Message - From: "David Kastrup" To: "Phil Holmes" Cc: "Richard Shann" ; "Lilypond-User Mailing List" Sent: Tuesday, September 27, 2016 9:04 AM Subject: Re: Question: Cross compilation

Re: Question: Cross compilation

"Phil Holmes" writes: > - Original Message - > From: "Richard Shann" > To: "David Kastrup" > Cc: "Lilypond-User Mailing List" > Sent: Tuesday, September 27, 2016 8:38 AM > Subject: Re: Question: Cross

Re: Question: Cross compilation

On Tue, 2016-09-27 at 08:53 +0100, Phil Holmes wrote: > - Original Message - > From: "Richard Shann" > To: "David Kastrup" > Cc: "Lilypond-User Mailing List" > Sent: Tuesday, September 27, 2016 8:38 AM > Subject: Re:

Re: Question: Cross compilation

On 27 Sep 2016 03:59, "David Kastrup" wrote: > > > At a brief look over GUB, the really big question in my mind is why on > > earth it seems to want to build *everything*. > > It wants to be _able_ to build everything, like autoconf. Fine. But Autoconf doesn't ship with makefiles

Re: Question: Cross compilation

- Original Message - From: "Richard Shann" To: "David Kastrup" Cc: "Lilypond-User Mailing List" Sent: Tuesday, September 27, 2016 8:38 AM Subject: Re: Question: Cross compilation and, more specifically, I would guess they

Re: Question: Cross compilation

On Tue, 2016-09-27 at 04:23 +0200, David Kastrup wrote: > Chris Yate writes: > > > On Mon, 26 Sep 2016 at 19:34 David Kastrup wrote: > > > >> > >> That's pretty good, actually. Not being able to do native/online > >> compilations by anybody wanting to is bad.