Re: Split percent repeats at line breaks
On 29/02/2020 13:10, Davide Liessi wrote:
Hi all.
I'd like to have percent repeats automatically split at line breaks,
i.e., in the following example I'd like the first score to look like
the second.
\version "2.19.84"
\score {
\repeat percent 30 { c'1 }
}
\score {
{
\repeat percent 14 { c'1 }
\repeat percent 16 { c'1 }
}
}
I think that this should typically also reset the percent repeat
counter, effectively behaving as if they were distinct percent
repeats, but being able to choose whether to reset it or not would be
nice.
Is there a way to achieve this?
I think your first requirement is the norm for human engraving,
certainly I've never come across any music outside of lilypond where a
staff has a percent as its first bar. Equally, I've never seen it reset
the count - that just carries on. What I have seen is where the count
only starts at eg bar 5.
I don't know enough about lilypond internals, but I guess the big
problem is that if the line-breaking calculation actually affects the
size of the bar (changing the first bar of a line from a percent to a
copy of bar 1 of the repeat), then the calculation itself could get into
quite a tangle.
Cheers,
Wol
Re: Transposing instruments
On 13/03/2020 11:29, Francisco Vila wrote: So my question for Kieren is, for large scores involving transposing wind instruments along with strings etc, how do you manage this by using only clefs and no transposition? This is a double question, seeing as wind instruments rarely transpose by an octave. For example, I play the trombone, which is either written in bass clef concert, or in treble transposed by a ninth. I just don't worry about the 8s on the clef, I transpose a second and use the treble_8 clef "as is". Nobody's commented on that extra little 8 so far ... :-) Cheers, Wol
Re: Remote Ensemble Playing
On 28/03/2020 11:00, Peter Gentry wrote: I appreciate this is off topic but in these times of social isolation does anyone have any tips. Clearly latency is the main issue – I wonder could this be reduced by say hosting a Zoom meeting on a private router – maybe only one video for a conductor. Experience suggests that a latency of 25ms is not low enough. Regards Peter https://www.youtube.com/watch?v=P0KiCXZ2IM0 Stuff I've picked up elsewhere - avoid Firefox. I hate to say that, but the evidence is that one user on that and everyone else suffers. Cheers, Wol
Re: Remote Ensemble Playing
On 28/03/2020 18:55, Ralf Mattes wrote: To the OP: there is an immanent latency in all network connections - packets need to pass through switches and routers, and let's not forget the speed of electrical signals. While one can get pretty low latency on local networks (Dante et al.) trying live jamming over the internet is pretty much impossible. Well, I shall soon find out ... a band I play for has scheduled a practice for Easter Saturday ... Cheers, Wol
Re: Suggestion to make sharps and flats persistent
On 13/05/2020 16:38, David Kastrup wrote: Given the number of English-speaking LilyPond users who all share the somewhat strange habit of calling a b-flat "b" if there is a flat in the key signature, it is sort of a safe bet that you are not the first to make this kind of proposal. Are these the same ones who call b an h? Certainly for someone who's mother tongue is English (NOT American) I'd never call b-flat a b because how would I tell whether it's flat or not :-) Cheers, Wol
Re: Suggestion to make sharps and flats persistent
On 14/05/2020 19:46, David Wright wrote: Wol gave these "b" people the benefit of the doubt as being "b/h" people (but why was the American tongue mentioned?). Because Americans like to think they speak English (but they are mistaken!). I play crotchets, not quarter-notes. I don't know what other weird language habits the Americans have ... :-) Cheers, Wol
Re: Suggestion to make sharps and flats persistent
On 14/05/2020 23:38, Karlin High wrote: On 5/14/2020 5:32 PM, antlists wrote: Because Americans like to think they speak English (but they are mistaken!). I play crotchets, not quarter-notes. I don't know what other weird language habits the Americans have ... :-) You really don't know? I'm almost certain you'd have some good guesses, though. ;-) I'm sure they'd love to table our eraser ... :-) Cheers, Wol
Re: Current octave in relative mode
There's a function Han Wen wrote for me years ago, that's made its way
in to standard lilypond. It's probably mentioned in the docu about
relative mode. Something along the lines of
c1 \highlight { c8 d e f g f e d }
\setAbsoluteOctave ...
c1 \highlight { c8 d e f g a b c }
Don't quote me on the function name though ... (I needed it for
Pennsylvania 6-5-0-0-0
Cheers,
Wol
On 15/05/2020 11:01, Klaus Blum wrote:
Hi,
I have a function that uses a music expression twice.
My problem is:
In relative mode, this expression can lead into a different octave. Then
the second application of the music expression starts from that new octave.
(See the last two invocations of "\highlight" in the example below)
Is there something I can do INSIDE my function to prevent this? E.g.
storing and re-applying the current octave? Thanks for any hint. :)
%
highlight =
#(define-music-function (mus)
(ly:music?)
#{
<<
$mus
\makeClusters $mus
>>
#})
\new Staff {
\highlight { c'8 d' e' f' g' a' b' c'' }
\relative c' {
c1 \highlight { c8 d e f g f e d }
c1 \highlight { c8 d e f g a b c }
c1 \highlight { f,4 e d c }
c1
}
}
%
Cheers,
Klaus
Re: Current octave in relative mode
On 15/05/2020 12:28, antlists wrote:
There's a function Han Wen wrote for me years ago, that's made its way
in to standard lilypond. It's probably mentioned in the docu about
relative mode. Something along the lines of
c1 \highlight { c8 d e f g f e d }
\setAbsoluteOctave ...
c1 \highlight { c8 d e f g a b c }
Don't quote me on the function name though ... (I needed it for
Pennsylvania 6-5-0-0-0
Found it ...
\version "2.8.2"
resetOctave =
#(define-music-function
(parser location reference-note)
(ly:music?)
(let*
((notes (ly:music-property reference-note 'elements))
(pitch (ly:music-property (car notes) 'pitch))
)
(set! (ly:music-property reference-note 'elements) '())
(set! (ly:music-property reference-note
'to-relative-callback)
(lambda (music last-pitch)
pitch))
reference-note
))
pennsylvania = \context Voice = pennsylvania {
\override NoteHead #'style = #'cross
r2_\markup{ shout } f8. f16 f8. f16 f4 f f8. f16 r4
}
pennsylvaniaLyrics = \lyricmode { \small { Penn syl van ia six five thou
sand } }
voiceTromboneI = \relative c' {
r2 ef4.-- ef8-> ~ ef1 r2 r4 bf8.->( ef16-.) r2 r4 ef,8. af,16-> ~ |
af2 c-- df-- d-- ef-- df-- c-- bf-- |
\repeat "volta" 2 { R1*6 } \alternative { { \resetOctave f
\pennsylvania } { \pennsylvania } }
bf8-. cf4-> bf8-> ~ bf4 bf8.-- af16-. r8 af4.---. r2 bf8-. cf4-- bf8->
~ bf4 bf8.-- af16-> ~ |
Cheers,
Wol
Okay, this is just the start of the file so it won't compile as is :-)
but you can see it defines the function resetOctave. I don't
particularly remember how it works, but you also see how it's used
further down. iirc it eats the first note after it - the f - and treats
it as an absolute pitch of zero length so the subsequent phrase is at
the right pitch regardless of what went in front of it.
As I say, I think this function or something similar has made its way
into lilypond proper.
Cheers,
Wol
On 15/05/2020 11:01, Klaus Blum wrote:
Hi,
I have a function that uses a music expression twice.
My problem is:
In relative mode, this expression can lead into a different octave. Then
the second application of the music expression starts from that new
octave.
(See the last two invocations of "\highlight" in the example below)
Is there something I can do INSIDE my function to prevent this? E.g.
storing and re-applying the current octave? Thanks for any hint. :)
I think you can use this inside your function. I explicitly didn't want
to because this phrase appears in at least two different octaves so I
wanted to apply the pitch outside it instead.
Cheers,
Wol
Re: Current octave in relative mode
On 16/05/2020 23:19, David Kastrup wrote: As I say, I think this function or something similar has made its way into lilypond proper. What advantage over the solution using make-relative that I posted do you see here? Because if I understand the OP correctly, what he wants is \resetRelativeOctave, which is already a standard part of lilypond? I'm guessing Han Wen's resetOctave is its predecessor. So I guess - at the third attempt - my solution is the best because it doesn't need a custom function at all :-) Cheers, Wol
Re: Current octave in relative mode
On 17/05/2020 00:04, David Kastrup wrote:
antlists writes:
On 16/05/2020 23:19, David Kastrup wrote:
As I say, I think this function or something similar has made its way
into lilypond proper.
What advantage over the solution using make-relative that I posted do
you see here?
Because if I understand the OP correctly, what he wants is
\resetRelativeOctave, which is already a standard part of lilypond?
What he wants is music used twice within a function not to end up in
different octaves.
Isn't that what \resetRelativeOctave does? His description seems exactly
to match my problem with Pennsylvania 6-5-0-0-0
I'm guessing Han Wen's resetOctave is its predecessor.
So I guess - at the third attempt - my solution is the best because it
doesn't need a custom function at all :-)
make-relative has been part of LilyPond in its current form since
2.18.0. I am not sure what you call "custom function" in this context.
Particularly since your proposal contained a large amount of code.
It was an example which - obviously - predated both \resetRelativeOctave
and \makeRelative (you did notice the "version 2.8.0" at the start?)
I couldn't remember what \resetRelativeOctave was, so I was trying to
give him the clues he needed to find it. I did explicitly say "I think
it's now a standard part of lilypond" (implying it wasn't when that code
was written).
So let's give a very simple example of what I think he was trying to
achieve ...
arpeggio = { c e g c }
\new Staff {
\relative c' {
\arpeggio \resetRelativeOctave c'
\arpeggio \resetRelativeOctave c'
\arpeggio
}
}
Despite being in relative mode, all the arpeggios will now start on
middle C. The OP's eXample is more complicated but as far as I can tell
this is what he's aiming at.
Oh - and I believe
arpeggio = { \resetRelativeOctave c' c e g c }
would also work. I don't know for certain because I haven't had this
problem since Pennsylvania.
Cheers,
Wol
Re: Identify included files
On 15/05/2020 21:17, Fr. Samuel Springuel wrote: Now I just need to turn this list into something that can be used to figure out if the target needs to be recompiled. As Jacques said, "make". At the top of your directory structure you can have a makefile, and it just contains a list of all your targets, and the files they depend on. Okay, every time you add a new include, you need to update it, but... Then when you change something, you just go to your top directory, type "make", and watch everything affected by your recent changes recompile. The really nice thing about it, is it will handle recursive includes by itself. Can't remember the syntax, but if an include file pulls in other includes, you can define that include file as a target, which then flags any other that targets that use it. So each target in your makefile only needs to include the includes that it depends *directly* upon. Cheers, Wol
Re: Identify included files
On 18/05/2020 13:44, David Kastrup wrote: antlists writes: On 15/05/2020 21:17, Fr. Samuel Springuel wrote: Now I just need to turn this list into something that can be used to figure out if the target needs to be recompiled. As Jacques said, "make". At the top of your directory structure you can have a makefile, and it just contains a list of all your targets, and the files they depend on. Okay, every time you add a new include, you need to update it, but... Then when you change something, you just go to your top directory, type "make", and watch everything affected by your recent changes recompile. The really nice thing about it, is it will handle recursive includes by itself. Can't remember the syntax, but if an include file pulls in other includes, you can define that include file as a target, which then flags any other that targets that use it. So each target in your makefile only needs to include the includes that it depends *directly* upon. That's not how Makefile dependencies work. Dependencies track the relation of _output_ files to their _input_. They do not track the hierarchy of different input files that only refer to each other by name: for the purpose of Make, those are independent and equivalent. But the _output_ file(s) generated from them are dependent on all of the respective input files in use, and tracking those and generating the dependencies was what Fr. Samuel was asking about in the first place. Yup. But he wanted to know "which files do I need to recompile". Which is exactly what makefiles do. so if trombone.pdf is compiled from trombone.ly, which includes trombone-notes.ly, which includes dynamics.ly, then I know there is some sort of syntax which will: define trombone-notes.ly as a target, define it as changed if its dependencies change, and say "it doesn't exist as a file that can be created with a command". So if dynamics.ly changes, it cascades up and causes trombone.pdf to be re-compiled, but this is the important bit - you don't need to *ex*plicitly define trombone.pdf as relying on dynamics.ly Just had a slight rethink - which affects things - namely what exactly is Fr. Samuel trying to achieve. Does he want a list of dependencies as a thing in its own right, or does he want to know which targets need to be recompiled as a result of changing a file. Because "make" is all he needs if the latter is what he's aiming for. If he really wants the former, then yes he'll need all thse lily functions etc that people have pointed him to. Cheers, Wol
Re: Identify included files
On 18/05/2020 15:29, Fr. Samuel Springuel wrote: On 18 May, 2020, at 9:37 AM, antlists wrote: define trombone-notes.ly as a target, define it as changed if its dependencies change, and say "it doesn't exist as a file that can be created with a command". Right, that’s the step I’m trying to automate. Make itself cannot determine the list of prerequisites. You either need to do that manually (a real pain) or provide a tool that can examine a file, determine what its prerequisites are and then write them out in a way that make understands. From the manual for GNU Make: https://www.gnu.org/software/make/manual/html_node/Automatic-Prerequisites.html#Automatic-Prerequisites The example there uses the -M flag for a C compiler. I’m looking to come up with an equivalent for LilyPond. Okay, does that mean you want a list of all the lilypond include files, or just your own? If you're digging into the internals of lilypond, then it'll be a big job, and makes it dangerous to upgrade lilypond. Because I assume that means you're actually modifying lilypond's internal structure. What I do, anything of lilypond's that I modify, I split it out into my directory structure, and then over-ride lilypond's version from within my source. That way, what happens to lilypond during an upgrade is no concern of mine (other than changes to syntax which mess up my source :-) If it's just your own files you're concerned about, then grep will probably do the trick. I don't know how to recurse directories, but making it search all the files in a directory for "include", and tell you which file it found that line in, is pretty basic. You can then read up on make for how to create those virtual objects, and use an editor to put them in your makefile. Not totally automated, I admit, but fairly simple grunt-work. The sort of thing I could have written a BASIC program to do in 10 minutes, except I don't have access to a BASIC I understand how to use any more - ironic - as computers have got easier to use, so the programming languages have got harder... Cheers, Wol
Re: Suggestion to make sharps and flats persistent
On 18/05/2020 17:33, Kieren MacMillan wrote:
We (well… modulo me LOL) don’t get this worked up about how \relative makes
cut-and-paste a nightmare. Why start now?;)
Those of us who only use \relative (just me?) don't have any problems
with cut-n-paste. Or is it just that my workflow is more likely to use
"\repeat unfold"?
I've got no problem with \keyed, but there is a fly in the ointment here
... \keyed a \minor { a b c d e f g a g f e d c b a }
Now is that a g-natural or g-sharp? Likewise the f.
Cheers,
Wol
Re: Suggestion to make sharps and flats persistent
On 18/05/2020 22:15, Mark Stephen Mrotek wrote:
The natural a minor scale does not contain any sharps.
But is it a natural scale?
The harmonic a minor scale has the f sharp.
or a harmonic scale?
The melodic a minor scale has the g sharp and the f sharp.
But it also has g and f. So my point remains - ESPECIALLY if it's the
melodic scale - how is lilypond supposed to know whether the g and f are
supposed to be sharpened? :-)
Mark
Cheers,
Wol
-Original Message-
From: lilypond-user [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org]
On Behalf Of antlists
Sent: Monday, May 18, 2020 12:22 PM
To: lilypond-user@gnu.org
Subject: Re: Suggestion to make sharps and flats persistent
On 18/05/2020 17:33, Kieren MacMillan wrote:
We (well… modulo me LOL) don’t get this worked up about how \relative
makes cut-and-paste a nightmare. Why start now?;)
Those of us who only use \relative (just me?) don't have any problems with cut-n-paste.
Or is it just that my workflow is more likely to use "\repeat unfold"?
I've got no problem with \keyed, but there is a fly in the ointment here ...
\keyed a \minor { a b c d e f g a g f e d c b a }
Now is that a g-natural or g-sharp? Likewise the f.
Cheers,
Wol
Re: Suggestion to make sharps and flats persistent
On 19/05/2020 16:04, David Kastrup wrote: All because people think "it's not difficult to figure out how to make it work" when actually it is once you aim for more than a "mostly working" determination and keep shuffling around just which 10% you are willing to let fall apart. Too many people try to solve the immediate problem, without asking themselves what the real problem is. If you work out what the state table is, it's fine solving just your bit of it. But if you don't know what the state table is, (trying to) solve your bit just leaves a big mess for the next guy who needs a different bit solved. Cheers, Wol
Re: Identify included files
On 21/05/2020 01:49, David Wright wrote: I don't understand your equivalence between .ily and .h files. The .ily file(s) can contain just as much code as the .ly file(s), whereas .h files don't contain any code at all (in the sense of producing executable code for the next stage. a) just like .h files, .ily files can't be passed directly to a compiler for compilation. b) who says .h files don't produce executable code? They often contain code, sometimes entire functions. I understand the equivalence exactly - it's what you DO to the file. You're thinking "what you *should* put in the file". Since when have people done what they *should*? Cheers, Wol
Re: Identify included files
On 21/05/2020 14:36, David Kastrup wrote: antlists writes: On 21/05/2020 01:49, David Wright wrote: I don't understand your equivalence between .ily and .h files. The .ily file(s) can contain just as much code as the .ly file(s), whereas .h files don't contain any code at all (in the sense of producing executable code for the next stage. a) just like .h files, .ily files can't be passed directly to a compiler for compilation. b) who says .h files don't produce executable code? They often contain code, sometimes entire functions. The point of .h files is that they are intended to be included by more than one compilation unit resulting in an executable. Which is exactly how I use .ily files ... As such, they are limited with regard to the code they can contain. They can contain a) inline function definitions: those can occur in multiple compilation units as long as they are identical. You're describing the way I define variables that contain all my notes. You're also describing how I define the musical structure. b) static inline: do not even need to be identical, are per-unit. c) static data definitions, are per-unit. d) template function definitions I redefine the header function - I've NEVER seen a header laid out the way lilypond does it, apart from parts produced by lilypond ... Plus I have my own dynamics definition file that extends lilypond's ones I don't think that .ly/.ily is all that comparable here... The way I use .ily files EXACTLY matches your definition of a .h file... how on earth do you use them? Cheers, Wol
Re: Identify included files
On 21/05/2020 16:36, David Wright wrote:
On Thu 21 May 2020 at 13:57:00 (+0100), antlists wrote:
On 21/05/2020 01:49, David Wright wrote:
I don't understand your equivalence between .ily and .h files. The
.ily file(s) can contain just as much code as the .ly file(s), whereas
.h files don't contain any code at all (in the sense of producing
executable code for the next stage.
a) just like .h files, .ily files can't be passed directly to a
compiler for compilation.
Why do you say that?
Because while it may not be globally true, I have tried accidentally to
do things like "lilypond voiceTrombone.ily" and it blew up quite
spectacularly. I would expect most of mine, and in truth most other
peoples', .ily files to blow up if fed straight to lilypond.
And if they do compile, the output probably isn't much use ... :-)
b) who says .h files don't produce executable code? They often contain
code, sometimes entire functions.
I understand the equivalence exactly - it's what you DO to the file.
Good, that means I have a second source of edification as to what the
intent of this analysis is.
You're thinking "what you *should* put in the file". Since when have
people done what they *should*?
Letting that pass, let's say we have a source file foo.c and it needs
an extraordinary quantity of functionality that's contained in bar.c.
We put the latter's function declarations into bar.h and compile
bar.{c,h}¹ into bar.o.
Does bar.c contain a main{} definition?
Now we can compile foo.c (which #includes bar.h) over and over while
debugging it, all without ever recompiling bar.c. foo.c knows all it
needs to know about bar.c because of bar.h's declarations.
Can you now link bar.o into foo? I honestly don't know - I don't know
how a linker will behave if fed two main{} functions ... ?
I now have a suite.ly that typesets my Suite for flute and piano.
It \includes nine files: flute{I,II,III}.ily, piano{I,II,III}.ily
(the notes), and flute-part.ily, piano-part.ily and complete-score.ily,
(my \score templates). It also \includes {marks,dyns,fingers}.ily that
contain LP code for my preferred styles of markings, dynamics and fingering.
I have a file, suite.dep, which contains the information that suite.ly
depends on these files to produce three targets, {flute,piano,suite}.pdf
The same file might also indicate that I need just flute{I,II,III}.ily,
flute-part.ily and {marks,dyns,fingers}.ily for just a flute.pdf.
What do I write in a top-level theFlute.ly file to produce this
flute.pdf and how does it benefit from the suite.sep information?
How do I use this information profitably, in the way that bar.h did?
¹ I'm abbreviating with shell's "brace expansion" notation.
Cheers,
David.
Now we get to the meat of the matter. You've put bar.c's *declarations*
into bar.h. Does lilypond even have declarations? Also, it's perfectly
normal practice to put *definitions* in .h files - static variables,
macros, inline functions, etc etc.
I put most of my lilypond variable *definitions* into .ily files. Yup,
.h files *tend* to contain declarations not definitions, but as I say, I
don't think lilypond syntax has declarations?
So yes, am I right in thinking you view .ily files as closer to .o
files? With lilypond closer to a linker than a compiler?
At the end of the day, I see it as .h files can contain declarations,
.ily files contain declarations. .h files are included, .ily files are
included. Some languages (like lilypond) are monolithic and don't really
have the concept of libraries. So I find it extremely easy to view
.ly/.ily as being similar to .c/.h. Not the same, because lilypond is
not gcc ... :-)
There's no one absolute view - you see things different to me, doesn't
mean you (or me) is right.
Cheers,
Wol
Re: show key signature but also alterations
n 21/05/2020 07:35, Frédéric wrote:
Hi,
I'm writing a scale book. I would like to have the key signature but
also an accidentals in front of each note. For example, in d \major, I
would like to print f# c# as key signature and a # in front of each f
and c.
I see 2 possibilities:
1. define a custom Key_engraver which just prints the key and do not
set the alterations.
2. define a special accidental rule that considers that the key
signature is blank
However, I was not able to do any of those.
Any idea?
Not quite what you asked for, but pretty much what you want?
\score {
\key bf \major
bf? c d ef? f g a bf?
}
Is that any good?
Cheers,
Wol
Re: Identify included files
On 23/05/2020 06:06, Michael Gerdau wrote:
Big deal. I won't ask what's in voiceTrombone.ily.
A variable declaration. You know - EXACTLY THE SAME as C programmers
often stick in .h files ...
I don’t think that’s correct.
For one according to my understanding LP has no variable declarations
whatsoever, only definitions.
I think I'm getting confused :-) no change there :-)
For two LP allows for an arbitrary number of definitions of the same variable,
the latest (as of the parser) overriding any previous. In C there’s just one
definition and an arbitrary number of repetitions of the same declaration.
int i = 1;
enum something = {
a = 1;
b = 2;
c = 3;
}
voiceTromboneI = \relative c { c d e f g a b c }
Forgive my rusted solid C syntax - I can't remember it properly :-)
The two languages may be different, but my mental view of the Computer
Science behind them tells me to treat them the same. I declare them in
an include file, and use them where I need them.
(Whether the language treats them as such, the theory says they are
global constants...)
Cheers,
Wol
Re: registering a composition
On 22/05/2020 13:26, Gilles Sadowski wrote: IIUC, CC licences aim to protect against others making money from your work. How is "ASCAP not being happy" related to that? Unless I'm mistaken, LilyPond (GNU) and CC belong to the "eco-system" where sharing is the norm (to enhance the common cultural pool) while making it hard for "free-riders". Using the tools offered by that alternate system, and then bow to the arguments of those who smear it seems a contradiction. You're correct that GNU and CC belong to the eco-system where sharing is the norm, but NEITHER have any objection to others making making money (yes they do both object to free-riders). CC has an *optional* clause that forbids commercial activity (I use it on my photos), and GNU forbids charging for THE SOFTWARE. But CC doesn't forbid commercial activity by default, and GNU permits charging for services, such as supplying the software, supporting the software, and anything like that. Cheers, Wol
Re: registering a composition
On 23/05/2020 20:21, Valentin Villenave wrote: I’m not saying the world is a nice place (it isn’t); you should, at the very least, secure*your* copyright by having a solid proof of anteriority, as we discussed. What I’m saying is that you shouldn’t overestimate the possible threat to your work if you were to publish it freely, nor the amount and quality of “protection” you’ll get from any RMO out there. for the sake of a few pennies, there's an easy way to prove the date. Used, I believe, by some law firm in America for its legal documents, and easy enough to do here in England too. Put all of your stuff on a CD. Now run a program that generates an MD5 checksum or whatever it is, and save both the command and output to a text file. (I'd throw in a listing of the CD too.) Print this, as an advert, in a legal newspaper such as - in London - Lloyds Gazette. That CD can now be copied freely, the MD5 sum won't change. And the advert proves that it was in existence on the date of the newspaper. You don't even need to save a copy of the newspaper - the fact that it is a newspaper of legal announcements means that there will be loads of copies kept, probably a lot of them by courts themselves! Cheers, Wol
Re: registering a composition
On 24/05/2020 11:59, David Kastrup wrote: Wols Lists writes: On 24/05/20 01:08, Carl Sorensen wrote: Actually, GNU allows charging for the software. From the Preamble to the GNU GPL: "When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish)" You have freedom to charge for the SERVICE of DISTRIBUTING the software (which I said :-), not the freedom of charging for the software itself. That is like saying I can charge for the service of distributing the contents of a book, not for the contents themselves. Exactly so - you are charging for the service of putting the words on paper, and for the paper and postage etc etc. What is the "contents themselves" without a means of dissemination, a medium? You are not charging for the words themselves, and more importantly, you are not charging for work of arranging those words in that specific order! Yes, I know I'm being pedantic, but when you're dealing with the law pedanticism matters :-) (GPL v2 contains some bugs, and some people actively exploit those bugs as features ...) A license does not contain "bugs". Pedanticism does not mean using words with a different meaning than anybody else. It means using them more carefully according to their agreed-upon meaning. So you don't understand the difference between the story, and the book? If I walk into a bookshop, the could easily be a shelf that has just one story on it, "The Half Blood Prince" lets say. There could be three or four different editions, and maybe 10 copies of each. BUT THERE IS ONLY ONE STORY. In the same vein, I can take GPL software written by other people, create my own edition, and copy it on to CD. I can sell that CD, charging for for the physical embodiment and my work in creating said embodiment, but I cannot - MUST NOT - charge for the software itself. That is basic GPL 101. As for bugs in the GPL, are you saying that software doesn't contain bugs? Just as software DOES contain bugs, so do legal documents, including the GPL! And whether you call them bugs or features, I can list at least two bugs in v2, which v3 was intended to correct. Bug 1 - the revocation of the licence - can you cure a breach of v2 by simply downloading another copy? PEOPLE ARGUE - WITH REASON - BOTH WAYS. The new language in v3 makes it quite clear that you can't get round a revocation by obtaining a new copy, but also that if you do try and comply with the licence in good faith then it isn't revoked. Bug 2 - if you make software available on the web as two separate archives, one binary and one source, this triggers the binary distribution clause of v2. So if I make the source available, and offer a pre-compiled binary as a convenience, I'm forced to keep the source available for three years? THAT'S NOT FAIR. So v3 makes it clear that if *you* *choose* not to avail yourself of the source at the same time as the binary, then it's *your* problem - you can't come back to me later and demand the source. These are bugs, according to the authors of the GPL, hence v3 aiming to correct them. Cheers, Wol
Re: Getting started with Scheme
On 23/05/2020 11:37, Kevin Barry wrote: My copy of windows doesn’t have a*Start* menu: so that’s another instruction that is meaningless. OK. Is there a common way to accomplish the old Start -> Run -> type in the name of a program? Windows 10 has a (sort of) start menu - click on the windows icon in the bottom left. This brings up a search bar, into which you can type a program name. It's a complete pain in the arse because it seems to think you want to do everything on the web, but you can force it to search your computer, not everyone else's ... If you just want to run a program that's in your search path, it's been the same since Windows 7 or even earlier - -R. Cheers, Wol
Re: Harmonics in tablature
On 29/06/2020 10:30, Valentin Petzel wrote: 3) Forcing a string number can be done manually easily (though this is not good if the tuning changes at some point). But in code it is quite a bit more effort to achieve the same result, because we then would need to read the string tunings from the context and determine for each single note on which string that is. By simply setting minimumFret to an appropriate value (sorry again), we can achieve the same result without coding the same thing multiple times. Only problem is that doing it this way will override minimumFret directions done before. Not that I have a clue what you're talking about here but ... You're aware that it's not uncommon to play lute music on guitar? And that guitars are then tuned to lute pitch with the 3rd g string tuned to f#? And I occasionally play harmonics on a fretted not open guitar string. (Off-topic - I went round my Aunt's once and she showed me some music her guitar teacher had given her, saying it was really hard. I spotted it was lute music and said I thought I could sight read it. She was amaZed so I retuned the guitar and struggled through it. So that was a trick she taught her guitar tutor ...) It sounds to me like this might impact what you're doing (or it might not). Cheers, Wol
Re: Naming RFC: Properties, property sets, presets
On 15/07/2020 12:08, Urs Liska wrote: Out of curiousity: How do you feel about the use of "preset" in synthesizers, radios or audio processors like equalizers or effects (to name just a few I know of)? As I understand what's going on, a preset with synthesizers et al is a "preset list of defaults", ie if I select a preset, it sets EVERYTHING up. As I understand your usage, you have what I think of as a preset, and then you are applying what you call a preset, that modifies SOME of the settings. It's that that's jarring - to me a preset is an initial setup that you can modify. As I understand you, you're using it as a bunch of settings that change part of an initial setup. I'm not saying your usage is wrong, it's just that what is correct and what people actually do doesn't always match up ... :-) Cheers, Wol
Re: What happened to INSTALL.txt?
On 30/07/2020 17:25, H. S. Teoh wrote: On Mon, Jul 27, 2020 at 08:30:34AM -0700, Knute Snortum wrote: Well it looks like README.git should just contain this: Instructions for compiling LilyPond from source files can be found online at: [1]https://lilypond.org/doc/v2.21/Documentation/contributor/index_17#Compiling Sounds like a good idea. Does it? You're assuming internet access ... :-( Okay, most people will have it, but not all, and if all it needs is to run ./configure, then that's what should be in README.git. Chers, Wol
Re: macro for \once\override
On 28/08/2020 20:42, Werner LEMBERG wrote: Well, we have to make a compromise. The PDF document has a small line width, and you can't scroll horizontally... Theoretically, the snippet could be printed with a smaller font size, but this doesn't look very pretty IMHO. I consider the `\oo` shorthand both innocuous and simple enough for a snippet. My preference is the one that you said is inappropriate: \once \override Very.Long.Grob.PropertyToBeChanged = foo If we introduce oo, then that adds extra lines to the snippet, and it confuses the override (which is the purpose of the snippet) with the convenience function (which is not necessary for the operation of the snippet). If you have to split 20 very long `\once\override` line this way, it's (a) very hard to read, and (b) much longer than the few lines introducing the little function. I think that the benefit of the improvement in the typography is outweighed by the increased difficulty of understanding the snippet. I disagree. There are snippets with *extremely* sophisticated Scheme code. What I'm going to introduce is very basic. Complex or basic, if it's extraneous to the example, then you don't want it. And especially, if the intent is show the use of \once \override, using an abbreviation for it obscures the whole point of the example. Some of us have great difficulty getting to grips with Scheme :-) ANY use of it unnecessarily is an obstacle to understanding, sorry. Cheers, Wol
Re: Dynamics context
On 07/09/2020 17:01, Martín Rincón Botero wrote: I wanted to ask if using the Dynamics context is the simplest way available in Lilypond for achieving this kind of vertically aligned dynamics. The huge drawback of the Dynamics context is that it disrupts the syntax, since dynamics can’t be used next to the first note they’re attached to, but instead they need a separate variable, reducing readability of the actual “music”. Just to throw my two-pennorth in, while I didn't know about the dynamics context, I've started separating dynamics out ... I do band parts, and if the dynamics are replicated across, say, all trombones I find it easier to have the notes in one variable, the dynamics in another, and to merge them for each part. Especially as, although I haven't really been doing scores, I can then merge all the trombone parts, and the dynamics, to put them on one line of the score. It's not unusual for different instruments to have different dynamics, as usually the cornets have the melody in the first section, then the bass instruments in the trio, often with the middle instruments such as trombones and euphs having a middle section. So whoever's got the melody might be ff, with the others p underneath. At the end of the day, horses for courses and if it doesn't work for you then fine. But it does work for people like me :-) Cheers, Wol
Re: adding chordmode chord modifiers
On 08/09/2020 03:21, Randy Josleyn wrote: (By the way, I switched to a daily digest for lilypond-user emails and I'm not sure about how replies work from them. I've made mistakes with how replies to a list work before, so I apologize if I've done it again.) I don't know how it works, but I know one email client I used had the ability to receive a digest and break it up into individual emails. Or do what I do and just have rules that filter lists into their own folder. You can then go in when you want to peruse them all one by one (little hint - turn off email notification then you're less tempted every time one comes in :-) Cheers, Wol
Re: Forzando in Lilypond 2.20
On 01/10/2020 19:27, Carl Sorensen wrote: Variables can only be defined at top level, not inside a score. https://lilypond.org/doc/v2.20/Documentation/notation/file-structure I just shove all of this sort of stuff in an include file, and include it at the top. I've come across things like sffz and so on, so as I come across them they go in this include file and they're there for next time I need them. Cheers, Wol
Re: Forzando in Lilypond 2.20
On 03/10/2020 03:32, Mike Dean wrote: Not really sure how to get the fermata over the repeat bar line rather than over the clef on the next line Isn't this the default behaviour of \uFermata and friends? Sorry I can't from memory be more specific, but I know my battle with fermatas was getting them to go over notes, rather than sticking themselves ove barlines where they wanted to be ... Oh - just noticed you said "on the next line" - which might be the problem - it's put it over the "start" of the bar rather than the end. That might be a fruitful line of enquiry ... Cheers, Wol
Re: Repeated durations: pitches vs rests
On 22/02/2021 06:02, Andrew Bernard wrote: Its not a bug. It's just the syntax. A 16 without a note will produce a note, not a rest, even after a rest. There would be a dozen different possibilities for syntax, but that's how it is. Principle of least surprise. As a player, a rest is a note without sound, as a programmer I think it should go back to whatever was most recently made explicit (ie the rest). Is it that hard to make the computer program emit an r for a rest? People don't normally put ties on rests - does not quite make sense, as a ties means hold the note and don't articulate, whereas silence cant be articulated anýway. How easy is it to make the program just not take advantage of this shortcut? Just emit the note every time. I've been using lilypond for over 15 years and I think this is a pretty recent addition. Andrew Cheers, Wol
Re: Guitar Tab / Bends
If you're into guitar stuff, there's something else you might be interested in cleaning up and getting working ... I wrote a capo feature, but it sort of fell by the wayside. If you're using chord notation, it puts "Capo G" or whatever at the start of the piece, and transposes the chord and puts it in brackets after the main chord. I think I can find it and pass it over to you - I'm sure I've got the patch files, and the feature branch is, I think, still there but moribund - if you search for "guitar capo" on the list, you might find it. As I remember it really just needs cleaning up - unfortunately my scheme-fu wasn't up to it. Cheers, Wol On 12/03/2021 02:56, David Stocker wrote: I will look into this and read back up on the contributing docs. It's been a while, but since I do software every day now, I hope learning will be quicker! (probably not 😉) On 3/11/2021 5:50 PM, Federico Bruni wrote: This is a great news! Yes, the development is still active. I guess you'd better subscribe to lilypond-devel for questions about development. Can I suggest something to work on? :-) You may remember that Marc Hohl bend.ly file had bending notation for both Staff and TabStaff. Harm's implementation is more powerful.. see this commit: https://gitlab.com/lilypond/lilypond/-/commit/376a8c362fea5b754ff383dd62f2664f8dea13bb but it lacks the bending notation on Staff.
Re: why Kieren is a \relative evangelist [was “Re: Nested transposition"]
On 17/03/2021 08:23, Michael Gerdau wrote: I don't have any of the show stopper Kieren is so evangelistic about and very clearly find \relative easier to enter via a normal keyboard by a long shot. Entering all those "'" (requires SHIFT on a german keyboard) and "," is not at all fluent. Well, I'm a "hunt-n-peck" one-fingered pianist, so I guess I'd find using a midi keyboard MUCH harder than a computer one (as a guitarist, I found that was great for improving my typing skills :-) imho the near universality of keyboard competence defines Western Music as "can be played on a piano" and has severely damaged our understanding of what music actually is. Musicians like me who can't play piano are very rare ... And why would a copyist be able to play keyboard? I also find reading \relative much easier but that my be depending on what you're used to. likewise I seldom use transpose and I know of no case where I have nested transpose. With unnested transpose I have not yet had a problem. And frescobaldi does very easily transform from \relative to \absolute, should I ever need it. Well, as a trombonist who plays in both brass and concert bands (and used to play in an orchestra), I use transpose all the time, and never had any trouble. Therefor my conclusion is: Kieren surely has good reason to prefer \absolute, but deriving that \relative is inferior and should be avoided is overdoing it IMO. Agreed. Okay, my instrument wouldn't use much by way of octave modifiers, but I'd hate to be writing a piccolo trumpet part ... Cheers, Wol
Re: why Kieren is a \relative evangelist [was “Re: Nested transposition"]
On 19/03/2021 16:43, H. S. Teoh wrote: It's somewhat mitigated by inserting octave checks every so often (say, at the start of every section), so that when it does go wrong, there's a warning, and the problem only propagates up to the next octave check rather than the rest of the piece. :-) And Han Wen wrote the original octave check for me! Because I think I had exactly the problem Kieren is moaning about - I put a fragment of music in a variable, and because it started and finished over a 5th apart, I had great difficulty getting the phrase to repeat correctly. That was back in the 2.4/2.6 days ... Cheers, Wol
Re: AW: Custom Format
On 31/03/2021 20:20, Callum Cassidy-Nolan wrote: You are correct, there is no distinction between these two notes, because in terms of pitch they are the same. Actually, they're not ... If you're talking about "well-tempered" instruments - basically keyboard - then IN PRACTICE they are the same note, but the whole well-tempered system is a bodge to make sure instruments sound "okay" in any modern scale. As soon as you move to instruments capable of playing any pitch (the violin family, the trombone family, probably others I've missed) or "bending" notes - basically all the wind instruments - then you'll find they tend to play circle of fourths or fifths, and not well-tempered, and d# and eb are most definitely different notes (although very close). Cheers, Wol
Re: AW: Custom Format
On 01/04/2021 09:50, Kevin Barry wrote: On Wed, Mar 31, 2021 at 11:47:05PM +0100, antlists wrote: On 31/03/2021 20:20, Callum Cassidy-Nolan wrote: You are correct, there is no distinction between these two notes, because in terms of pitch they are the same. Actually, they're not ... If you're talking about "well-tempered" instruments - basically keyboard - then IN PRACTICE they are the same note, but the whole well-tempered system is a bodge to make sure instruments sound "okay" in any modern scale. I assume by "well-tempered" you mean equally tempered. Isn't Bach's 48 called "The WELL-tempered Klavier"? There seems to be a common misconception that the tuning systems that preceeded equal temperament were somehow satisfactory for a single scale, and that we needed equal temperament only to overcome that problem, but that is not the case. Even if you try to only tune the seven white notes, it is not possible to both have acoustically correct thirds and fifths. Equal temperament may have made it possible to use all keys equally, but that's not why it was adopted. Even for a single scale it is better than the alternatives. That's why, as soon as the mathematics (root extractions) required for tempered tuning were discovered, it rapidly became the standard. As soon as you move to instruments capable of playing any pitch (the violin family, the trombone family, probably others I've missed) or "bending" notes - basically all the wind instruments - then you'll find they tend to play circle of fourths or fifths, and not well-tempered, and d# and eb are most definitely different notes (although very close). The issue of black notes is a red herring. Even if you restrict yourself to one pitch, "A" let's say, you will find that there isn't a single correct value for it. The A which is a major third above F is not the same pitch as the A that is fourth fifths (less two octaves) from F (if anyone interested is reading this, I urge you to try the math for yourself - it's usually quite a surprise to everyone the first time). So even if you just want to tune two white notes you run into problems. And here you prove my point. You seem to be talking about keyboard instruments. I play brass. There's no such thing as "well-tempered" for brass instruments - with just four or five adjustment points there's no way you can adjust the 36 or so notes that your instrument typically produces (and a good player can probably get more notes than that out of it). As for the tuning systems before equal temperament, which instruments would they have applied to? Brass, strings, which are incapable of equal temperament! Apart from the organ (which I was shocked to discover, in its MODERN form, first appeared about 600BC!!!), equal temperament appeared, I believe, at about the same time as instruments capable of taking advantage of it such as the ?clavichord, harpsichord, spinet, forte-piano etc. Cheers, Wol
Re: Concert pitch question (confused ex-tuba player)
On 17/09/2021 22:09, Kenneth Wolcott wrote:
I know, as an ex-tuba player (and a very low-level amatuer tuba
player), that tuba and trombone (bassoon?) don't require transposition
as they are already in concert pitch (I never played a tuba in the key
of C, F or Eb).
Tuba and trombone don't need transposition? OH YES THEY DO!
I believe (or rather, I know for the trombone and believe for the tuba)
that in the ORCHESTRA they are written in bass clef in concert pitch. So
an orchestral trombone is a "Bb trombone in C".
But in a brass band, they are written in treble clef, and a written C is
the instrument's fundamental harmonic, so a band trombone - despite
being the exact same instrument - is a "Bb trombone in Bb" (and of
course there's an exception to every rule - the bass trombone is
written, in concert, in bass clef!)
So the simple rule when describing an instrument is, if the note is
BEFORE the instrument name, it describes the fundamental of the
instrument - Bb trombone, Eb trombone, F horn, Bb/F trombone. If the
note comes AFTER the instrument, it denotes the note that actually
sounds when you play a written C - bass clef trombone in C plays a C
when you read a C, treble clef trombone in Bb plays a Bb when you read a C.
Note that the pitch after the instrument name should ONLY EVER be the
fundamental, or C.
As a trombone player in both brass and concert bands, who reads both
bass and treble clef, I always transpose my music on input into concert
pitch. So if I've got a bass clef part, I enclose the music in
"\transpose c c {}". And if I've got a treble clef part I enclose it in
"\transpose c'' bf {}" (that takes it down a ninth, not a second).
Then when I output it, likewise I wrap it again in "\transpose c c {}"
for bass clef, or "\transpose c' bf {}" for treble_8 clef (note I
transpose treble clef an octave and the music a second here).
> However most of the other wind instruments of an
> orchestra are not in concert pitch. So when there is a trumpet in Bb,
> it certainly is not the same as a tuba in Bb, correct? What about
> Horn in F?
APART FROM OCTAVE a trumpet in Bb IS the same as a tuba in Bb - or any
other instrument in Bb for that matter, eg clarinet.
And I can't think of anything else in F, but if a guy with a Bb/F
trombone played with the trigger down all the time, it would be exactly
the same as the horn in F.
> What happens when the overall pitch of the piece in
> question is not C Major?
Irrelevant. If I'm playing a piece in concert C, in treble clef, I have
to revert the two flats introduced by the transposition, so my music is
in the key of D with two sharps.
And bear in mind that, unlike some other music software, lilypond
"thinks" internally in terms of pitch, not "position in the scale", so
when you transpose lilypond will worry about accidentals and key
signatures. Just make sure that on output, you include the key signature
INSIDE the transpose, so that gets transposed too.
Cheers,
Wol
Re: Concert pitch question (confused ex-tuba player)
On 17/09/2021 23:11, antlists wrote:
Then when I output it, likewise I wrap it again in "\transpose c c {}"
for bass clef, or "\transpose c' bf {}" for treble_8 clef (note I
transpose treble clef an octave and the music a second here).
Whoops - should read "\transpose bf c' {}" here ... print C on the music
for a concert Bb ...
Cheers,
Wol
Re: Concert pitch question (confused ex-tuba player)
On 17/09/2021 22:58, Michael Seifert wrote: Trombone player here. You and I play instruments that are in concert pitch. This means that when you & I look at a C printed on the page, and move our fingers/slide/lips to play it, a C comes out of our horns. Nitpick here - our instruments belong to the trumpet family, not the horn ... Finally, note that trumpet players are perfectly used to this transposition, to the extent that “C trumpet” parts (i.e. trumpet parts in concert pitch) are a rarity and a nuisance, particularly if you’re not used to older orchestral repertoire. Unless you really do have a C trumpet - I believe they do exist. If you’re planning to give this part to a trumpet player, leave it as it is; they’ll know what to do with it. Horns are more used to doing weird transpositions on the fly, but “Horn in F” is still the most common, so there’s no real need to transpose this for them either. The only reason to transpose these parts into concert pitch would be to play it with other concert-pitch instruments (like other low brass players.) Note that I believe this slightly odd setup historically comes from the fact that the trombone (or rather sackbut) was written in concert because it could play chromatically since before the dawn of "classical" music, while most brass instruments could only play arpeggios until the end of the true classical era (Mozart's horn concertos were written for natural horn), and so were written in the key of C for convenience. And it is now useful in that let's take a trumpet player - they can in the middle of a piece switch between Bb trumpet/cornet, D trumpet (popular with Handel, or was it Haydn), and repiano (Eb) cornet, without having to remember which fingering goes with which written note - the music has been transposed so C is always the open note. And that's why brass bands are all written as transposing treble clef. It's normal over a career for players to switch between instruments, or play a couple of different instruments (eg Bb/Eb cornets) in a single concert. That way they don't have to relearn the fingering every time they switch instruments - and that includes the trombones! (Bass trombone excepted.) Cheers, Wol
Re: Musical Theatre-Style Bar Numbers
On 20/09/2021 04:38, Calvin Ransom wrote: Hello everyone, I’m transposing a musical theatre book and sometimes the bar numbers contain letters then go back to normal numbering. Here is an example for the Bar Numbering that I am looking for: 1 2 3 3a 3b 3c 4 5 6 Does anyone know how to do this? It is documented. Off the top of my head it's something like \mark \default % 1 \mark \default % 2 \mark \default % 3 \mark "3a" \mark "3b" \mark "3c" \mark \default % 4 Cheers, Wol
