tie from grace to second in chord
Hi list,
the tie from the f' in the following code goes too far right as if the
f' wasn’t shifted because of the g' (see attachment). Is this a bug? Any
ideas for a workaround?
%%%
\version "2.19.40" % 2.18.2 and earlier
\language "deutsch"
\relative {
\set tieWaitForNote = ##t
\grace { h8~ f'~ g~ }
1
}
%%%
Malte
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Scheme book (p)review
Hi all, preparing a course I'm going to give in June and July turned into a substantial task: I'm ending up writing the book that *I* would have needed some years ago. Basically what I'm trying to do is give readers a chance to properly understand how Scheme can basically be used in LilyPond. It's the same objective as the Scheme tutorials started a while ago on Scores of Beauty, but heading for some kind of comprehensiveness. The book is far from complete and from a state where I'd publicly share the link but if anyone is interested in (p)reviewing i I'll do so privately. Basically I'm interested in three kinds of critical looks from different kinds of readers: - pointing to issues that are not explained clearly or thoroughly enough (i.e for example where I'm still relying on knowledge the reader doesn't have yet) - comments on missing topics - spotting factual errors Best Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tie from grace to second in chord
Am 02.05.2016 um 10:20 schrieb Malte Meyn:
> Hi list,
>
> the tie from the f' in the following code goes too far right as if the
> f' wasn’t shifted because of the g' (see attachment). Is this a bug?
I would say it is a bug, the tie should know where its ending note is.
> Any ideas for a workaround?
Short of \shape? no.
>
> %%%
> \version "2.19.40" % 2.18.2 and earlier
> \language "deutsch"
>
> \relative {
> \set tieWaitForNote = ##t
> \grace { h8~ f'~ g~ }
> 1
> }
> %%%
>
> Malte
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Scheme book (p)review
Hi Urs, Oh my goodness, yes… I am the perfect candidate for this, I think. =) Please send/link. Thanks, Kieren. On May 2, 2016, at 5:27 AM, Urs Liska wrote: > Hi all, > > preparing a course I'm going to give in June and July turned into a > substantial task: I'm ending up writing the book that *I* would have > needed some years ago. Basically what I'm trying to do is give readers a > chance to properly understand how Scheme can basically be used in > LilyPond. It's the same objective as the Scheme tutorials started a > while ago on Scores of Beauty, but heading for some kind of > comprehensiveness. > > The book is far from complete and from a state where I'd publicly share > the link but if anyone is interested in (p)reviewing i I'll do so > privately. Basically I'm interested in three kinds of critical looks > from different kinds of readers: > > - pointing to issues that are not explained clearly or thoroughly enough > (i.e for example where I'm still relying on knowledge the reader > doesn't have yet) > - comments on missing topics > - spotting factual errors > > Best > Urs Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Scheme book (p)review
Hello Kieren, I’ve been looking forward to reading such a book so yes, I’m interested in proof-reading it! JM > Le 2 mai 2016 à 15:32, Kieren MacMillan a > écrit : > > Hi Urs, > > Oh my goodness, yes… I am the perfect candidate for this, I think. =) > > Please send/link. > > Thanks, > Kieren. > > On May 2, 2016, at 5:27 AM, Urs Liska wrote: > >> Hi all, >> >> preparing a course I'm going to give in June and July turned into a >> substantial task: I'm ending up writing the book that *I* would have >> needed some years ago. Basically what I'm trying to do is give readers a >> chance to properly understand how Scheme can basically be used in >> LilyPond. It's the same objective as the Scheme tutorials started a >> while ago on Scores of Beauty, but heading for some kind of >> comprehensiveness. >> >> The book is far from complete and from a state where I'd publicly share >> the link but if anyone is interested in (p)reviewing i I'll do so >> privately. Basically I'm interested in three kinds of critical looks >> from different kinds of readers: >> >> - pointing to issues that are not explained clearly or thoroughly enough >> (i.e for example where I'm still relying on knowledge the reader >> doesn't have yet) >> - comments on missing topics >> - spotting factual errors >> >> Best >> Urs > > > Kieren MacMillan, composer > ‣ website: www.kierenmacmillan.info > ‣ email: i...@kierenmacmillan.info > > > ___ > lilypond-user mailing list > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Scheme book (p)review
I'm very much interested. g. -- View this message in context: http://lilypond.1069038.n5.nabble.com/Scheme-book-p-review-tp190300p190307.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Scheme book (p)review
Hey Urs, I'm willing to review the book. I'm a programmer with very good scheme/lisp knowledge and I've been using lilypond for a number of years. I've written some lilypond scheme functions but not that much. Let me know if I can be of help. Cheers, Immanuel On Mon, May 2, 2016 at 11:27 AM, Urs Liska wrote: > Hi all, > > preparing a course I'm going to give in June and July turned into a > substantial task: I'm ending up writing the book that *I* would have > needed some years ago. Basically what I'm trying to do is give readers a > chance to properly understand how Scheme can basically be used in > LilyPond. It's the same objective as the Scheme tutorials started a > while ago on Scores of Beauty, but heading for some kind of > comprehensiveness. > > The book is far from complete and from a state where I'd publicly share > the link but if anyone is interested in (p)reviewing i I'll do so > privately. Basically I'm interested in three kinds of critical looks > from different kinds of readers: > > - pointing to issues that are not explained clearly or thoroughly enough > (i.e for example where I'm still relying on knowledge the reader > doesn't have yet) > - comments on missing topics > - spotting factual errors > > Best > Urs > > ___ > lilypond-user mailing list > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user > ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Choice of pitch input mode
On Sat 30 Apr 2016 at 09:22:14 (+0200), Noeck wrote: > Am 30.04.2016 um 05:43 schrieb David Wright: > > it would be great > > if it could convert into a canonical style, where canonical could be > > defined in ways such as: every note with pitch&duration; duration (or > > even pitch) on only the first note of each line (omitted elsewhere); > > Frescobaldi offers that in the tools menu (I think it is python-ly in > the background). You're right, it does. Both the embedded and stand-alone version of ly appear to have the functionality required, provided by (in the stripping case): def remove_dups(iterable): """Change reoccurring strings to '' in iterable.""" old = None for i in iterable: yield '' if i == old else i old = i However, unless there's a secret switch somewhere, there's no way of causing that code to be run in the stand-alone version, even though it is two years more up-to-date (2015 vs 2013) than the Frescobaldi I have compared it with. Cheers, David. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Choice of pitch input mode
On Sat 30 Apr 2016 at 10:38:55 (+0200), Malte Meyn wrote: > Am 30.04.2016 um 05:43 schrieb David Wright: > >But it's no surprise that composing directly into LP is only really > >possible in absolute mode. > > It’s not. I’ve always done it in \relative mode using octave checks, > I never had any problems. I guess there's more difference between composing and transcribing than I had realised. It looks from your example as if your leave phrases out and then put them in later. The problem with transcribing is that you often have to do that note by note. An octavation check on every other note soon looks like absolute! A vital part of transcribing for me is a written copy to follow; kind of chicken and egg. So I write the individual lines with gaps where it's muddy, get them roughly right, particularly the overall durations so that LP can break lines, and typeset that as a working copy. (Using absolute is tedious for that.) Then I convert to absolute and try to sort out the muddy bits. As soon as you start, for example, switching inner parts' notes (the bass and the top line tend to be easier), you get in a mess with relative. When you press "R" to refresh the PDF after making a change, the bar you're working on might jump to a different page because suddenly the alto is an octave deeper, the tenor an octave higher, and the music takes more pages to render, than it did. Perhaps composers don't sweat over individual notes like that and/or don't need a decent looking copy in front of them. Some compose at the piano, don't they. Cheers, David. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tie from grace to second in chord
2016-05-02 10:20 GMT+02:00 Malte Meyn :
> Hi list,
>
> the tie from the f' in the following code goes too far right as if the f'
> wasn’t shifted because of the g' (see attachment). Is this a bug? Any ideas
> for a workaround?
>
> %%%
> \version "2.19.40" % 2.18.2 and earlier
> \language "deutsch"
>
> \relative {
> \set tieWaitForNote = ##t
> \grace { h8~ f'~ g~ }
> 1
> }
> %%%
>
> Malte
At least it's ugly.
\shape will not work without other settings - same problem sometimes
happens with tied chords.
See:
{
\time 2/1
1~
1
}
As far as I understand TieColumn steps in and sets certain values, not
always the best ones.
To circumvent use in-chord Ties with direction-modifiers and throw
'positioning-done with value '():
{
\time 2/1
1
\once\override TieColumn.positioning-done = #'()
1
}
Now \shape is usable. Your example could be like:
\relative {
\set tieWaitForNote = ##t
\grace {
b8_~
f'_~
g-\shape #'((0 . 0.6) (0.25 . 0.8) (0.75 . 0.8) (1 . 0.6)) ^~
}
\once\override TieColumn.positioning-done = #'()
1
}
HTH,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
German translation (was Re: ANN: Frescobaldi 2.19.0)
Op Fri, 22 Apr 2016 14:45:41 +0600 Henning Hraban Ramm schreef: > I started working on the German translation (see attached), but can > proceed only next week. In case someone else is working on that, > please let me know - we can at least proofread each other. Thanks! > Did you consider using translation services like > translations.launchpad.net ? Not yet :) -- Wilbert Berendsen, musician ‣ mail: i...@wilbertberendsen.nl ‣ web: www.wilbertberendsen.nl ‣ phone: +31646122877 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Multi-measure rests and mark collisions ...
On Thu 28 Apr 2016 at 13:56:03 (+0100), Anthonys Lists wrote: > On 27/04/2016 01:04, Carl Sorensen wrote: > >On 4/26/16 3:56 PM, "Thomas Morley" wrote: > > > >>2016-04-26 2:21 GMT+02:00 Wols Lists : > >>>On 25/04/16 05:31, David Wright wrote: > (I still don't know what you're trying to accomplish > [...]) > > The problem here is the thread has drifted quite a lot. Sorry, > David, my previous email was a bit sarky, for which I apologise, but > as I said in my original email, this is my eternal bugbear, and you > touched a nerve ... Incidentally, I didn't notice this earlier, but > the house style I'm copying DOES put the tempo above the tune name > ... :-) Very odd. The attached shows what I would want. The dynamic is closest because it applies directly to me as the singer. The tempo comes next; it applies indirectly to me. I need warning of a change, but watching the conductor would be sufficient instead. In this particular case, the swing directive is also vital. The tune's information is given furthest away because it's not needed in performance. It could equally well be summarised on a contents page. Not shown here is some legal bumf at the foot of each page where a new tune happens to start (song copyright, arrangement copyright, rights administration and licencing). > >>>Copy "House Style", maybe? > >>>And the whole point of this entire thread has been about > >>>SAVING VERTICAL SPACE - it's just plain butt-ugly for markup to stack > >>>vertically when a slight shift sideways could save lines - plus there's > >>>the high price I put on page turns that could be saved by reclaiming > >>>that wasted space. > >> > >> > >>Anyway, you seem to want multiple texts applied to a the same BarLine. > >>These texts shouldn't be stacked vertically but horizontally, right? > >I think that the desired functionality is to allow markups to be loosely > >tied to notes, so that if possible, they can shift horizontally some > >amount instead of shifting vertically to avoid collisions. > > Yup. Because actually, a lot of markup doesn't actually belong to a > *note*. It belongs to a *phrase*. Which leads to the desire that, > not only should markup shift right or left to avoid a collision, it > should be able to push *music* out of the way. For example, I have a > bit of code similar to the following ... Perhaps the so-called spanners might help you here. You can even have dashed lines to show the extent of their significance. They're really set up for cresc etc, but can be customised. > R1 | \mark \default \tempo "Scherzando" R1*8 | \mark \default > > At present, the scherzando sits above both rehearsal marks. And if I > had another tempo at the second mark, I'd have colliding tempi which > doesn't make musical sense :-) If only the scherzando could say "I > apply to the next 8 bars. The 9th bar must come after I end". > > > >That is, there could potentially be a shift in both X and Y to avoid > >collisions, and the shift with the least badness is the one that is chosen > >-- perhaps it's one line up in Y and two lines left in X, or something > >similar. > > > >If we had some facility for doing such a movement, then it would be > >relatively straightforward to assign penalties for taking up more vertical > >space, along with penalties for moving horizontally away from the desired > >home point. And we'd choose the layout with the lowest penalty. Have you tried spreading the music to take up more room? I'm not going to bother to come up with an example as you usually just find something else to criticise about it. Searching on the term "newSpacingSection" should give you the idea. It changes the natural spacing of the notes so that the stretching effect becomes unnoticeable. > >But right now, as far as I know, we have no such facility. I believe that > >right now, we horizontally space the music elements to avoid collisions, > >and then we vertically shift the outside-staff grobs to avoid collisions, > >and then we space the skylined staves to achieve the desired spacing. And > >there's nothing in this algorithm that lets us simultaneously vertically > >AND horizontally shift the outside-staff grobs. > > > >Such a feature would be cool to add. But it's not trivial in any sense of > >the word, given the current LilyPond spacing architecture, as I understand > >it. > > > > > That's what I understood, too. Because the outside-staff grobs need > to make the music elements wider if appropriate, and coding that > sort of feedback loop is probably a nightmare! In fact, coding it AT > ALL seems to be a nightmare with the current state of lilypond. You > need some way of allocating a minumum width to a random fragment of > music (like above - I need those 8 bars to take a minumum width, but > while the current part is all rests, another part may be all notes, > so I can't even say "make this rest that wide" because next time > round it might not be a rest! > > And apologies if I am grumpy about this topic, bu
Re: writing text on the staff & using numbers in music functions
> > But I could not get it to move down onto the staff. As described in
> >
http://www.lilypond.org/doc/v2.19/Documentation/notation/formatting-text#text-alignment
> > "Vertical alignment is a bit more complex. As stated above, markup
objects
> > can be moved as a whole; however, it is also possible to move specific
elements
> > inside a markup block."
> >
> > It took me a while to realize this meant that the techniques using
> > raise, lower, translate, general-align and translate-scaled
> > will NOT affect the "markup object moved as a whole",
> > but rather affect the relative position of objects within the markup
object.
...
> Well, it's not true, see:
...
> Printing text in Staff depends of the settings for TextScript
>
> {
> \override TextScript.outside-staff-priority = #'()
> \override TextScript.staff-padding = #'()
> s1^\markup {
> \line { \circle "." "This is the anchor" }
> \translate #'(-25 . 0) \with-dimensions #empty-interval
> #empty-interval "xy"
> }
> }
That's great, thanks for demonstrating that.
Just curious, but how did you ever learn this?
It seems doubtful that one would have arrived at this insight using the
manuals.
Trying to find this info in the docs, the formatting-text page
http://lilypond.org/doc/v2.19/Documentation/learning/moving-objects
starts out with a link to the LM about moving objects.
But neither that page, nor the NR section about text alignment
http://www.lilypond.org/doc/v2.19/Documentation/notation/formatting-text#text-alignment
mentions the outside-staff-priority.
Searching for this property, it can be found in
Tweaking Output > Placement of Objects > Outside-staff objects
http://lilypond.org/doc/v2.19/Documentation/learning/outside_002dstaff-objects
But even here, there is no mention of how to get outside-staff objects
placed in the staff.
Of course, based on the naming convention "outside-staff objects", it seems
unlikely that you could place an outside-staff object within the staff.
So, maybe this is a silly discussion to begin with. However, since it is
possible, I wonder if it should be mentioned?
"Objects with the lower value of the outside-staff-priority property are
placed nearer to the staff, and other outside-staff objects are then raised
as far as necessary to avoid collisions. The outside-staff-priority is
defined in the grob-interface and so is a property of all layout objects.
By default it is set to #f for all within-staff objects, and to a numerical
value appropriate to each outside-staff object when the object is created."
If anything, one might guess that in order to get an outside staff object
placed in the staff, you would specify it's outside-staff-priority as "#f",
since the above quoted passase says that's the default for within-staff
objects.
Yet, the example you provide sets TextScript.outside-staff-priority to an
empty list. Is an empty list equivalent to "#f"?
Then there is the matter of staff-padding. The LM section on grob sizing
mentions it with respect to vertical alignment of dynamics and refers to
the section on Collisions of objects
http://lilypond.org/doc/v2.19/Documentation/learning/collisions-of-objects
Within there, it is described in the section on Moving Objects
http://lilypond.org/doc/v2.19/Documentation/learning/moving-objects
"staff-padding applies only to those objects which are always set outside
the staff – it controls the minimum distance from the staff to the
outside-staff object."
This also seems to imply that an outside-staff object cannot be set within
the staff.
If you read this literally--but keeping in mind that you've demonstrated
that it is possible to set text within the staff--it is saying that
staff-padding does not apply to text markup (since text markup is not
always set outside the staff.)
This would be more consistent if it said, "staff-padding applies only to
outside-staff objects – it controls the minimum distance from the staff to
the outside-staff object." In which case the discrepancy is only in the
naming convention, since an outside-staff object is not necessarily always
set outside the staff.
And in the section specifically on the staff-padding property:
"staff-padding can be used to align objects such as dynamics along a
baseline at a fixed distance from the staff, when no other notation forces
them further from the staff.""
Which is to say, it is unclear why and how this relates to setting text
within the staff.
So, it is not very clear where one would learn that both of these are
necessary:
\override TextScript.outside-staff-priority = #'()
\override TextScript.staff-padding = #'()
In any case, thanks for your help. What would I do without this list?
David Elaine Alt
415 . 341 .4954 "*Confusion is
highly underrated*"
ela...@flaminghakama.com
self-immolation.info
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re: Multi-measure rests and mark collisions ...
On Tue 26 Apr 2016 at 01:21:00 (+0100), Wols Lists wrote: > On 25/04/16 05:31, David Wright wrote: > > But I see you've now acknowledged (indirectly) that LP can set > > multiple marks at the same point after stating that it can't. > > Are there other things that LP can be persuaded to do itself that you > > have closed your mind to? > > > Except I *haven't* closed my mind. That's you putting words into my > mouth. The exact words were "The problem really is, all I want to do is stick multiple marks on a barline (which doesn't work, lily doesn't do multiple \mark's :-(," on Sat, 23 Apr 2016 11:25:05 +0100. Cheers, David. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Choice of pitch input mode
On 3 May 2016 at 04:53, David Wright wrote: > Perhaps composers don't sweat over individual notes like that and/or > don't need a decent looking copy in front of them. Some compose at the > piano, don't they. When I’m composing, I don’t want to have to deal with anything more technologically advanced than a pencil sharpener. If I used music software for composing I’d want instant playback, maybe MIDI-based? As far as transcribing, I adapted my own version of Finale’s Speedy Note Entry for note input, so there are rarely problems there. I’m more fluent reading \relative, so I guess I consider the occasional octave/duration issue while making small edits the price of being able to read more fluently. Vaughan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Horizontal Brackets and Markup Placement
Hi everyone,
In the attached MWE, I'm somehow having trouble getting the initial
`^\markup a` to be placed /above/ the horizontal bracket, even though
all future instances of this markup are placed above the bracket no
problem. It seems so simple; I feel a little silly just asking. The
commented out override does the trick, but it brings up some other
undesirable issues that I'd rather not deal with. Any tips would be great.
Thanks,
Sam
\version "2.19.40"
\language english
\layout {
\context {
\Voice
\consists "Horizontal_bracket_engraver"
}
}
\relative c'' {
\clef treble
\key g \major
\override HorizontalBracket.direction = #UP
\override Score.BarNumber #'break-align-symbols =
#'(staff-bar clef)
\override HorizontalBracket.outside-staff-priority = #1
% \override TextScript.avoid-slur = #'inside
g2\(\startGroup^\markup a g4. g8 | % this markup should be above the bracket
ef'2. d4 c2 g |
af1\)->\stopGroup |
g2\(\startGroup^\markup a' g4. g8 |
ef'2. d4 |
c2 af4. af8 |
bf1\)->~ |
bf2 r\stopGroup |
bf2.\startGroup^\markup b bf4 |
c2 c4. c8 |
df1~ |
df2 r\stopGroup |
}___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
