Re: Tuplet number direction
Simon Albrecht writes: > On 15.04.2016 00:51, Thomas Morley wrote: >> (1) The TupletNumbers are always inside the bow, I coded no >> possibility to print the Number cutting the bow. >> I maybe add it later. >> (2) What to do at line-break? > > Wouldn’t it better do disallow line-breaks during tuplets > (i.e. \override TupletBracket.breakable = ##f – if that has an > effect), or at least ignore such situations for this particular style? > Clearly, there are situations where it would be better or even > necessary to break tuplets, but I don’t think such situations occur > before 1900, Josquin des Prez? I've sung some Missa from him with wildly augmented triplets crossing a number of bars. Timing them accurately took some math because at that speed there was no natural flow any more really. That would be early 16th century. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tuplet number direction
- Original Message - From: "David Kastrup" To: "Simon Albrecht" Cc: "Thomas Morley" ; Sent: Friday, April 15, 2016 8:04 AM Subject: Re: Tuplet number direction Simon Albrecht writes: On 15.04.2016 00:51, Thomas Morley wrote: (1) The TupletNumbers are always inside the bow, I coded no possibility to print the Number cutting the bow. I maybe add it later. (2) What to do at line-break? Wouldn’t it better do disallow line-breaks during tuplets (i.e. \override TupletBracket.breakable = ##f – if that has an effect), or at least ignore such situations for this particular style? Clearly, there are situations where it would be better or even necessary to break tuplets, but I don’t think such situations occur before 1900, Josquin des Prez? I've sung some Missa from him with wildly augmented triplets crossing a number of bars. Timing them accurately took some math because at that speed there was no natural flow any more really. That would be early 16th century. -- David Kastrup Wouldn't have been notated like that in those days - they would have used coloratio. So to notate it for singers today, you could do it any way that you choose to make it look sensible. -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tuplet number direction
"Phil Holmes" writes: > - Original Message - > From: "David Kastrup" > To: "Simon Albrecht" > Cc: "Thomas Morley" ; > Sent: Friday, April 15, 2016 8:04 AM > Subject: Re: Tuplet number direction > > >> Simon Albrecht writes: >> >>> On 15.04.2016 00:51, Thomas Morley wrote: (1) The TupletNumbers are always inside the bow, I coded no possibility to print the Number cutting the bow. I maybe add it later. (2) What to do at line-break? >>> >>> Wouldn’t it better do disallow line-breaks during tuplets >>> (i.e. \override TupletBracket.breakable = ##f – if that has an >>> effect), or at least ignore such situations for this particular style? >>> Clearly, there are situations where it would be better or even >>> necessary to break tuplets, but I don’t think such situations occur >>> before 1900, >> >> Josquin des Prez? I've sung some Missa from him with wildly augmented >> triplets crossing a number of bars. Timing them accurately took some >> math because at that speed there was no natural flow any more really. >> >> That would be early 16th century. > > Wouldn't have been notated like that in those days - they would have > used coloratio. So? Modern practices of printing Renaissance music are different from contemporary practices. They are still different from modern practices of printing Classic music. > So to notate it for singers today, you could do it any way that you > choose to make it look sensible. Which would usually involve triplet brackets rather than hacking this into partial note values at measure boundaries. Which is how it was done in the score I have been singing this from. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tuplet number direction
David Kastrup writes: [...] > "Phil Holmes" writes: > >> So to notate it for singers today, you could do it any way that you >> choose to make it look sensible. > > Which would usually involve triplet brackets rather than hacking this > into partial note values at measure boundaries. Which is how it was > done in the score I have been singing this from. Sigh. "The former is how it was done in the score I have been singing this from." Like I would have expected it. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
variable to simplify writing / chordmode and <<>>
I writing some accordion scores and for this reason I'm trying to create
the lilypond tools that will make the task more easy.
I started writing the following vaiables:
cC = {c4}
cc = \chordmode {c4}
ccC = { \new Voice << {\cC} {\cc}>>}%first solution
(In the attached image you can see an output example)
I know I could define ccC in this other way
ccC = {4} % second solution
but:
(1) if possible I would like to build the tools creating small 'object' and
assembling them (in this case I create cC and cc and I assembled them in
ccC)
(2) I need to use Thomas Morley "event-chord-reduce" on the score. This
work well with my first solution because it reduces the chord but it does
not work with the second solution because it is not a chord
I would like to know if I'm going in the right direction or there is a
better way.
Thank you, g.
P.S.
- Sorry for the terrible variables name, these are temporary.
- In the 'real' code cc is defined in a bit more complicated way:
cc = \chordmode { c4 _\tweak #'direction #UP _\markup {M}}
but for the previous example I simplify it because it was not relevant.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Lilypond error behaviour
I am writing a lilypond server to process lilypond source files submitted by a
client program to avoid the startup costs of lilypond. This is based on an idea
by Sharon, I think pulled up from past archives, and is a small project Sharon
and Urs and I are working on experimentally.
In relation to this, an oddity – to me, at least – came up, when dealing with
errors in source files. If I have a lilypond source as shown in the example
here, it’s deliberately incorrect, and I would expect lilypond to report a
fatal error and stop. Instead, this file produces not only a fatal error
message from lilypond, but also generates a PDF file. Why is the file
generated? This has me rather confused – I thought my server code was not
working. The syntax error is reported as fatal not as a warning.
Is this expected behaviour? Wouldn’t a complete syntax error stop processing?
What am I missing here? Should I be addressing instead the bug list?
Andrew
— snip
file test.ly:
——
\version "2.19.39"
junk syntax error on purpose
{
c''
}
lilypond output:
——
Processing `test.ly'
Parsing...
test.ly:3:6: error: syntax error, unexpected STRING, expecting '.' or '=' or ','
junk
syntax error on purpose
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `/tmp/lilypond-kUaRg5'...
Converting to `test.pdf'...
Deleting `/tmp/lilypond-kUaRg5'...
fatal error: failed files: "test.ly"
— snip
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond error behaviour
On 15.04.2016 13:59, Andrew Bernard wrote: Is this expected behaviour? Wouldn’t a complete syntax error stop processing? What am I missing here? Should I be addressing instead the bug list? To me, the oddity would be in that Lily speaks of a ‘fatal error’ here. It’s a policy that Lily should always try to finish processing and return some output instead of just exiting. Best, Simon ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tuplet number direction
On 15.04.2016 10:23, David Kastrup wrote: Josquin des Prez? I've sung some Missa from him with wildly augmented triplets crossing a number of bars. Timing them accurately took some math because at that speed there was no natural flow any more really. That would be early 16th century. Wouldn't have been notated like that in those days - they would have used coloratio. So? Modern practices of printing Renaissance music are different from contemporary practices. They are still different from modern practices of printing Classic music. So to notate it for singers today, you could do it any way that you choose to make it look sensible. Which would usually involve triplet brackets Exactly, brackets, not bows. So this isn’t relevant to the current thread either. Best, Simon ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond error behaviour
Am 15. April 2016 18:50:48 MESZ, schrieb Simon Albrecht : >On 15.04.2016 13:59, Andrew Bernard wrote: >> Is this expected behaviour? Wouldn’t a complete syntax error stop >> processing? What am I missing here? Should I be addressing instead >the >> bug list? > >To me, the oddity would be in that Lily speaks of a ‘fatal error’ here. > >It’s a policy that Lily should always try to finish processing and >return some output instead of just exiting. This seems related to the regular source of confusion when a version mismatch cause a fatal error *and* a file. Urs > >Best, Simon > >___ >lilypond-user mailing list >lilypond-user@gnu.org >https://lists.gnu.org/mailman/listinfo/lilypond-user -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tuplet number direction
On Fri, Apr 15, 2016 at 11:53 AM, Simon Albrecht wrote: > On 15.04.2016 10:23, David Kastrup wrote: > >> Josquin des Prez? I've sung some Missa from him with wildly augmented triplets crossing a number of bars. Timing them accurately took some math because at that speed there was no natural flow any more really. That would be early 16th century. >>> >>> Wouldn't have been notated like that in those days - they would have >>> used coloratio. >>> >> So? Modern practices of printing Renaissance music are different from >> contemporary practices. They are still different from modern practices >> of printing Classic music. >> >> So to notate it for singers today, you could do it any way that you >>> choose to make it look sensible. >>> >> Which would usually involve triplet brackets >> > > Exactly, brackets, not bows. So this isn’t relevant to the current thread > either. > > Even if it is unlikely that an era of music which favors bow notation would require tuplets across bars or line breaks, it still makes sense to allow them for consistency. Besides, someone will come along who likes the look of bows and requires a broken tuplet for a more recent style of music DN.. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Controlling compilation
David Sumbler writes:
> As an experiment, I produced this:
>
> File: experimentNotes.ly
>
> \version "2.19.24"
>
> compileA =
> \score {
> \new Staff {
>a' a' a' a'
> }
> \layout { }
> }
[...]
> #(if sectionA #{ \compileA #} )
From: David Kastrup
> > Date: Mon, 11 Apr 2016 09:29:40 +0200
> >
> > #... at top level is executed and the result ignored to allow for
> > #(set! ...) and similar expressions with usually unspecified return
> > #codes. Just try
> >
> > $(if sectionA compileA)
> >
> > instead.
This is wonderfully elegant, and is just what I was looking for.
I confess, though, that I have looked at the relevant section of the
"Extending" manual, and I could never have figured this out for myself.
> > From: Urs Liska
> > Date: Mon, 11 Apr 2016 09:13:12 +0200
> >
> > Hi David,
> >
> > I'm sure this could be made work, with some more complex Scheme code.
> > But If I'm understanding you correctly there seems to be a simpler way.
> >
> > You seem to be ready to *do* some manual changes to your master file
> > (e.g. defining a variable or not). So you could simply put your
> > different scores in individual include files and comment in/out these
> > includes.
> > If you are creating independent scores (or score/part/whatever) you
> > should consider including the scores in \bookpart expressions to
> > guarantee a page break if you compile more than one sub-score in one go.
On the face of it, this seems to me to be rather more complex than what
I was trying to do. (I do, incidentally, use \bookpart in my full
score.) But I would be interested to see a detailed example of how this
can be made to work. By "detailed", I mean showing everything important
that is in each file apart from the actual music itself.
> > From: Jan-Peter Voigt
> > Date: Mon, 11 Apr 2016 09:16:30 +0200
> >
> > Hi David,
> >
> > compileA is not compiled, because it is just a music-expression inside a
> > scheme-expression.
> > But if you add it to the current book, it will appear. So your example
> > will work with a tiny extension:
> >
> > #(if sectionA (add-score #{ \compileA #} ))
> >
> > But you should look around for templating mechanics.
I think you are suggesting something similar to what Urs described. Can
you point me to an example of the sort of thing you are thinking of?
Thanks to all for your suggestions.
David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Controlling compilation
Am 15.04.2016 um 19:46 schrieb David Sumbler:
>>> You seem to be ready to *do* some manual changes to your master file
>>> > > (e.g. defining a variable or not). So you could simply put your
>>> > > different scores in individual include files and comment in/out these
>>> > > includes.
>>> > > If you are creating independent scores (or score/part/whatever) you
>>> > > should consider including the scores in \bookpart expressions to
>>> > > guarantee a page break if you compile more than one sub-score in one go.
> On the face of it, this seems to me to be rather more complex than what
> I was trying to do.
Maybe the others' solutions are simpler. I would have thought there's
more to be done in Scheme ...
> (I do, incidentally, use \bookpart in my full
> score.) But I would be interested to see a detailed example of how this
> can be made to work. By "detailed", I mean showing everything important
> that is in each file apart from the actual music itself.
>
>
OK, probably I'd need several examples for different use cases (as I'm
not fully clear what you *really* want to do). But I'll show you one
pattern that I like pretty much: Actually it's one set-up and two
patterns/uses
###
musicA.ily:
violin = {
c''1
}
viola = {
c'1
}
cello = {
\clef bass
c1
}
###
musicB.ily:
violin = {
d''1
}
viola = {
d'1
}
cello = {
\clef bass
d1
}
###
violinStaff.ily
violinStaff = \new Staff \violin
### etc. violaStaff.ily and celloStaff.ily
###
partViolin.ily
\include "violinStaff.ily"
\bookpart {
\score {
\violinStaff
}
}
### etc. for viola and cello
###
score.ily
\include "violinStaff.ily"
\include "violaStaff.ily"
\include "celloStaff.ily"
\bookpart {
\score {
<<
\violinStaff
\violaStaff
\celloStaff
>>
}
}
Now your actual main.ly:
\include "musicA.ily"
%\include "musicB.ily"
\include "partViolin.ily"
%\include "partViola.ily"
%\include "partCello.ily"
\include "score.ily"
#
Now you can:
- comment out one of the alternative music files (using A or B)
- comment out any combination of part/score files.
The key to this is that you define alternative music files with
variables of the same name. Then you define scores/parts etc. that *use*
these variables. If you set this up properly you can easily switch
between musics and scores.
Depending on the use case one can make this even more sophisticated by
plugging in "adaptor" files.
HTH
Urs
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Workaround for issue 1515?
I have independently stumbled across what I now now is Issue 1515 "Subdivided
beams are disregarded with \cueDuring".
Here is a (tiny-ish) example based on some code from 2011:
/\version "2.19.39"
music = \relative c'' {
\set subdivideBeams = ##t
\set baseMoment = #(ly:make-moment 1 8)
c16->( \mp d) c c
}
\addQuote music \music
<<
\new Staff {
*% \set Score.quotedCueEventTypes = #'()*
\cueDuring #"music" #UP s4
}
\new Staff {
\new CueVoice
\quoteDuring #"music" s4
}
>>/
Uncommenting the bold line above somehow causes *everything* to be
'correctly' quoted, but I want to be able to selectively quote parts - e.g.
not dynamics or slurs or articulations.
Is this an insurmountable bug, or is there a workaround that exists by
inserting some special event type into quotedCueEventTypes?
Thanks,
Dominic
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Workaround-for-issue-1515-tp189630.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: Controlling compilation
David Sumbler writes: > From: David Kastrup >> > Date: Mon, 11 Apr 2016 09:29:40 +0200 >> > >> > #... at top level is executed and the result ignored to allow for >> > #(set! ...) and similar expressions with usually unspecified return >> > #codes. Just try >> > >> > $(if sectionA compileA) >> > >> > instead. > > This is wonderfully elegant, and is just what I was looking for. > > I confess, though, that I have looked at the relevant section of the > "Extending" manual, and I could never have figured this out for > myself. That sounds more like something I should be confessing. The #/$ dichotomy ($ previously was implemented via ly:export causing a lot of problems) and define-scheme-function/define-void-function were designed and implemented and to a good degree documented by me. It may well be that some aspects where decisions had to be made that were reasonably consistent with expectations and previous behavior did not really make it into proper documentation. The code most certainly has seen quite more wholesale rewrites and refactoring than the documentation: the documentation has mostly just seen amendments additions. Consequently, it tends to be more patchwork and less consistent in style and organization. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: variable to simplify writing / chordmode and <<>>
2016-04-15 11:06 GMT+02:00 Gianmaria Lari :
> I writing some accordion scores and for this reason I'm trying to create the
> lilypond tools that will make the task more easy.
>
> I started writing the following vaiables:
>
> cC = {c4}
> cc = \chordmode {c4}
> ccC = { \new Voice << {\cC} {\cc}>>}%first solution
>
>
> (In the attached image you can see an output example)
>
> I know I could define ccC in this other way
>
> ccC = {4} % second solution
>
>
> but:
>
> (1) if possible I would like to build the tools creating small 'object' and
> assembling them (in this case I create cC and cc and I assembled them in
> ccC)
> (2) I need to use Thomas Morley "event-chord-reduce" on the score. This work
> well with my first solution because it reduces the chord but it does not
> work with the second solution because it is not a chord
>
> I would like to know if I'm going in the right direction or there is a
> better way.
>
> Thank you, g.
>
> P.S.
> - Sorry for the terrible variables name, these are temporary.
> - In the 'real' code cc is defined in a bit more complicated way:
>
> cc = \chordmode { c4 _\tweak #'direction #UP _\markup {M}}
>
> but for the previous example I simplify it because it was not relevant.
Hi Gianmaria,
I've no idea what you're trying to do, please give us a better idea about it.
Maybe rewording your request woud help, and please post code matching the image.
Thanks,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tuplet number direction
2016-04-15 7:25 GMT+02:00 Werner LEMBERG : > >> Meanwhile I recoded it (using make-bow-stencil which is not >> available in 2.18.2) making things way easier. > > Nice! One minor thing: If space allows, I would move the `3' a bit > nearer to the center to reduce the curvature of the slur. You mean move the `3' nearer to the staff, right? > Would that be possible? No idea. I'll have a look asap, which may take some time, though. I'm far to busy with non-lily-tasks ... Cheers, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tuplet number direction
2016-04-15 19:07 GMT+02:00 David Nalesnik : > Even if it is unlikely that an era of music which favors bow notation would > require tuplets across bars or line breaks, it still makes sense to allow > them for consistency. Agreed. I never considered to disallow tuplets over line-break. Gould has nothing to say about it? (I still don't own the book...) I'm not always convinced by our current default either... Cheers, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tuplet number direction
>> Nice! One minor thing: If space allows, I would move the `3' a bit >> nearer to the center to reduce the curvature of the slur. > > You mean move the `3' nearer to the staff, right? Yep. Werner ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond error behaviour
So gentlemen, since this is a regular source of confusion, and it certainly has had me glued up for many days wondering what is wrong with my code, should this not be raised as a defect, or at the very least the adjetctive ‘fatal’ removed fromt he message, and replaced with ‘warning’ or something else? As to lilypond making a best effort at producing output, I have never seen this referred to in the NR. That ought to go in somewhere. But for my preference, a serious syntax error which is just outright garbage should in my opinion not produce any output. Other types of compilers would stop. If there is such an error it neeeds attention, not PDF output I reckon. I think this is best moved to the bug list for discussion. I think aberrant behaviour that does not match ordinary expectations can fairly be classed as a bug. Andrew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
