Re: [OT] sorry for the spam
On 2016-05-11 10:41, Chris Yate wrote: > There's no point having passwords that you can't remember; In fact, there is: no one can force you to divulge a password that you don't know. Which is why I have started using Keepass with a Yubikey. The Yubikey contains a password that I certainly don't know. It unlocks the password database kept by Keepass. Obviously, not all passwords require such security (such as the password for a music-engraving mailing list), but there is a point having passwords that you not only don't remember but in fact never knew. Cheers, Stephan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond error behaviour
On 2016-04-19 17:54, Tim Reeves wrote:
> Maybe they should be called "mortally-wounding" errors? :)
This is an excellent suggestion. Perhaps we could implement that further
output from Lilypond becomes more and more incoherent as the poison sets
in? And finally, the pain is too much to bear and Lilypond gives up.
Something like this:
$ lilypond playground/error.ly
GNU LilyPond 2.19.37
Processing `/tmp/lyp/wrappers/error.ly'
Happily parsing...
/Users/sharon/playground/error.ly:1:3: aargh! they got me, the bastards!
/Users/sharon/playground/error.ly:1:3 error: unrecognized string, not in
text script or \lyricmode
{
bork }
/tmp/lyp/wrappers/error.ly:1: warning: no ... \version ... statement
found, please ... oh god, do I have to go through with this?
/tmp/lyp/wrappers/error.ly:1: dammit, add
\version "2.19.37"
for future compa... ti... bility
Interpreting ... music... though ... it's ... hard ...
Ah crap, I've had it. Tell George he can keep the horse.
Fly, you fools!
$
Fun,
Stephan
--
GPG key ID 4BDA81D3
fingerprint 5F88 399F 8811 72BE B36A FC93 4D13 FCB2 4BDA 81D3
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond error behaviour
On 2016-04-18 20:29, David Wright wrote: That begs the question. How do you define "clearly malformed input." If it is malformed, it can't be clear. Of course, if you mean "clearly-malformed", then I contest this vehemently. I think I was precise enough. But I must say that I don't feel comfortable with the tone of this discussion, so I will, with respect, bow out of it. Fun, Stephan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond error behaviour
On 2016-04-17 13:51, Urs Liska wrote: Am 17.04.2016 um 04:29 schrieb David Wright: I think a better analogy than compilers writing programs would be browsers rendering web pages. Can you imagine a WWW where malformed pages produced a few error messages on the screen and nothing else? No, we expect the browser to make its best attempt at a partial rendition. So please leave LP alone and write a better server. Yes, it might be nice if LP had an indication of severity level, but my preference would be for improvements in LP's primary goals. I think the browser is indeed a good analogy. If we have malformed HTML or even worse issues like e.g. a failed CSS include, then yes, we expect the browser to render as much and as nice as possible. But what LilyPond currently does is displaying a big modal over the page saying "I'm sorry but I couldn't render the page due to a fatal error. Please click here to close this message and view the page." Coming at this discussion rather late, and also from a totally different angle, I'd like to make the (slightly off-topic) point that I don't think that it's a good idea to make it a design principle that Lilypond should try to render even clearly malformed input. (Note that I'm not saying that it is a happy coincidence that Lilypond does, in fact, do this. It's great for debugging, as I can attest. All I'm saying is that it would be a bad idea for users to rely on this behaviour, and for Lilypond developers to embrace it as a design principle.) We have seen in HTML how malformed input quickly becomes the norm and how browser vendors are unable to back out of supporting it. (Just try to validate almost any web page that claims to be HTML 4.01 and you'll see what I mean.) The result is that render engines are much slower and much buggier than they need to be, because they have tons of exceptions for stuff that isn't really HTML but where the blame would ultimately fall on the browser if it didn't render properly. (I'm not saying that I advocate browsers refusing to render something that is almost, but not quite, entirely unlike HTML. I'm just saying that once you go down that rabbit hole, you won't come back up in a hurry.) Personally, I like the idea of Lilypond clearly saying to the user that there is something wrong with the input file. If that "modal dialog" went away, users would simply look at the output file and conclude that their input must have been OK. Having a clear and unambiguous message (even if there is debate about the use of the word "fatal") that _there is something wrong with the input file_ frees Lilypond developers to extend and otherwise develop Lilypond without the burden of having to support wrong but entrenched usage. Fun, Stephan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: accidentals for just intonation
On 2015-12-01 11:27, David Kastrup wrote: [...] Which explains why my default manner of tuning a guitar, namely just tuning each string to sound as I think it should in relation to the sequence of previous strings, has a good chance to end up more playable than the followup work of a "serious" guitar player believing in tuning by using harmonics. This may be off-topic, but this is *exactly* how I do it. For a while I was worried that this might be too slapdash, but then I thought, "if it sounds good, who am I to argue?" :-) Fun, Stephan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Markup for repeated notes or phrases
On 2015-11-09 19:40, David Kastrup (and Simon Albrecht) wrote:
> Stephan Neuhaus <s...@artdecode.de> writes: [...]
Thanks, both solutions work like a charm!
Now another thing, in the same context. Let's say I have
pattern = { 8 8 }
\relative c' { \repeat unfold 4 \pattern }
And let's say I want to add fingering instructions, but only to the
first , as if I had written
\relative c' { 8 8 8 8 8 8 8
8 }
Can I do something similar?
Thanks in advance,
Stephan
--
GPG key ID 4BDA81D3
fingerprint 5F88 399F 8811 72BE B36A FC93 4D13 FCB2 4BDA 81D3
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Markup for repeated notes or phrases
Dear list,
I have a piece that contains phrases that are repeated often. For
example, let us assume that the phrase consists of two sixteenth notes.
In the piece in question, the unit of repetition is in fact much longer;
this is just an example. So I have done this:
phrase = { c16 d16 }
\relative c' { \repeat unfold 8 \phrase }
But the composer has sometimes put expressive marks on some of the notes
in the phrase, some of the time. For example:
\relative c' { c16 d c d c d c d\staccato c d c d c d c d }
Obviously I could do
\relative c' {
\repeat unfold 3 \phrase
c d\staccato
\repeat unfold 4 \phrase
}
But this obscures the fact that the "c d\staccato" is the same as
"\phrase", just with expression markings added. (When the unit of
repetition is several bars long, this is not as obvious as in this
simplified example.)
Is there an elegant way to keep the structure visible, and yet to add
markings to selected parts of \phrase?
Thanks in advance,
Stephan
--
GPG key ID 4BDA81D3
fingerprint 5F88 399F 8811 72BE B36A FC93 4D13 FCB2 4BDA 81D3
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 2.19.30 returns error code -1073741819
On 2015-11-01 11:18, Nick Payne wrote:
> On 01/11/2015 18:02, Brian Guo wrote:
>> Hi,
>>
>> I have just installed LilyPond version 2.19.30 on a Windows 10 (64
>> bit) laptop, b
>> laptop, but when I try to compile a simple score, such as:
>> \version "2.19.30"
>> \score {
>>\new Staff \relative c' {
>> c
>>}
>> }
>
> Have you tried an uninstall/reinstall of 2.19.30?
If it's an access control problem, I would rather guess that either the
output file already exists and isn't writeable, or perhaps it's a directory.
Best,
Stephan
--
GPG key ID 4BDA81D3
fingerprint 5F88 399F 8811 72BE B36A FC93 4D13 FCB2 4BDA 81D3
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
