Re: hairpins default stop at barline
Am 14.06.2015 um 01:29 schrieb Gianmaria Lari:
First, I'm not a politician and I'm not here to win a war :) My suggestion is
just a suggestion that have to be analyzed and in case it brings more
benefits than disavantages it should be considered; if an expert explains me
it is not advantageous I will not cry and I will be glad having learnt
something new.
Now regarding the issue, I suspect I have not been clear.
Attached is the snapshot of Pratch study #11
http://lilypond.1069038.n5.nabble.com/file/n177817/Capture.png
As you can see in the snapshot, hairpin begin on 'd8' and end on f4.
Could you please confirm me that in music language this means crescendo ends
on 'f4.' (d8' has the lower intensity and 'f4' the higher)
Well, very strictly I would interpret this crescendo to end even
somewhat after the downbeat. However, one can also see that the drawing
is somewhat sloppy, so yes, I can confirm that. As a sidenote: You’ll
find that there are many music publications with typographical errors in
them, even most annoying ones, and often it’s better to follow that
which Lilypond does.
And if this is the case, why this code
d4. e8\ (fis8 g8)
a4. b8 (a8 g8)
fis4\! a8 (fis8 d8)
does not work as written and I have to add 'override Hair.?
It does work as written, only there are two major conventions on how to
represent a crescendo which ends on the beat directly after a barline.
Lilypond follows that which ends the hairpin before the barline, but
nevertheless is meaning the same: a crescendo until the following beat.
And because the other convention (continuing the hairpin up to the note
after the barline) is quite widely used and much preferable in some
cases, a _very simple_ way to change the behaviour was introduced. Note
that you need the override only once, if you want it in every instance; even
\layout {
\context {
\Voice
\override Hairpin.to-barline = ##f
}
}
will then make sense. Or, if it’s only for specific instances, you can
use { ceses128-\tweak to-barline ##f \ }, or store the tweak and \ in
a variable like
hairpinLong = -\tweak to-barline ##f \
Now, that’s a bouquet to choose from!
Yours, Simon
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: hairpins default stop at barline
First, I'm not a politician and I'm not here to win a war :) My suggestion is just a suggestion that have to be analyzed and in case it brings more benefits than disavantages it should be considered; if an expert explains me it is not advantageous I will not cry and I will be glad having learnt something new. Now regarding the issue, I suspect I have not been clear. Attached is the snapshot of Pratch study #11 http://lilypond.1069038.n5.nabble.com/file/n177817/Capture.png As you can see in the snapshot, hairpin begin on 'd8' and end on f4. Could you please confirm me that in music language this means crescendo ends on 'f4.' (d8' has the lower intensity and 'f4' the higher) And if this is the case, why this code d4. e8\ (fis8 g8) a4. b8 (a8 g8) fis4\! a8 (fis8 d8) does not work as written and I have to add 'override Hair.? My apologies if I don't understand something and thank you for your explications. P.S. Brian Barker reply about this subject on the mailing list (and CC to my personal email) but his message never shows on the ML. Why? -- View this message in context: http://lilypond.1069038.n5.nabble.com/hairpins-default-stop-at-barline-tp177538p177817.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: \dim and avoid-slur
Hello Trevor,
I stand corrected. And thanks for spelling out that explanation :-) I
haven’t been thorough enough looking it up myself – or rather
overestimated my knowledge of the docs, which is unfortunate after some
four years of learning. Sigh… On the other hand: I have rarely, if ever,
come across issues of this kind, so I’ve been moving in a region I
didn’t know as well as others.
In this particular case, confusion was increased by forgetting to tweak
DynamicLineSpanner’s outside-staff-priority along with that of
DynamicText. And I just noticed that, with outside-staff-priority being
unset for both (or rather, all three), avoid-slur doesn’t have the
desired effect, they will just collide (see attachment). But that would
be a different issue.
Good night,
Simon
Am 13.06.2015 um 23:45 schrieb Trevor Daniels:
Simon Albrecht wrote Saturday, June 13, 2015 8:53 PM
Am 13.06.2015 um 15:17 schrieb Trevor Daniels:
Simon Albrecht wrote Saturday, June 13, 2015 2:00 PM
Weird, but it works and is definitely preferable over extra-offset.
Does anybody have an explanation? I couldn’t find the table with default
values for outside-staff-priority. They don’t seem to be referenced in
the IR, are they?
Try the Learning Manual:
http://www.lilypond.org/doc/v2.19/Documentation/learning/outside_002dstaff-objects
Thanks for the hint, that helps. But it is not comprehensive, is it?
No, it isn't. It's not intended to be comprehensive; it's intended to teach
you how to find out things for yourself. Which you have, because
you say:
For
example I know that Slur also uses the outside-staff-interface, but
there is no outside-staff-priority referenced in the LM.
That's because by default its value is not set. If you read the description
in the outside-staff-interface you'll see that it says:
If set, the grob is positioned outside the staff in such a way as to avoid all
collisions
To find out if it has a value you look for outside-staff-priority under the Slur
layout object, and find it is not listed, so its value is not set. By setting
it,
you change its behaviour wrt collisions.
Actually, if you read a little further through the section of the Learning
Manual,
which I helpfully suggested to you earlier, you'll find:
Slurs by default are classed as within-staff objects, but they often appear above
the staff if the notes to which they are attached are high on the staff. This can push
outside-staff objects such as articulations too high, as the slur will be placed first.
The avoid-slur property of the articulation can be set to 'inside to bring the
articulation inside the slur, but the avoid-slur property is effective only if the
outside-staff-priority is also set to #f. Alternatively, the outside-staff-priority of
the slur can be set to a numerical value to cause it to be placed along with other
outside-staff objects according to that value.
Followed by an example showing exactly how to do it.
It would seem
proper if all properties and their default values were to be found in
the Internals…
They are. You just have to read the manuals and learn how to extract them.
Trevor
\version 2.19.20
\score {
\new Voice {
{ d''1
%-\tweak outside-staff-priority #0
(
}
{ s2 s
-\tweak style #'none
-\tweak avoid-slur #'inside
-\tweak outside-staff-priority ##f
-\tweak DynamicLineSpanner.outside-staff-priority ##f
^\dim
}
es''4)\!
}
\new Voice {
8 8 8 8 8 8 8 8
4
}
}
dim-avoid-slur.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Assertion failed!
On 2015-06-13 07:54 PM, Keith OHara wrote: Colin Campbell cpkc at shaw.ca writes: Under the assumption that the changed assertion handling is exposing previously non-fatal bugs, I propose to create separate issues for the 3 items now known: Daniel's two and another reported by Andrew Barnard. Colin would you let met add the three issues. I can minimize the examples fairly effectively, knowing what to expect from reviewing Daivd's patch. We'll likely be working together to figure out which operating system shows each problem; as I'm windows only at the moment. By all means, Keith, and many thanks for *all* your contributions to LilyPond! Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: hairpins default stop at barline
Hi Gianmaria, Could you please confirm me that in music language this means crescendo ends on 'f4.' (d8' has the lower intensity and 'f4' the higher) The second part of your statement is correct: the notation implies that d should have a lower intensity/volume, and the f a higher intensity/volume. However, it is very hard to tell, from the imprecise engraving, whether the crescendo should end at the moment the note begins, or sometime after that (i.e., during the duration of the note itself). That ambiguity is precisely the reason that many engravers — and most acknowledged experts on notation (such as Elaine Gould) — recommend ending the hairpin at [or, actually, just before] the barline. Hopefully that explains why Lilypond’s default is set the way it is. Regards, Kieren. 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: Assertion failed!
Colin Campbell cpkc at shaw.ca writes: Under the assumption that the changed assertion handling is exposing previously non-fatal bugs, I propose to create separate issues for the 3 items now known: Daniel's two and another reported by Andrew Barnard. Colin would you let met add the three issues. I can minimize the examples fairly effectively, knowing what to expect from reviewing Daivd's patch. We'll likely be working together to figure out which operating system shows each problem; as I'm windows only at the moment. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \dim and avoid-slur
Simon Albrecht wrote Saturday, June 13, 2015 2:00 PM Weird, but it works and is definitely preferable over extra-offset. Does anybody have an explanation? I couldn’t find the table with default values for outside-staff-priority. They don’t seem to be referenced in the IR, are they? Try the Learning Manual: http://www.lilypond.org/doc/v2.19/Documentation/learning/outside_002dstaff-objects Trevor ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tremolo confusion
Simon Albrecht simon.albre...@mail.de writes: Am 13.06.2015 um 11:59 schrieb Damian leGassick: I do know about the accidental style - I'm revising a file that I started back in 2007 (when I was just starting with Lilypond) And in the EU, Webern will enter public domain on 1st January 2016 :-) Unless some term in a secret trade agreement intervenes. Possibly even retroactively. There's precendent for retroactive retraction of the public domain in the EU. Puccini, I think, was in the public domain in Italy and got back into copyright via copyright extension in the EU. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: hairpins default stop at barline
Hi Gianmaria,
Does people really use this features? I mean does it happen
frequently people set '\!' in a certain location expecting Lilypond render
it at the bar line immediately preceding if the note which ends a hairpin
falls on a downbeat?
Yes. I would estimate that 95% of the time, I use the default behaviour (i.e.,
stopping at the barline), as is also recommended by all respected notation
guides (e.g., Gould). In the remaining 5% of cases, I manually tweak the
behaviour.
Another good reason to change would be if new users (like me)
periodically pop up asking help about the hairpin position.
You’re the only one I remember asking about it in recent years.
If you want to change this — or any other default — for your scores, I would
recommend creating a file (named “Lilypond.ily”, or “default_override.ily”, or
similar), which you simply \include in all scores using (e.g.)
\include “Lilypond.ily”
In that file, you can put things like
\layout {
\context {
\Score
\override Hairpin.to-barline = ##f
}
}
and your scores will behave as you wish them to.
Hope this helps!
Kieren.
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: \dim and avoid-slur
Am 13.06.2015 um 02:57 schrieb David Kastrup: Simon Albrecht simon.albre...@mail.de writes: Hello, I need help with the attached situation: the dim. should go inside the slur, but the avoid-slur tweak is ignored and it appears above. How to fix that? Thanks in advance, Simon I have no idea what I'm doing here and there appears to be no significance to the actual value at all. Weird, but it works and is definitely preferable over extra-offset. Does anybody have an explanation? I couldn’t find the table with default values for outside-staff-priority. They don’t seem to be referenced in the IR, are they? Thank you, Simon ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
RE: Assertion failed!
Hi Daniel,
That's another assertion failure on top of the one I have been reporting in
2.19.21. Can you please submit a bug report, given you have an example that
produces the error?
Something seems to be a bit broken in 2.19.21 compared to 2.19.20.Iif I had
the knowledge, I would jump in and fix it, but it's too early for me as yet,
not being familiar with the internals.
Can you see if this works in 2.19.20? [Based on my hypothesis that 2.19.21
has regressed something, or introduced a bunch of defects.]
Andrew
-Original Message-
From: lilypond-user-bounces+andrew.bernard=gmail@gnu.org
[mailto:lilypond-user-bounces+andrew.bernard=gmail@gnu.org] On Behalf Of
Daniel Rosen
Sent: Saturday, 13 June 2015 1:10 AM
To: lilypond-user Mailing List (lilypond-user@gnu.org)
Subject: Assertion failed!
Hello all,
When I try to attach a balloon to a whole note, like this:
%%% Snippet begins
\version 2.19.21
\new Voice \with { \consists Balloon_engraver } {
\balloonGrobText #'Stem #'(3 . 3) \markup { I'm a Stem }
g1
}
%%% Snippet ends
I get the attached pop-up window.
Is this an issue on my end, or is it a bug?
DR
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Assertion failed!
Andrew Bernard andrew.bern...@gmail.com writes: Hi Daniel, That's another assertion failure on top of the one I have been reporting in 2.19.21. Can you please submit a bug report, given you have an example that produces the error? Something seems to be a bit broken in 2.19.21 compared to 2.19.20.Iif I had the knowledge, I would jump in and fix it, but it's too early for me as yet, not being familiar with the internals. Can you see if this works in 2.19.20? [Based on my hypothesis that 2.19.21 has regressed something, or introduced a bunch of defects.] More likely than not it is URL:https://code.google.com/p/lilypond/issues/detail?id=2787, Issue 2787: Sanitize usage of -DDEBUG, -DNDEBUG, assert, programming_error and so on that is making the difference for you here. assert is a programmer's way to indicate that the failure of the assertion is something that the program is unable to deal with. Consequently, a failed assertion aborts the program rather than continuing and likely crashing in unpredictable ways. Now assertion checks previously to this issue were only enabled on debugging builds, so only developers would have gotten to see them in versions compiled for testing. But it would appear that some cases of assert are perfectly capable of continuing gracefully, so that's more a case for the diagnostic programming error which reports conditions that should not be occuring but that are not fatal. They still deserve investigation but aborting the program for them would appear to be overkill as it seems unlikely they would cause operations to completely derail. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
RE: Assertion failed!
-Original Message- From: David Kastrup [mailto:d...@gnu.org] Sent: Saturday, June 13, 2015 5:23 AM To: Andrew Bernard Cc: Daniel Rosen; lilypond-user@gnu.org Subject: Re: Assertion failed! Andrew Bernard andrew.bern...@gmail.com writes: Hi David, The one I have reported dumps core. So pretty much a fatal error. Assertion failures always dump core. The idea is that they dump core at a point of time where one is still reasonably close to the problem rather than at some arbitrary point later. A core dump can be used for analyzing the state of the program at the point of the core dump. But it is good to know the program behaviour has been altered and that accounts for why we are suddenly seeing assertion failures when they occur. The difference is just that the production version of LilyPond no longer ignores assertions and just crosses fingers. Some assertions might warrant converting into programming errors, some assertions might warrant finding the cause and either fixing it or putting up some sensible continuation strategy. At any rate, the failed assertions will not go away by themselves: making suitable small examples and reporting them on the bug reporting list will give developers a chance to look at them as they occur. -- David Kastrup Would it still be helpful for me to submit a bug report, or have you now identified an existing issue as the culprit? DR ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Assertion failed!
Daniel Rosen drose...@gmail.com writes: -Original Message- From: David Kastrup [mailto:d...@gnu.org] Sent: Saturday, June 13, 2015 5:23 AM To: Andrew Bernard Cc: Daniel Rosen; lilypond-user@gnu.org Subject: Re: Assertion failed! Andrew Bernard andrew.bern...@gmail.com writes: Hi David, The one I have reported dumps core. So pretty much a fatal error. Assertion failures always dump core. The idea is that they dump core at a point of time where one is still reasonably close to the problem rather than at some arbitrary point later. A core dump can be used for analyzing the state of the program at the point of the core dump. But it is good to know the program behaviour has been altered and that accounts for why we are suddenly seeing assertion failures when they occur. The difference is just that the production version of LilyPond no longer ignores assertions and just crosses fingers. Some assertions might warrant converting into programming errors, some assertions might warrant finding the cause and either fixing it or putting up some sensible continuation strategy. At any rate, the failed assertions will not go away by themselves: making suitable small examples and reporting them on the bug reporting list will give developers a chance to look at them as they occur. Would it still be helpful for me to submit a bug report, or have you now identified an existing issue as the culprit? I haven't. That code is not my area of expertise. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Assertion failed!
On 2015-06-13 10:52 AM, David Kastrup wrote: Daniel Rosen drose...@gmail.com writes: -Original Message- From: David Kastrup [mailto:d...@gnu.org] Sent: Saturday, June 13, 2015 5:23 AM To: Andrew Bernard Cc: Daniel Rosen; lilypond-user@gnu.org Subject: Re: Assertion failed! Andrew Bernard andrew.bern...@gmail.com writes: Hi David, The one I have reported dumps core. So pretty much a fatal error. Assertion failures always dump core. The idea is that they dump core at a point of time where one is still reasonably close to the problem rather than at some arbitrary point later. A core dump can be used for analyzing the state of the program at the point of the core dump. But it is good to know the program behaviour has been altered and that accounts for why we are suddenly seeing assertion failures when they occur. The difference is just that the production version of LilyPond no longer ignores assertions and just crosses fingers. Some assertions might warrant converting into programming errors, some assertions might warrant finding the cause and either fixing it or putting up some sensible continuation strategy. At any rate, the failed assertions will not go away by themselves: making suitable small examples and reporting them on the bug reporting list will give developers a chance to look at them as they occur. Would it still be helpful for me to submit a bug report, or have you now identified an existing issue as the culprit? I haven't. That code is not my area of expertise. Under the assumption that the changed assertion handling is exposing previously non-fatal bugs, I propose to create separate issues for the 3 items now known: Daniel's two and another reported by Andrew Barnard. Given David K's comments, this seems preferabvle to updating Issue 2787. Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Control which voice if shifted left
Hello LilyPonders,
I have a piece where I want the lower right-hand voice to be shifted left
whenever the chord is too crowded, but instead the default is for it to be
shifted right. The snippet below shows how I could use force-hshift on the
notes I want shifted; the second measure is the default.
The piece is fairly short so I can put in all the hshifts by hand but I'm
wondering if there is a way to tell the voice, Just left shift instead of
right shift.
\version 2.19.21
\language english
forceHShift = \once \override NoteColumn.force-hshift = -1.75
highVoice = \relative {
s4 b d8 ( cs e ds fs4 ) |
s4 b d?8 ( cs e ds fs4 ) |
}
upperMiddle = \relative {
s4 \forceHShift a8 as \forceHShift c4 |
s4 a?8 as c4 |
}
lowerMiddle = \relative {
s2. * 2 |
}
lowVoice = \relative {
g2- r4 |
g2- r4 |
}
global = {
\key c \major
\time 3/4
}
upper = {
\global
\clef treble
\new Voice { \voiceOne \highVoice }
\new Voice { \voiceTwo \upperMiddle }
}
lower = {
\global
\clef bass
\new Voice { \voiceThree \lowerMiddle }
\new Voice { \voiceFour \lowVoice }
}
\score {
\new PianoStaff
\new Staff = upper \upper
\new Staff = lower \lower
\layout {
\context {
\Score
\hide BarLine
\hide SpanBar
}
\context {
\Staff
\remove Time_signature_engraver
}
}
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tremolo confusion
Am 13.06.2015 um 11:59 schrieb Damian leGassick: I do know about the accidental style - I'm revising a file that I started back in 2007 (when I was just starting with Lilypond) And in the EU, Webern will enter public domain on 1st January 2016 :-) Best regards, Simon ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Assertion failed!
Hi David, The one I have reported dumps core. So pretty much a fatal error. But it is good to know the program behaviour has been altered and that accounts for why we are suddenly seeing assertion failures when they occur. Andrew On 13/06/2015 18:04, David Kastrup d...@gnu.org wrote: Andrew Bernard andrew.bern...@gmail.com writes: Hi Daniel, That's another assertion failure on top of the one I have been reporting in 2.19.21. Can you please submit a bug report, given you have an example that produces the error? Something seems to be a bit broken in 2.19.21 compared to 2.19.20.Iif I had the knowledge, I would jump in and fix it, but it's too early for me as yet, not being familiar with the internals. Can you see if this works in 2.19.20? [Based on my hypothesis that 2.19.21 has regressed something, or introduced a bunch of defects.] More likely than not it is URL:https://code.google.com/p/lilypond/issues/detail?id=2787, Issue 2787: Sanitize usage of -DDEBUG, -DNDEBUG, assert, programming_error and so on that is making the difference for you here. assert is a programmer's way to indicate that the failure of the assertion is something that the program is unable to deal with. Consequently, a failed assertion aborts the program rather than continuing and likely crashing in unpredictable ways. Now assertion checks previously to this issue were only enabled on debugging builds, so only developers would have gotten to see them in versions compiled for testing. But it would appear that some cases of assert are perfectly capable of continuing gracefully, so that's more a case for the diagnostic programming error which reports conditions that should not be occuring but that are not fatal. They still deserve investigation but aborting the program for them would appear to be overkill as it seems unlikely they would cause operations to completely derail. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Assertion failed!
Andrew Bernard andrew.bern...@gmail.com writes: Hi David, The one I have reported dumps core. So pretty much a fatal error. Assertion failures always dump core. The idea is that they dump core at a point of time where one is still reasonably close to the problem rather than at some arbitrary point later. A core dump can be used for analyzing the state of the program at the point of the core dump. But it is good to know the program behaviour has been altered and that accounts for why we are suddenly seeing assertion failures when they occur. The difference is just that the production version of LilyPond no longer ignores assertions and just crosses fingers. Some assertions might warrant converting into programming errors, some assertions might warrant finding the cause and either fixing it or putting up some sensible continuation strategy. At any rate, the failed assertions will not go away by themselves: making suitable small examples and reporting them on the bug reporting list will give developers a chance to look at them as they occur. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tremolo confusion
On 12 Jun 2015, at 14:57, Simon Albrecht wrote:
Hello Damian,
Am 12.06.2015 um 11:15 schrieb Damian leGassick:
\version 2.18.2
{
\time 3/4
r4 \repeat tremolo 4 { e'''!64 c'''! } r4.
r4 \repeat tremolo 8 { e'''!64 c'''! } r4
}
You might be interested in \accidentalStyle dodecaphonic – unless of course
you already know it…
Cheers, Simon
thanks Simon
I do know about the accidental style - I'm revising a file that I started back
in 2007 (when I was just starting with Lilypond)
cheers
Damian
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
RE: Assertion failed!
-Original Message-
From: Andrew Bernard [mailto:andrew.bern...@gmail.com]
Sent: Saturday, June 13, 2015 3:49 AM
To: Daniel Rosen; lilypond-user@gnu.org
Subject: RE: Assertion failed!
Can you see if this works in 2.19.20? [Based on my hypothesis that 2.19.21
has regressed something, or introduced a bunch of defects.]
Using 2.19.20, I compiled
\version 2.19.20
\new Voice \with { \consists Balloon_engraver } {
\balloonGrobText #'Stem #'(3 . 3) \markup { I'm a Stem }
g1
}
While I no longer get the dialog I reported originally, I do get the attached
PDF output, which is equally problematic.
I'll go ahead and create a bug report.
DR
document.pdf
Description: document.pdf
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
MMA using lilypond syntax/style
Hi guys.. The other day i was trying to practice jazz improvisation on linux. I was searching for a simple/fast working software that would help me practice. I found about MMA and it is cool - text based, midi output/export but it wasn't so clean regarding musicly writing speaking. So i had this tought. Lilypond has a great syntax and has also midi output/export. Has somebody tried doing something with it? I onced tried to write a complete pop song with lilypond and I was literally sweating. Idea behind the MMA is great. When you write a groove you define the drum parts, groove. And then you say use this groove. For example: use 44 Tempo 120 Groove Main 1 Gsus/C G/B 2 Gm/Bb Ab 3 C/E Eb Groove Fill 4 Cm Dm G@2.5 Has someone use a combination of variables and scheme to do such a thing? What do you think about the idea? Stef ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \dim and avoid-slur
Am 13.06.2015 um 15:17 schrieb Trevor Daniels: Simon Albrecht wrote Saturday, June 13, 2015 2:00 PM Weird, but it works and is definitely preferable over extra-offset. Does anybody have an explanation? I couldn’t find the table with default values for outside-staff-priority. They don’t seem to be referenced in the IR, are they? Try the Learning Manual: http://www.lilypond.org/doc/v2.19/Documentation/learning/outside_002dstaff-objects Thanks for the hint, that helps. But it is not comprehensive, is it? For example I know that Slur also uses the outside-staff-interface, but there is no outside-staff-priority referenced in the LM. It would seem proper if all properties and their default values were to be found in the Internals… Yours, Simon ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MMA using lilypond syntax/style
2015-06-13 21:07 GMT+02:00 Stjepan Horvat zvanste...@gmail.com: Hi guys.. The other day i was trying to practice jazz improvisation on linux. I was searching for a simple/fast working software that would help me practice. I found about MMA and it is cool - text based, midi output/export Well, google-search for MMA offered at top: https://en.wikipedia.org/wiki/Mixed_martial_arts I'm somehow pretty sure you mean something different. So far I've not the slightest idea what you're talking about. ;) Have a link? Cheers, Harm but it wasn't so clean regarding musicly writing speaking. So i had this tought. Lilypond has a great syntax and has also midi output/export. Has somebody tried doing something with it? I onced tried to write a complete pop song with lilypond and I was literally sweating. Idea behind the MMA is great. When you write a groove you define the drum parts, groove. And then you say use this groove. For example: use 44 Tempo 120 Groove Main 1 Gsus/C G/B 2 Gm/Bb Ab 3 C/E Eb Groove Fill 4 Cm Dm G@2.5 Has someone use a combination of variables and scheme to do such a thing? What do you think about the idea? Stef ___ 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: MMA using lilypond syntax/style
On Sat, 13 Jun 2015, Martin Tarenskeen wrote: Have a link? http://www.mellowood.ca/mma/ A quote from that website: If you are confused by the acronym MMA and were looking for the the MIDI Manufacturers Association (MMA) please visit http://www.midi.org. On the other hand, if you were completely confused and were looking for the Mixed Martial Arts folk, try http://www.mmafighting.com/. We did think about calling our program by some different names, but they all share letters with other things. And, please remember, our program is called MMA - Musical MIDI Accompaniement, not MMA. -- MT ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tremolo confusion
Am 13.06.2015 um 15:50 schrieb David Kastrup: Simon Albrecht simon.albre...@mail.de writes: Am 13.06.2015 um 11:59 schrieb Damian leGassick: I do know about the accidental style - I'm revising a file that I started back in 2007 (when I was just starting with Lilypond) And in the EU, Webern will enter public domain on 1st January 2016 :-) Unless some term in a secret trade agreement intervenes. Good point, darn! Another item to the long list of reasons for protesting against TTIP. Let’s hope for the best ( – or avoiding the worst?). Best regards, Simon ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MMA using lilypond syntax/style
At 21:58 13/06/2015 +0200, Martin Tarenskeen wrote: A quote from that website [http://www.mellowood.ca/mma/]: And, please remember, our program is called MMA - Musical MIDI Accompaniement, not MMA. So its full name would be Musical Musical Instrument Digital Interface Accompaniment - Musical Musical Instrument Digital Interface Accompaniment? (Oh, and they do call it MMA far more often than anything else!) Brian Barker ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \dim and avoid-slur
Simon Albrecht wrote Saturday, June 13, 2015 8:53 PM Am 13.06.2015 um 15:17 schrieb Trevor Daniels: Simon Albrecht wrote Saturday, June 13, 2015 2:00 PM Weird, but it works and is definitely preferable over extra-offset. Does anybody have an explanation? I couldn’t find the table with default values for outside-staff-priority. They don’t seem to be referenced in the IR, are they? Try the Learning Manual: http://www.lilypond.org/doc/v2.19/Documentation/learning/outside_002dstaff-objects Thanks for the hint, that helps. But it is not comprehensive, is it? No, it isn't. It's not intended to be comprehensive; it's intended to teach you how to find out things for yourself. Which you have, because you say: For example I know that Slur also uses the outside-staff-interface, but there is no outside-staff-priority referenced in the LM. That's because by default its value is not set. If you read the description in the outside-staff-interface you'll see that it says: If set, the grob is positioned outside the staff in such a way as to avoid all collisions To find out if it has a value you look for outside-staff-priority under the Slur layout object, and find it is not listed, so its value is not set. By setting it, you change its behaviour wrt collisions. Actually, if you read a little further through the section of the Learning Manual, which I helpfully suggested to you earlier, you'll find: Slurs by default are classed as within-staff objects, but they often appear above the staff if the notes to which they are attached are high on the staff. This can push outside-staff objects such as articulations too high, as the slur will be placed first. The avoid-slur property of the articulation can be set to 'inside to bring the articulation inside the slur, but the avoid-slur property is effective only if the outside-staff-priority is also set to #f. Alternatively, the outside-staff-priority of the slur can be set to a numerical value to cause it to be placed along with other outside-staff objects according to that value. Followed by an example showing exactly how to do it. It would seem proper if all properties and their default values were to be found in the Internals… They are. You just have to read the manuals and learn how to extract them. Trevor ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
