Re: Adding a continuous drone to midi output
Hi. On Tue, 22 May 2018 17:47:35 +0100, Sven Axelsson wrote: I just tried the midi output to play back bagpipe music and was actually surprised the complex grace notes work pretty well. However, I'm wondering if there is some way to add the continuous drone to the music automatically without having to actually write them in as separate voices? I need two separate drone voices sounding the same note continuously during the entire playback. Should be possible with a little Scheme magic, right? This http://lsr.di.unimi.it/LSR/Item?id=997 answered the same question which I asked here a few years ago. Regards, Gilles P.S. I've encountered an issue where the drone stops well before the melody it is supposed to double; it occurs when there are a lot of grace notes. Regards, Sven Axelsson ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Proprietary Software term
On Tue, 21 Aug 2018 14:34:59 -0500, Karlin High wrote: On 8/21/2018 1:02 PM, Wol's lists wrote: you have to get clear in your mind the distinction between the description, and what is described. Like that French artist who made paintings of objects titled "This is not $OBJECT?" https://en.wikipedia.org/wiki/Ren%C3%A9_Magritte Regards, Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond slurs do not transfer to midi output
Hi. On Wed, 20 Feb 2019 11:37:26 +0100, Even Thorbergsen wrote: Hello Lilypond users, I cannot manage to have the use of slurs do any impact on the midi representation of Lilypond scores. I guess there is a solution to this? http://lilypond.org/doc/v2.18/Documentation/notation/the-articulate-script HTH, Gilles Best regards, Even Thorbergsen Norwegian amateur musician ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Function to add a drone staff?
Hi.
Is there a way (i.e. a function) to automatically add a
staff for a bagpipe's drone note(s)?
Up to now, I was adding a staff by hand (with a tag so it
would not appear on the printed score). But it is more
complicated than it could be since the drone does not change,
plays along the melody and stop at rests.
Here is how the code currently looks like:
---CUT---
melodyNotes = \relative c'' {
% ...
}
droneNotes = \relative c'' {
2~ |
2~ |
% and so on...
2 |
}
bagpipeOneStaff = \new Staff {
\set Staff.instrumentName = \markup \column { "Bagpipe I" }
<<
\new Voice {
\set midiInstrument = "oboe"
\set midiMinimumVolume = #0.6
\set midiMaximumVolume = #0.7
\clef G
\melodyNotes
}
\new Voice {
\set midiInstrument = "accordion"
\set midiMinimumVolume = #0.2
\set midiMaximumVolume = #0.3
\tag #'no-layout {
\droneNotes
}
}
>>
}
---CUT---
[Thus, whenever there are changes in "melodyNotes", the "droneNotes"
must also be modified...]
So, an idea would be to use the function in order to
automatically add the drone voice (second voice in the
above excerpt) with the MIDI settings, and tag, as
parameters.
Hence, the above would become:
---CUT---
melodyNotes = \relative c'' {
% ...
}
melody = \new Voice {
\set midiInstrument = "oboe"
\set midiMinimumVolume = #0.6
\set midiMaximumVolume = #0.7
\clef G
\melodyNotes
}
bagpipeStaff = \new Staff {
\set Staff.instrumentName = \markup \column { "Bagpipe I" }
<<
\melody
% I don't know what is legal syntax for the parameters
specification...
\makeDrone #'no-layout #'accordeon #0.2 #0.3 \melody
>>
}
---CUT---
Does that make sense?
Best regards,
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Function to add a drone staff?
Hello.
On Sat, 11 Apr 2015 11:19:31 -0700 (MST), Paul Morris wrote:
Gilles Sadowski wrote
It works but the sound is still cut after every bar: It looks like
no
tie was added to the last note of a bar.
What is the advantage of using "\makeOctaves" wrt having two
"\dronify"?
Hi Gilles,
You're welcome. There's no real advantage to using \makeOctaves,
just a
matter of preference on how you want to set it up. Nothing wrong
with
having two \dronify staves or voices.
OK. Thanks.
It's working for me here with simple examples like the following,
both
visually and in midi output, and in 2.18.2 and 2.19.18. Can you give
a tiny
example showing the sound being cut after every bar?
It happens when you use bar checks!
The sound is continuous without them but it would be quite annoying to
encode without their help for spotting mistakes... [I use version
2.18.2.]
In addition, the midi volume and instrument used for the drone must be
different from that of the main melody (in order not to overwhelm the
melody lines). I've been playing a little with your function but I
only
ended up being able to change all the voices at the same time. :-{
In short, those lines
\set midiInstrument = "accordion"
\set midiMinimumVolume = #0.2
\set midiMaximumVolume = #0.3
should be inserted in the drone "Voice".
Thanks a lot,
Gilles
Cheers,
-Paul
%%%
\version "2.19"
% dronify function omitted
melody = \relative f' {
c4 d r e f r g a b
c r e f r g a b
}
\score {
<<
% \melody
\dronify g \melody
>>
\layout {}
\midi {}
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Function to add a drone staff?
Hi.
On Sat, 11 Apr 2015 22:07:43 -0700 (MST), Paul Morris wrote:
Gilles Sadowski wrote
It happens when you use bar checks!
The sound is continuous without them but it would be quite annoying
to
encode without their help for spotting mistakes... [I use version
2.18.2.]
In addition, the midi volume and instrument used for the drone must
be
different from that of the main melody (in order not to overwhelm
the
melody lines).
Well, here's where the climb gets steep in trying to make this more
robust.
See below where I added a "music-filter" step that filters out the
bar
checks. This solves the bar check problem, but there will surely be
similar
things that will also need to be filtered out.
It works almost fine: no more stops between bars.
However I sometimes stumbled upon another problem: "dronified" full
measure
rests ("R") generate a bar check warning. It seems wrong because when
I
changed "R" into "r" (and touched nothing else), the warning
disappeared
(but so did the printed rests, of course).
I couldn't yet define a small example as the error comes and goes as I
add
bars to the score! :-{
These can be added just like for bar checks, but it's a tall order to
figure
out which ones to filter out and which to leave in, given the large
number
of "music types" to consider. All the different types are found in
the
LilyPond source code under scm/define-music-types.scm (I glanced
through
them, and even briefly tried it the other way around where you only
leave in
note events, rest events, and... all other seemingly relevant events,
but
this didn't work, as apparently more are relevant than I was leaving
in.)
So that's what it will take to make this robust. Alternatively you
could
just add more types to filter out as new problems come up.
You can uncomment \displayMusic (below) in order to see what's
causing
trouble and needs filtering out.
On setting the midi volume and instrument per voice... something like
what
you originally had should do the trick. Maybe something as shown
below with
separate scores for midi and layout?
Yes, this solution is quite fine.
Thanks,
Gilles
Cheers,
-Paul
\version "2.18.2"
dronify =
#(define-music-function (parser location drone melody)
(ly:pitch? ly:music?)
(let* ((melody-filtered
(music-filter
(lambda (m)
(not (or
(music-is-of-type? m 'bar-check)
;; add other types to filter out here, as
needed...
)))
melody))
(prev #{ #})
(current #{ #})
(art '())
(drone-part
(music-map
(lambda (m)
(set! prev current)
(if (and (music-is-of-type? m 'note-event)
(ly:pitch? (ly:music-property m 'pitch)))
;; change the pitch
(begin
(ly:music-set-property! m 'pitch drone)
(if (and (music-is-of-type? prev 'note-event)
(ly:pitch? (ly:music-property prev
'pitch)))
;; add tie to previous note
;; avoid overwriting existing articulations
(begin
(set! art (ly:music-property prev
'articulations
'()))
(ly:music-set-property! prev 'articulations
(append art (list (make-music (quote
TieEvent)
(set! current m)
prev)
melody-filtered)))
#{ #drone-part #current #}))
melody = \relative f' {
c4 d r e |
f r g a |
b c r e |
f r g a |
b
}
\score {
\new Voice {
\clef G
\melody
}
\layout {}
}
\score {
<<
\new Voice {
\set midiInstrument = "oboe"
\set midiMinimumVolume = #0.6
\set midiMaximumVolume = #0.7
\clef G
% \displayMusic
\melody
}
\new Voice {
\set midiInstrument = "accordion"
\set midiMinimumVolume = #0.2
\set midiMaximumVolume = #0.3
% \displayMusic
\dronify g \melody
}
>>
\midi {}
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Function to add a drone staff?
Hello.
On Tue, 14 Apr 2015 10:51:49 -0700 (MST), Paul Morris wrote:
Gilles Sadowski wrote
It works almost fine: no more stops between bars.
However I sometimes stumbled upon another problem: "dronified" full
measure
rests ("R") generate a bar check warning. It seems wrong because
when
I
changed "R" into "r" (and touched nothing else), the warning
disappeared
(but so did the printed rests, of course).
I couldn't yet define a small example as the error comes and goes as
I
add
bars to the score! :-{
Hi Gilles, That's strange... I added support for "R"
(multi-measure-rest)
to the latest version of the dronify code (below). Maybe this will
prevents
those warnings?
Yes; that version fixes it!
Thanks a lot,
Gilles
Cheers,
-Paul
%
dronify =
#(define-music-function (parser location drone-pitch melody)
(ly:pitch? ly:music?)
(let ((art '())
(prev-note-or-rest #{ #}))
(music-map
(lambda (m)
(if (and (music-is-of-type? m 'note-event)
(ly:pitch? (ly:music-property m 'pitch)))
;; ...do note events ever not have a pitch?
;; ...are there any other kinds of events to dronify?
(begin
(ly:music-set-property! m 'pitch drone-pitch)
(if (music-is-of-type? prev-note-or-rest 'note-event)
;; add tie to previous note, don't overwrite
existing
articulations
(begin
(set! art (ly:music-property prev-note-or-rest
'articulations '()))
(ly:music-set-property! prev-note-or-rest
'articulations
(append art (list (make-music 'TieEvent
(if (or (music-is-of-type? m 'note-event)
(music-is-of-type? m 'rest-event)
(music-is-of-type? m 'multi-measure-rest))
;; ...should there be more types of events here?
(set! prev-note-or-rest m))
m)
melody)))
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
with the publishing business in general. LilyPond's capacities are great if we look at http://www.lilypond.org/examples.html If the competition does it better, nothing will change; if it does it worse, then probably, nothing will change!!! That is, until people stop buying the big houses' edition because they have come across a more beautiful rendering by LilyPond. :-) Sorry for that elaborate text, but I think it is important and hopefully fruitful. Yes it is important, definitely. Hopefully the discussion will avoid embarking on the wrong trail. Thanks for starting it. Best regards, Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Something wrong with transposing instruments? (Was: Re: Survey: Large scores)
Hi. [Sorry for the thread hijacking.] [...] Another thing: For me, also the implementation of transposing instruments is less than ideal (I prefer to write the pitches in concert pitch and have them transposed for the parts, rather than the other way around, as it is implemented at the moment). [...] Can you give an example? To my knowledge, both ways of encoding are equally simple in LilyPond. [But I perhaps I misunderstood what you mean.] Best regards, Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Something wrong with transposing instruments?
Hello. On Sun, 19 Apr 2015 10:00:46 -0400, Kieren MacMillan wrote: Hi Gilles, [...] Another thing: For me, also the implementation of transposing instruments is less than ideal (I prefer to write the pitches in concert pitch and have them transposed for the parts, rather than the other way around, as it is implemented at the moment). [...] Can you give an example? To my knowledge, both ways of encoding are equally simple in LilyPond. [But I perhaps I misunderstood what you mean.] This wasn’t from me… I know; I hadn't seen that yours was the recipient's address. And I just hit "Reply all" which usually does the right thing for a ML. [I don't see the purpose of CC'ing someone who is on the list...] but I wholeheartedly agree: Lily’s default/built-in implementation of transposing instruments is rather incomplete/poor (see, for example, <http://lists.gnu.org/archive/html/lilypond-user/2015-01/msg00201.html> and <http://lists.gnu.org/archive/html/lilypond-user/2014-05/msg00067.html> for an idea of the problems and workarounds). I believe there has been some recent improvement via openlilylib, but I haven’t had time to investigate In any case, the main distro should have much better tools to handle transposing instruments more deftly. I didn't have all the info; from the statement above it looked like the "problem" was for encoding a part of a transposing instrument whereas the links you provided point to difficulties for switching instrument within a \score. Sorry for the noise, Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
Hello. On Sun, 19 Apr 2015 21:39:29 -0400, Kieren MacMillan wrote: Hi Gilles (et al.), To whom LilyPond should strive to "offer the future”? To everyone it possibly can. ;) Yes, but we are all aware of the limited resources, and I doubt that focusing on how to please established editing houses will lead us closer to the principles and goals of free software. IMHO, certainly not to the "[...] big house[s] with traditions, regulations and limitations”. Why not? What’s to say that Lilypond can’t initially fit within those traditions, regulations, and limitations, while providing benefits (financial and otherwise) to those “big houses”, and can’t eventually help a “big house” move past those limitations while maintaining whatever traditions and regulations they see as indispensible? Your question is quite fair. But why do you ask _me_? ;-) I'd answer that, yes, they can and should use LilyPond, if they care for their business' future. The point is that _they_ don't understand, and that bright people here will (probably) waste their time trying to figure out their business case for them. Some software projects try to please their users, sometimes through decisions that could hurt long-term improvements. Even worse is giving the priority to non-users! What's for the LilyPond team in spending resources trying to work around those self-inflicted limitations? Let’s say, for discussion’s sake, we convince a Warner-Chappell, Boosey & Hawkes, or Barenreiter to use Lilypond as their primary engraving application. You honestly don’t see the potential upsides of that situation? Sure, I could imagine them. I could parallel the comparison with big companies starting to pay programmers for contributing to the development of Linux. But, actually, the situation is upside down: the Linux team did not try to please e.g. IBM; rather, IBM figured out what their best interest was. Publishers would be expected to give back if (when) they benefit financially from using LilyPond. The discussion here is that LilyPond should give even more to them, right now. Do you not remember the tipping point when OpenOffice was embraced over Microsoft Office as the official office application suite by certain governments? Again, this is different in a very significant aspect: the citizen benefit (in principle at least) when public institutions become independent of private interests (by adopting FLOSS). In this case, we consider FLOSS being adopted by a private company. I'm sure the company can benefit; I'm not sure that the public will. LilyPond is "[...] a program that creates beautiful sheet music following the best traditions of classical music engraving." (excerpt from "http://www.lilypond.org/introduction.html";) I think that this goal is way more important (to users) than trying to convince publishers. To certain users? Absolutely. To a majority of users? Possibly. To all users? Doubtful. If one goal of LilyPond was to immediately grab all users of the existing alternatives, it should have renounced to implement its way of inputting contents... It's good (for the goal of creating beautiful scores automatically) that the chosen approach was different. With the difference came incomprehension of most people who are generally averse to change, whatever the number of rational arguments you can throw at them. In any case, those aren't mutually exclusive goals. Quite the contrary: almost tautologically, the easier it is for an abstract user to “create beautiful sheet music following the best traditions of classical music engraving”, the easier it will be to convince a given publisher to become a user. I agree with the rationality of the argument: the reality is different (cf. previous paragraph), unfortunately. A project like Mutopia is a promising future I disagree rather strongly. Mutopia (at least currently) appears to me to be a rather damning example of the failure of the open-source philosophy to be able to make a broad and lasting impact on its intended market. Worse, far too many of the examples there are not, to my eye, “beautiful sheet music following the best traditions of classical music engraving”; I would, for example, never send someone there if I was trying to impress them with Lilypond’s engraving output. I meant the _idea_ of "Mutopia": a repository of free sheet music. One can rightly be disappointed that the quality of the contents does not evolve in step with LilyPond. Can it be blamed on LilyPond's shortcomings? I'd like to know what people think it would take to make the endeavour really take off. I possible, I'd rather use resources for that project. If and when "big" publishers use LilyPond, the result will be more restricted access (through cost) Cost of what? Lilypond wouldn’t ever cost any more. I didn't mean LilyPond; I meant t
Re: Do we really offer the future?
Hi. On Mon, 20 Apr 2015 09:52:54 -0400, Kieren MacMillan wrote: Hi Federico (et al.), I've thought for a long time that the right way to go is to seek public funds for engraving public domain contents Me too. I think it’s telling that most of the non-publishing music world is going in exactly the opposite direction: schools are adding “musical entrepreneurship” courses, programs, and degrees all over, in an attempt to teach musicians how to avoid the trap of relying only on public funds; and there is a significant (and mostly successful) grassroots effort to abandon the dying “not-for-profit” model of musical organziations in favour of a model where pleasing the paying audience actually matters to some extent. I started thinking about bringing LilyPond in music schools. Even though I never tried because of lack of time, I can imagine two major issues: 1. LilyPond is not considered as a professional tool because it's not used by the publishing companies. In general schools teach what the market asks. That's why I think that this effort by Urs is important. 2. Text input. Frescobaldi is doing a good job here, but still. From the [many] discussions I’ve had with music schools large and small, the second is *far* less important than the first. And rightly so: all other things being equal, higher education should be teaching students skills and tools [!!] which they can immediately apply to their careers. This cannot be the overall guiding rule, if "progress" has any value at all. Is the sole expectation, of students attending music schools, to be hired by a publishing company? Personally, I think that it is equally wrong to teach (how to become dependent of) proprietary products, the more so when a free (and more fit to the task!) alternative exists. [Cf. M$-Office versus LaTeX for typographic quality and consistency.] Unfortunately, as long as Lilypond is a pariah amongst publishers, it does a disservice to students to teach them Lilypond at the expense of other things. I might be wrong, but I think that the vast majority of music engraving software users don't make their choice based on what a publishing company uses. LilyPond is at a disadvantage mainly because of marketing reasons (and aversion to changing one's viewpoint on certain tasks). As Urs mentioned, LilyPond would be a serious alternative for new publishing houses. Teaching it is offering business opportunities for people so inclined. Best, Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
On Mon, 20 Apr 2015 10:22:23 -0400, Kieren MacMillan wrote: Hi Andrew (et al.), I would have thought that, like the invention of desktop publishing in the 1980’s, which allowed small scale companies and individuals to produce professional publications, lilypond frees composers, musicians, and engravers from the tyranny - and rejections - of the hidebound established music publishers. Why do we need Peters and Barenreiter and others? Have you seen the “graphic design” of the millions of people who bought a Mac (or whatever) and Adobe Illustrator (or whatever) and started cranking out “design”? The situation is exactly analogous in the music world: the vast majority of people (composers, etc.) *think* they know how to make a readable music score, or at least trust that Finale/Sibelius/whatever will do it for them, and the results are atrocious. Publishing houses, for the most part, are Awfulness Sieves… and as such are [mostly] necessary evils, at a certain level. My composer colleague of the New Complexity School will never be published by the Big Firms. But he will be published by me. And with the web nowadays, the big distribution networks the Old Companies have is no longer important. For better or worse, I have chosen to self-publish my own works. But I’m not deluding myself into thinking that “the big distribution networks the Old Companies have is no longer important” — that’s a fallacy, and easily debunked. It may well be that *one day* that statement will be more true than false… but we’re still at least a decade off from that Rapture, maybe more. I would like to see every engraver using lilypond I don’t really care; I only care about engraving quality. What I *would* like to see is every engraver outputting music of equal or superior quality to the scores I engrave myself in Lilypond, and that’s clearly not happening right now. If (as some have suggested) Steinberg’s pending application has output of equal or greater quality to Lilypond, and there is some reasonable way (e.g., MusicXML or MEI) for me to “own the source indefinitely”, that application's ease of use (read: GUI and other tools and workflows) could certainly sway me into abandoning Lilypond. Unlike many on this list, I have no burning need to force Open Source Philosophy on the world if it’s not willing to prove its own worth. In F - Free L - Libre O - Open S - Source S - Software the most important word is "Libre" (as in "freedom"). When people put convenience above all, they start giving up their freedom. And yes, we are heading in that direction (through lazyness, despite all the wonderful work build by the _original_ OSS movement, and the increasing availability of free alternatives). It's the wrong direction. If [established firms] need vast amounts of explaining to understand it, they simply will not get it. So true. Hence my repeated pleas to try to make Lilypond usable without vast amounts of explaining. In some sense, LilyPond is usable with a little amount of explanation. As you know, some people will turn away just because of text input, even though I'm sure that, for simple tasks, it requires less time get up to speed with LilyPond than with a GUI software. [That is, unless one insists that softwares must be usable without reading the usage instructions...] Vast explanations are needed for example when it comes to making things that are not part of the LilyPond "language". [Whenever Scheme code is part of the solution, it can never be easy from viewpoint of someone who does not know the language.] It may also be a "problem" that the software is so flexible: there are (too?) many ways to organize a large work, at which LilyPond is probably much better than the competition. Along the years, several "add-ons" (templates, makefile, scripts, snippets) have been mentioned here but, unless I'm mistaken, they didn't yet evolve into a compelling "standard" set of files with features that would cover most needs. As a concrete example, I'd favour recommending that _any_ piece of music (small or large, it does not matter) be encoded in files that separate layout from contents; the official documentation provides templates where everything is in a single file. Best regards, Gilles Cheers, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [OT] Re: Do we really offer the future?
Hi. On Mon, 20 Apr 2015 14:18:19 -0400, Kieren MacMillan wrote: Hi Gilles, On Apr 20, 2015, at 1:19 PM, Gilles wrote: When people put convenience above all, they start giving up their freedom. My experience — this thread being no different so far — is that such discussions always end up in absolutist terms (moral and otherwise). It’s almost a defining quality of the FLOSS movement, from what I can tell. Ultimately, such positions are neither realistic, nor productive, nor particularly interesting to me (or many other people I know). I don’t grow my own food, because buying my food — even the organic food I purchase regularly, in person, from farmers I know by name — is not only more convenient, but also cheaper and more freeing than growing, harvesting, and processing it myself. That freedom allows me to do other things that are more important to me, like composition, and using Lilypond to engrave my compositions, instead of heading out at 5AM to feed and milk my cows before the hard 16-hour day tending my subsistence crops. I don’t put convenience above all; I make choices that make sense to me and those around me, in my real-world life. Your earlier comparisons were not really applicable to the situation discussed in this thread. This one is completely off-topic (as you correctly indicated in the subject line) if it purports to argue against something I wrote. I stated explicitly in my previous post what aspects would perhaps be worth working on (IMHO). Because I'm just a little user, and grateful for what the software can do, I always felt I should not complain about such shortcomings, as long as I did not have the time to contribute more productively. As the question was asked on this forum, I felt I could provide my opinion that some effort might be misplaced if its sole purpose was towards improving the publishing business. My opinion is that the future should not be that. The publishers indeed (also) do not care about the real-world principles (free access to culture in this instance) which a FLOSS like LilyPond can help achieve (within their obviously limited sphere). Not that they oppose it, it's simply not their business (which is selling printed scores). They have the right to use the software, like any of us. The point is that they don't want to. Several possible reasons were given by other people in this thread. Of course, you are free to pursue your effort with the publishing houses, despite the preference of some of your fellow LilyPonders... :-) Regards, Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: mutopia's shortcomings
On Mon, 20 Apr 2015 19:07:46 -0400, Kieren MacMillan wrote: Hi all, Seems to me it has been quite successful in its goals of making sheet music easily available for free, all works in the public domain or under creative commons licenses, in (user-editable, user-improvable) LilyPond format, pdf, and midi — all with volunteer labor. Looks like the total is over 1900 works now. Other than the “user-editable, user-improvable” issue, all of those things are far better done by IMSLP. Put another way, looking at IMSLP (with 310,000 scores) and Mutopia (with 1,900), the shine quickly comes off Mutopia for anyone except the handful of hardcore DIY musicians who (e.g.,) want to take a violin piece from Mutopia and make a guitar arrangement. I think it would be far better — and probably result in better visibility/marketing for Lilypond — if Mutopia were merged into IMSLP. (There appears to have been a thought in this direction at some point, but not any more; cf. http://imslp.org/wiki/IMSLP:Community_Projects/Mutopia_score_archive). Then, for important works, there would be the Lilypond source, side-by-side with scans of existing editions. But it seems this was considered, and rejected for exactly the reasons that Mutopia now flounders (cf. http://imslp.org/wiki/IMSLP_talk:Community_Projects/Mutopia_score_archive). Some pieces accessible on IMSLP were typeset for Mutopia, with a "publisher" link to Mutopia's site. So visibility of LilyPond can be achieved through publishing to IMSLP in addition to Mutopia. On Apr 20, 2015, at 5:58 PM, Simon Albrecht wrote: I think it’s mainly three problems: – Lilypond versions, as Paul already mentioned. Yes. – Coding style: the lilypond code I saw till now from Mutopia mostly gave me a real headache, because it was excessively hard to read, inefficient or hacky. Which makes reusing it an unpleasant experience. Yes. I would call real code reuse — certainly anything other than the most trivial cut-and-paste exercise — essentially impossible. – Visual quality of the output: Many of the scores very effectively display that using Lilypond does not warrant making beautiful scores Yes. Urs and I are hoping to change this (dramatically, for the better, in one fell swoop) with the openLilyLib stylesheet project. But for now, the defaults in Lilypond are far from publication quality (IMO). A word like "stylesheet" looks promising. I looked at the "openlilylib.org" web site but could not find the stylesheets. All the problems with Mutopia stem from not having a standardized way of managing the layout and contents. Mutopia should not be like IMSLP; rather it should be a database of LilyPond input format (the _music_ part). With standard stylesheets, one would be able to automatically update/adapt the contents. Of course, the devil is in the details... :-} Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
On Mon, 20 Apr 2015 11:50:24 +0200, Federico Bruni wrote:
2015-04-17 16:45 GMT+02:00 Gilles :
A FLOSS like LilyPond is a great opportunity to share (musical)
culture, at the lowest possible cost.
A project like Mutopia is a promising future: digital scores (of
public
domain music) that are free of publishers' rights.
If and when "big" publishers use LilyPond, the result will be more
restricted access (through cost) to culture (because they won't
release
their proprietary contents).
I've thought for a long time that the right way to go is to seek
public funds for engraving public domain contents with the purpose
of publishing it under a GPL-like (or Creative Commons) license.
Me too.. but unfortunately it's not a good moment to seek public
funds. And
I don't like much having to deal with public istitutions.
Whether or not funds will be obtained is a question that comes only
after people at various levels are made aware that LilyPond exists.
This perhaps requires a showcase especially crafted for convincing
this particular audience...
I would prefer if more people were able to use LilyPond and learn to
have
fun and learn and help others while contributing to Free Culture.
That's
why I started thinking about bringing LilyPond in music schools. Even
though I never tried because of lack of time, I can imagine two major
issues:
1. LilyPond is not considered as a professional tool because it's not
used
by the publishing companies. In general schools teach what the market
asks.
That's why I think that this effort by Urs is important.
2. Text input. Frescobaldi is doing a good job here, but still..
What I had in mind was creating the scores which music schools use
for teaching music (solfege and instrument). Here, (public) music
schools were forced to pay publishers a yearly contribution under
threats of legal action against them because of their use of
photocopies, even though most of the copyrighted material being
copied is actually based on public domain contents ("classical"
music).
Regards,
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
On Mon, 20 Apr 2015 20:19:37 -0700, Jim Long wrote: On Fri, Apr 17, 2015 at 04:45:20PM +0200, Gilles wrote: If and when "big" publishers use LilyPond, the result will be more restricted access (through cost) to culture (because they won't release their proprietary contents). Forgive me if I've missed important bits of this conversation, but I'm not I understand your point here -- can you expand on this statement? Why do you feel that large-scale adoption of OSS (in general) will restrict and increase the cost of cultural access? You are right, the sentence was not clear. I certainly did not want to mean that general adoption of OSS will have bad side effects.[1] Here I just meant that when publishing companies create new editions of out-of-copyright contents (e.g. works composed more than 100 years ago), the editing work is under copyright (and rightly so) and they choose the license (and rightly so). I just doubt that they will settle on something like "Creative Commons".[2] What I meant is that if the work is edited and published by a public institution, it should[3] be released under a protective license.[4] LilyPond makes that endeavour possible.[5] Regards, Gilles [1] Although the license question is a central issue, unless one does not care how the software is used (in the real world). [2] I don't imply that all music should be given away for free: Contemporary composers create contents and have all the rights to publish under whatever license suits them. [3] That's what I consider the duty of "public" service (that works thanks to the public's contribution). [4] That allows free usage and has some provision to discourage "free rides". [5] Because it is free software, the data (music contents) does not risk getting stale and the printed output will always be as beautiful as the version of LilyPond could make it at the the time of the encoding (assuming that computers, PDF readers, and printers are still available in the future). ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: best practices for volta (was Re: Problem with repeat, alternative endings that contain lyrics andleading rests)
Hello. [...] MIDI is widely acknowledged to be a relatively unimportant part of LP [...] I hope there is no intention to drop the MIDI output. For me, it is extremely useful to be able to figure out how an arrangement will sound. With all its shortcomings, it's still infinitely better than nothing. :-) Best, Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Is GridLY the future? (Was: Do we really offer the future?)
Hello. I think you could vastly benefit from using openLilyLib's GridLY library. Of course thst's only viable for new projects. That looks interesting just from a quick reading of https://github.com/openlilylib/openlilylib/tree/master/ly/gridly I stumbled upon that page only through a web search... The "openlilylib" web site refers to github but then it is not clear what functionality can be found there and how to install and use it (the links of the examples at the bottom of the above page point to nowhere). Is this something to be included in LilyPond at some point? If not, why? Thanks, Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How do new users feel about LilyPond's documentation?
Hello. On Wed, 22 Apr 2015 21:19:12 +0200, N. Andrew Walsh wrote: I started using Lily for serious maybe a month ago, so I'm what you'd call new. I find the guide far more useful than the manual (the former seems more structured around how to do specific things, while the latter seems much more a general conceptual introduction). However (and this is something I mentioned on a couple recent message exchanges), I feel that neither one of them gets me very far past making a single monolithic file using defaults. There's been a lot of mention (I imagine rightfully) about how Lily is capable, above all, of making beautifully engraved scores, and her suitability to managing a text-based, distributed, and version/change-tracked workflow. All of that sounds awesome, but I don't see anywhere where that's comprehensively documented. Let's take my case: I'm transcribing masses from some obscure composer from the 18th century. There are no extant scores, only the parts (which ironically works better for Lily's structure). I want these scores to look their absolute best, and the underlying files to follow the best practices for structure and organization. I want to put the score and parts alongside the work of a commercial (read: Sibelius-using) house and have it be unambiguously a better-looking and standards-conforming result, and be able to show the incredible flexibility and rigorous flow-control that using the underlying system can offer. I don't see anywhere in the reference or the manual where that sort of comprehensive style guide is presented. I'm thinking something like the doorstops O'Reilly's uses for documenting, say, HTML. I hate to use the term (it's already been ruined by bureaucrats), but what I'm really looking for is a comprehensive "best practices" style guide for how to organize larger scores. Best practices, yes; for any score (not just large ones).[1] A flexible structure that would be "compelling" and foster the creation of "compliant" tools. Is it GridLY? [Cf. other post.] Regards, Gilles Urs, I think this would probably dovetail nicely with your efforts to build a pool of competent engravers, as we would then all be working from the same style guidelines. But that's just my use-case. Maybe there are others? Cheers, A On Wed, Apr 22, 2015 at 9:03 PM, Urs Liska wrote: Am 22.04.2015 um 20:48 schrieb Federico Bruni: Hi Abraham I've been using LilyPond since 6 years. I think that LilyPond documentation is great. Learning Manual is a gentle introduction (basically 3 chapters only) for new users and Notation Reference is a complete reference, well indexed and easy to search through. I never found anything better (which is as complex as LilyPond). I am quite in line with that impression. I don't think the *documentation* can be *much* better in general. However, there are a few things that would help new users (I think it would be very good if some of these could also comment on this thread). It would be helpful if there were more learning material that has a slower pace and into more depth at explaining things than the notation reference. The Learning Manual is very good, but when that's finished people are not ready to walk alone. That's what I intend with the tutorials section on the blog, but of course these posts are only drops in the ocean. But better than nothing. I could also see something like a community book emerging from these tutorials, but I'm not sure how well this would work out. Urs 2015-04-22 17:09 GMT+02:00 Abraham Lee : All, I've been thinking about this a lot lately, even going so far as to create my own "Quick Start" tutorials for new users, but I can only go so far in my own head. I really have two questions that I keep wondering about: 1. What is the thing you (especially new users) like the least about LilyPond's documentation structure? 2. If you could have the same documentation structure as found in another notation program, which program is it? Or put another way: Is there a notation program out there that has a documentation structure you like? 1. The missing connection between input and output, in other words something similar to the experience of point-and-click in an editor. Yes, this is not about structure. I think that structure of NR is Ok. Also, syntax highlighting would help readability: https://code.google.com/p/lilypond/issues/detail?id=2578 https://code.google.com/p/lilypond/issues/detail?id=1005 2. no idea 1. I'm asking this because I'm trying to determine how we in the 'Pond can make it easier for new users to jump in with both feet instead of dipping a toe and getting scared of the deep. I may be over-thinking this, but I keep getting the feeling that people are sc
Standard LilyPond score structure (Was: How do new users feel about LilyPond's documentation?)
Hello. [Changing subject line; so many different topics in a single thread...] On Wed, 22 Apr 2015 19:14:15 -0400, Kieren MacMillan wrote: Hi Gilles (et al.), Best practices, yes; for any score (not just large ones).[1] A flexible structure that would be "compelling" and foster the creation of "compliant" tools. I have a pretty rich imagination, and I can’t begin to conceive of a Lilypond best practice [singular] or flexible structure [singular] that could possibly satisfy both a newbie who wants to quickly output a 32-bar lead sheet with chord symbols and a power user who wants to manage a crowd-engraved critical edition of “Porgy & Bess”. Yet you long for that would know how to remove a set of bars from "That Production" project. :-P A tool could do that *if* it knew what structure to expect. [Like if each note would be in a database table where one of the attributes is the bar number...] The various GUI applications do just that: they decide on a structure so that they can represent it graphically. By default, standardization is a Good Thing. It should not be the case that simple scores have a structure that becomes hugely inadequate when more contents is added. As I mentioned already, several "project managers" were referred to here along the years. But they had always the same fundamental problem as was raised in a recent post: they were designed outside official development. Hence, however powerful, they never became "standard". Best regards, Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
What is the problem with "\relative"? (Was: Do we really offer the future?)
Yet another subject ;-) [...] Yet another reason to deprecate \relative, which I now avoid like the plague. (Unfortunately, I was suckered into using it when I started using Lilypond over a decade ago, so all my legacy code is in \relative mode. Using Frescobaldi, I’m slowly converting all my old code to absolute mode.) Why? Thanks, Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Standard LilyPond score structure (Was: How do new users feel about LilyPond's documentation?)
On Wed, 22 Apr 2015 21:53:42 -0400, Kieren MacMillan wrote: Hi Gilles, Yet you long for that would know how to remove a set of bars from "That Production" project. :-P A tool could do that *if* it knew what structure to expect. I don’t believe that’s necessary… but we can leave that aside for now, since the technical investigation required to determine whether my intuition is correct isn’t worth it at this stage of the discussion. For sure, it is not necessary: LilyPond itself should be able to do it since it obviously has to know at some point which part of the input will end up in which bar. By default, standardization is a Good Thing. I agree 100%. (But, as an aside, many people wouldn’t!) It should not be the case that simple scores have a structure that becomes hugely inadequate when more contents is added. So, to output a simple 16-bar lead sheet, a user should always [be forced to] create 3 files (voice.ily, chords.ily, score.ly)? Or maybe four (lyrics.ily)? Or more? Because a “one-per-instrument” file structure — or something equally segmented in some other way — is likely necessary (or at least desirable enough to be chosen as the standard) for a huge project like an opera. Yes! :-) But once there is a standard, many tools will blossom, in particular one that would offer "simple layout" and transparently transform into "standard layout"... Or more probably a user that is too lazy to set up one directory (rather than one file) for a given project is likely to use a GUI in the first place and will never ever see the multi-file standard layout. Regards, Gilles Best regards, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
"Instrument" as first class citizen (Was: ...)
On Wed, 22 Apr 2015 19:17:53 -0700, Flaming Hakama by Elaine wrote:
[...]
Without getting too technical, objects are things that you can
create, have
properties and relationships with other well-defined objects.
This is true for things like staves, staff groups, scores, books,
etc.
You can say: \new Staff = { ... } to create a new staff because
there is
an object class called Staff that is well-defined.
It has known properties like Staff.TimeSignature, Staff.extraNatural,
etc.
Other objects (Staff Groups, Books, etc.) know how to handle this
Staff
object, or several Staff objects.
However, in the case of "instrument", there is no such object so you
cannot
create one.
There are certainly properties of other objects (namely, staves) that
have
"instrument" in the name, like Staff.instrumentName,
Staff.shortInstrumentName, Staff,midiInstrument.
However, these are *properties of a Staff object*.
There is no way to create an "instrument" outside the context of a
staff,
or identify or change its properties.
You cannot add an instrument to a staff or any other object.
If there were, the syntax might be more like:
violin = \new Instrument {
Instrument.name = 'violin'
Instrument.shortName = 'v.'
Instrument.midi = 'violin'
Instrument.clef = treble
...
}
\new Staff {
Staff.Instrument = \violin
\violinMusic
}
From the viewpoint of the encoder, this is quite sensible.
This would be a nice syntax simplification.
Best,
Gilles
As an aside, an outstanding problem with lilypond is that it is
difficult
to write multi-instrument parts.
This points to a lack of clarity of design around the distinction
between a
voice, instrument and staff.
At its core is the lack of a coherent concept of instrument.
Which is to say, while you might point to the Staff as the place
where most
instrument information is situated, Staff and Instrument are clearly
not
identical concepts, nor is Instrument a proper subset of a Staff.
Perhaps the reason there is no such Instrument object in lilypond is
that
an "instrument" is not a grob.
There is no place that an "instrument" appears on the page, except as
a
label for a staff.
Yet, for the purpose of this discussion, it is clear that everyone
thinks
in terms of "instruments".
So, the documentation ought to explain exactly how this commonsense
conceptual notion of "instrument" maps to the actual objects and
properties
that are available.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Standard LilyPond score structure (Was: How do new users feel about LilyPond's documentation?)
On Wed, 22 Apr 2015 19:39:25 -0700, H. S. Teoh wrote:
On Thu, Apr 23, 2015 at 04:19:08AM +0200, Gilles wrote:
On Wed, 22 Apr 2015 21:53:42 -0400, Kieren MacMillan wrote:
[...]
>So, to output a simple 16-bar lead sheet, a user should always [be
>forced to] create 3 files (voice.ily, chords.ily, score.ly)? Or
maybe
>four (lyrics.ily)? Or more?
>Because a “one-per-instrument” file structure — or something
equally
>segmented in some other way — is likely necessary (or at least
>desirable enough to be chosen as the standard) for a huge project
>like an opera.
Yes! :-)
But once there is a standard, many tools will blossom, in particular
one that would offer "simple layout" and transparently transform
into
"standard layout"...
Or more probably a user that is too lazy to set up one directory
(rather than one file) for a given project is likely to use a GUI in
the first place and will never ever see the multi-file standard
layout.
[..]
I beg to differ. I do not use a GUI (and never will, for lilypond),
yet
I have found (so far) that I prefer the single-file approach. At
least,
I've found it quite manageable so far for single-movement pieces.
[...]
Of course, if you are used to it, nobody forces you to change.
The suggestion was certainly that LilyPond should forbid all input
other than the "standard" ("best practice") layout.
[Yet I want to stress that what you seem to describe is exactly what
a LilyPond GUI would do; I mean that the GUI designer has chosen a
structure (like you did) so that the code knows where to fetch and
to put things. You do it "manually".]
Everything in one file is not a solution that can scale (e.g. for
large, possibly distributed, encoding projects).
Best regards,
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: "Instrument" as first class citizen
On Thu, 23 Apr 2015 09:50:05 +0200, Xavier Scheuer wrote:
On 23 April 2015 at 04:28, Gilles
wrote:
On Wed, 22 Apr 2015 19:17:53 -0700, Flaming Hakama by Elaine wrote:
[...]
Without getting too technical, objects are things that you can
create,
have
properties and relationships with other well-defined objects.
This is true for things like staves, staff groups, scores, books,
etc.
You can say: \new Staff = { ... } to create a new staff because
there is
an object class called Staff that is well-defined.
It has known properties like Staff.TimeSignature,
Staff.extraNatural,
etc.
Other objects (Staff Groups, Books, etc.) know how to handle this
Staff
object, or several Staff objects.
However, in the case of "instrument", there is no such object so
you
cannot
create one.
There are certainly properties of other objects (namely, staves)
that
have
"instrument" in the name, like Staff.instrumentName,
Staff.shortInstrumentName, Staff,midiInstrument.
However, these are *properties of a Staff object*.
There is no way to create an "instrument" outside the context of a
staff,
or identify or change its properties.
You cannot add an instrument to a staff or any other object.
If there were, the syntax might be more like:
violin = \new Instrument {
Instrument.name = 'violin'
Instrument.shortName = 'v.'
Instrument.midi = 'violin'
Instrument.clef = treble
...
}
\new Staff {
Staff.Instrument = \violin
\violinMusic
}
From the viewpoint of the encoder, this is quite sensible.
This would be a nice syntax simplification.
Actually there is the \addInstrumentDefinition command (used in
combination with \instrumentSwitch) which does *part* of that.
IMHO, a list of all instrument definitions would be useful.
Perhaps in individual files for inclusion ("violin.instrument.ily")
and files of families ("strings.family.instrument.ily"), and files of
musical ensembles ("quartet.ensemble.instrument.ily")...
[With accompanying "LilyPond" (not scheme) syntax for overriding
the default settings or selecting variants (e.g. something like
"\bassoon \with { \clef tenor }".]
Regards,
Gilles
See NR 1.6.3 Writing parts > Instrument names
http://lilypond.org/doc/v2.18/Documentation/notation/writing-parts#instrument-names
Cheers,
Xavier
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
d approach made quite some impression particularly. As mentioned I have the impression that the overall issues of data integrity and the risks of relying on commercial software have become more present in publishers' minds by now. Imagine your suffering if the Sibelius case did not happen... :-) b) and c) are the problematic parts. And here I think the "risk" part is more of an issue thant the "investment". People can't really oversee how the new technology can fit into their existing infrastructure, particularly given the fact that they do and will always have contributions by numerous people from outside that have to be integrated. Add to this the question if we can reliably enough convince anybody that "we" will be around in a few years and that there is a sufficient user base to guarantee that they will always find someone to get "tech support" from. The problem is that they don't grasp what "free software" is. If they want to, "tech support" will be there, thanks to them. You cannot promise that it will be there, if they don't become involved in and concerned about the (evolving) "community". And as noted earlier, they have demonstrably wrong expectations that tech support for commercial will always be there! So finally I'm back at the beginning, namely my original post's question, preparing a convincing set of facts, arguments and "promises" that help to overcome the reservations with regard to b) and c) of the above list. I have the impression I'll be more or less alone with that, so I'll try to put my things together on my own. Having triggered quite a bunch of different (and hopefully fruitful) discussions is something too ... Back to thanking you for starting this discussion. And your involvement. And your work. And your projects. Maybe there will be a little slot for trying to take other paths into consideration for increasing LilyPond user base (or publish what you tried already and how/why it failed). Thanks, Gilles Best Urs Am 17.04.2015 um 15:03 schrieb Urs Liska: Just one more of the fundamental questions I took home from the Musikmesse ... The question can be asked somewhat less pretentious then in this message's subject line, but I think it actually boils down to no less than that. You know that I have again been at the Frankfurt Musikmesse this week, and again I had the opportunity to talk with various people from publishing houses (names only privately ...), and I was (unpleasantly) surprised that I didn't always have fully satisfactory answers ready. The questions came in various variants of "why should a publishing house use LilyPond?" And despite all the reasoning and writing I have produced over the last years I didn't always find "the" striking key features that were convincing in the concrete situation. I think I have always taken a perspective that was focused slightly beside the point, namely the perspective of an individual editor or the team of editors. This is perfectly transferable to a publishing house starting from scratch, but not to a big house with traditions, regulations and limitations. Compared to last year I have the impression that many people have become more aware of the basic questions about longevity of binary and textual data formats and data processing. The question has become much less "why should we consider dropping Finale and Sibelius, it's working, heh?" and more "OK, we see that we need an alternative approach, but how do you convince me that LilyPond has to be it?" We always say that text based tools are superior because they are much less prone to become unusable. This, and the potentials that come from version control, make quite some impression, but again this is only relevant to new material and doesn't take into account two important issues: 1) Publishers receive heterogenuous data material from various sources (editors, composers, engravers), and these are mostly done using Finale or Sibelius (and in some cases Score). It is completely out of question to requre all these people to switch to LilyPond. 2) One major question publishing houses consider today is how to carry their (digitally) existing material to the future. By now they have realized that simply using the latest version of the mainstream programs is calling for disaster, that's good for us. But again, the question is: Can we really offer "the" solution for this? The immediate idea would be to go some route via MusicXML and offer hassle-free workflows to convert existing editions or said received data material) to LilyPond. But firstly I don't think we can already guarantee this. And secondly, the question is natural to pop up: If one already uses MusicXML as the permanent and future-oriented storage format, whe
Re: Do we really offer the future?
On Fri, 24 Apr 2015 01:59:40 +0200, Urs Liska wrote: Am 24.04.2015 um 01:26 schrieb Kieren MacMillan: Hi Gilles, I have _not_ asked "the LilyPond team" to spend any resources for whatever. First of all, nobody wrote that you did. You wrote What's for the LilyPond team in spending resources trying to work around those self-inflicted limitations? That response fairly strongly implies that you think Urs has suggested or asked “the Lilypond team” to spend resources. I think so too. You got me there! Almost. :-) Actually what I meant is that *you* did not ask (in your post), but that (in my opinion) it logically follows that resources would be spent (to fix whatever needs fixing). And I included *you* in the "LilyPond team". Perhaps your initial post offered the possibility of misinterpretation. I seriously doubt that comment will help matters. Well, there *are* things that I didn't express in full length originally. So, while I still think I have the "right" to complain about some comments, there is some truth in this comment. Will you still complain, if I offer more compliments? :-) Rephrasing the idea: My opinion is that there is more to gain for us if you spent your resources without focusing too much on the "big publishers" potential user segment. I'd be more inclined if you set to educate "small publishers". Perhaps an easier target. But you, as the one doing the work, definitely get to decide in the end. And particularly as Gilles' post you are referencing here is overall very constructive I don't see much sense in playing "he started" or "I didn't say that but you did". I'll respond in more detail to that post as soon as I have the time. I'm particularly interested in constructive feedback on the alternative project which I mentioned. How to make a case for LilyPond? So that people will support the idea of creating free contents (primarily for use music schools) and will request that funds (which otherwise would go to "big publishers") be diverted towards that goal. Best, Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: mutopia's shortcomings
Hi. On Fri, 24 Apr 2015 12:43:59 +0200, Federico Bruni wrote: 2015-04-21 1:07 GMT+02:00 Kieren MacMillan : > Seems to me it has been quite successful in its goals of making sheet music easily available for free, all works in the public domain or under creative commons licenses, in (user-editable, user-improvable) LilyPond format, pdf, and midi — all with volunteer labor. Looks like the total is over 1900 works now. Other than the “user-editable, user-improvable” issue, all of those things are far better done by IMSLP. Put another way, looking at IMSLP (with 310,000 scores) and Mutopia (with 1,900), the shine quickly comes off Mutopia for anyone except the handful of hardcore DIY musicians who (e.g.,) want to take a violin piece from Mutopia and make a guitar arrangement. You forgot the quality of sheets: a (really) digital PDF will always look better than a scanned PDF. And if it's too old or don't like anything you can change it and get what you want. This is the value of Mutopia and the reason why I strongly disagree on the idea of merging it into IMSLP. In the past discussion on this topic there were a couple of ideas on better integration between the two projects. I think it would be far better — and probably result in better visibility/marketing for Lilypond — if Mutopia were merged into IMSLP. (There appears to have been a thought in this direction at some point, but not any more; cf. http://imslp.org/wiki/IMSLP:Community_Projects/Mutopia_score_archive). Then, for important works, there would be the Lilypond source, side-by-side with scans of existing editions. But it seems this was considered, and rejected for exactly the reasons that Mutopia now flounders (cf. http://imslp.org/wiki/IMSLP_talk:Community_Projects/Mutopia_score_archive ). Whether merge or not depends on the ultimate purpose of the project. IMSLP is mainly a repository of "printed" scores (final output) that happens to provide source code for some scores, while Mutopia is primarily a repository of musical "data" (LilyPond input data) that happens to provide the final output. I think that the original problem with Mutopia is that it did not position itself as a "contents" database but only as a score "repository". In the former case, one would have required that submitted contents follow rules well beyond just being a LilyPond-compilable source. If all works would follow the same standard layout, it would be much easier to maintain, upgrade (the layout) and adapt to different users taste wrt to the output (for example, changing the font should be doable with just rerunning LilyPond with an appropriate command-line switch). Even if not everyone will agree on "the" standard layout, I feel that it is extremely important to define one, with the maximum flexibility. The contents of all files that make up the complete layout does not have to be easily comprehensible by everyone; I think that the indispensable features are that * it should be manageable automatically (i.e. changing the standard should not require manual intervention) * the files requiring user input (i.e. music contents) should be completely separate from layout definitions Of course, the devil is in the details. And power users will complain in advance that they must tweak things (i.e. mix layout with contents) to get their required level of esthetics. Maybe that tweaked editions should not be in Mutopia's realm as a database[1] Maybe that such finely tuned editions could be managed with a source control system (keeping track of the differences with the "baseline contents"). Best regards, Gilles [1] Those editions could be available from there too, but would not be (so easily) upgradable. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: mutopia's shortcomings
On Fri, 24 Apr 2015 10:01:29 -0400, Kieren MacMillan wrote: Hi Simon, You forgot the quality of sheets: a (really) digital PDF will always look better than a scanned PDF. I think it depends: firstly, many IMSLP scores are on a level of typographical quality which – I’m sorry – Lilypond might never reach. +1000 Why do use LilyPond then? Or: Doesn't your appreciation need a more specific context? Like: LilyPond might never reach [that] level of typographical quality *without human tweaking*. Gilles [...] ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: mutopia's shortcomings
On Fri, 24 Apr 2015 10:48:02 -0400, Kieren MacMillan wrote: Hi Gilles, Why do you use LilyPond then? Here’s my answer: for compositions that have not yet been engraved — for example, every single one that will be written after today. But why _LilyPond_, if you agreed that quality will can (never!) match that produced with the tool that produced the scores available on IMSLP ? Why not that other tool? As a composer (and self-publisher), using Lilypond is a no-brainer for me. For engravers/publishers looking only to produce Yet Another Edition Of “That Old Chestnut”, I would imagine using Lilypond is far from a no-brainer — in fact, as we’ve seen, it’s a pretty tough sell, even for individual users. The question was not in reference to that subject. Rather it is about the "objective" quality of the result (independent of much work is required to get it). Best regards, Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: mutopia's shortcomings
On Fri, 24 Apr 2015 16:33:29 +0100, Anthonys Lists wrote: On 24/04/2015 12:42, Gilles wrote: Even if not everyone will agree on "the" standard layout, I feel that it is extremely important to define one, with the maximum flexibility. The problem arises, of course, when there are existing, conflicting, standards. There IS a standard out there, to which pretty much EVERY Brass Band march part I've seen adheres to (probably B&H house style, as they are the dominant publisher), that lilypond just does not produce by default. Yet talk to an orchestral musician and I guess many of them would say that the lilypond style feels "natural". If you impose a single style, you are pretty much guaranteeing that certain branches of music will stay away because the "house" style is just totally "wrong". At a minimum, you need different basic styles for different types of music. Of course, if style sheets become a lilypond reality, that will make life a lot better in that respect ... I was not at all suggesting a uniform layout of the "printed" output! On the contrary, I propose a standard way for managing an encoding project: list of files, names of those files, separation of concerns (contents vs graphical output), naming of variables, settings for different printed output (according to standard practice for the music style at hand), etc, etc. Best regards, Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: mutopia's shortcomings
On Fri, 24 Apr 2015 12:42:32 -0400, Kieren MacMillan wrote: Hi Gilles, But why _LilyPond_, if you agreed that quality will can (never!) match that produced with the tool that produced the scores available on IMSLP ? Why not that other tool? What "other tool"? Hand-engraving with metal punch ca. 1852-1952? Because that’s the standard we’re measuring against by comparing to IMSLP. I did not understand that. I thought that we were discussing computer generated output with (possibly heavy) human tweaking. New editions will (probably?) not use hand-engraving as you describe, so that's not part of the competition. No cross-platform computer application I know of — proprietary or open source — has better output than Lilypond. In fact, even with just a basic stylesheet applied to it, my musical theatre Piano/Conductor scores rival (and in most cases surpass) what the big publishing houses (e.g., Warner-Chappell) put out for sale. This is one of the reasons I laud Urs’s attempt to get some of those houses to use Lilypond: it would actually improve their current output! My point in the long thread is that they may indeed be satisfied with their current business model (which, for some, include ugly practice) and tools; hence, perhaps nothing can help. Regard, Gilles Cheers, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Limits of algorithmic typesetting (was: Re: mutopia's shortcomings)
On Fri, 24 Apr 2015 23:22:54 +0200, Eyolf Østrem wrote: On 24.04.2015 (14:12), tyronicus wrote: Simon Albrecht-2 wrote > I should’ve written “I believe that nothing as beautiful/good as this > will ever be engraved by a machine” then, since basically it is my > belief. Maybe I exaggerated a little :-) > And you may believe differently of course. My contrary belief: A machine will draw a circle better than a human 100% of the time. It's a matter of telling it how. A machine may draw a more geometrically perfect circle, but if I were to hang the drawing on my wall, I'd much rather have one made by Mirò than by a machine. Same with notation. Following this line of reasoning, you'll end up that it's better to have scores written by hand (as a really unique artisanal creation)... Also, a machine can be told to not draw a perfect circle, to fool you into thinking that was not drawn by machine. ;-) Regards, Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with "\relative"? (Was: Do we really offer the future?)
On Sun, 26 Apr 2015 09:58:33 +0200, Johan Vromans wrote:
On Sun, 26 Apr 2015 05:52:04 + (UTC)
Keith OHara wrote:
I wish the manual did not use the implicit \relative c'' {}
(sometimes \relative c' {} ) enclosing the examples. As soon as
the input gets complicated, \relative becomes difficult to figure
out.
I've always considered \relative as an operation that should be
applied as
close to the actual notes as possible. This gives the least suprises,
if
any.
\relative c'' {
\new PianoStaff <<
\new Staff { \time 2/4 c4 e | g g, | }
\new Staff { \clef "bass" c,,4 c' | e c | }
>>
}
This is, indeed, asking for problems...
I totally agree.
This kind of forgiveness from the LilyPond parser allows for
the ultimate bad practice of inextricably mixing typographical
information with musical information.
I fully understand and admit that the learning and notation
manual want to present self-contained examples (so that the
linked LilyPond code can readily compile), but I'm advocating
that readers should be made aware that it is only intended for
illustrating specific aspects of notation and that it should
not be done for any project for which maintainance is a concern.
[Some of the templates are complete counter-examples for this
aspect of best practices. The templates sections should probably
show an image of the intended output but link to "zip" file
containing the skeleton of a real project (possibly with a
"README" file).]
One should strive to separate editorial and musical information
to the utmost that LilyPond permits, not take advantage that
LilyPond allows for obfuscated code!
Best regards,
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: mutopia's shortcomings
On Mon, 27 Apr 2015 16:15:21 +0200, Noeck wrote:
Dear Kieren,
With the edition-engraver, there is (a) no need to mix layout with
contents
This seemed great; I looked for it in the documentation; and
did not find it...
I already wanted to submit a score to Mutopia using the edition
engraver. But I finally used ordinary tweaks because we were not sure
how future proof this is. This bings me to my questions:
1. How stable is the interface of the edition engraver?
Will the commands to use it change?
2. Will it always be in the current place of OpenLilyLib?
Now, I understand why. :-{
3. Might it get integrated into the core of LilyPond?
(Currently it is not guaranteed that OLL is available when Mutopia
scores are compiled, so its usage is complicated)
Because it does not make sense to improve the maintainability of a
large
set of scores by relying on a functionality that has to be adapted
manually in future and thus produces more manual interventions.
Indeed.
Best regards,
Gilles
To be clear, I like the edition engraver very much.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond teaching material
Hello. On Wed, 16 Sep 2015 11:49:04 +0200, BB wrote: I just read http://lilypond.org/doc/v2.18/Documentation/learning/entering-input.html (again). I find that is a good basis for such an introduction, IIRC, someone (among the most prominent current or past developers) once stated that this first example being compilable by lilypond had been a big mistake. Perhaps it was meant to show people that text input is not scary. But its simplicity is deceitful: no actual score is that simple; even a monophonic instrument part should not be encoded that way. but I think it needs some beef up to become more entertaining than lecturing. But I actually do not have an idea how to manage that? In my opinion there are much more instructive examples and exercises for reinforcement learning needed. The strategy will probably depend on the target audience and purpose. IMHO, the starting point should be a real score whose input contains all the bits that most people would use in the majority of their projects: score (and MIDI) blocks, header, systems, full score and instrument parts. A composer/publisher will not be scared that a work needs to have some kind of organization/layout. Some people will be afraid (i.e. won't be interested) by text input whatever advantage list you will throw at them. Those should be taught how to use a [FLOSS GUI] that depends on LilyPond for its rendering. Best regards, Gilles On 16.09.2015 11:24, Urs Liska wrote: Am 16.09.2015 um 11:14 schrieb BB: Obviously the Lilypond users are overaged? I very much hope that our recent "inofficial survey" is biased for whatever reasons. But I admit this impression is very strong. Is there a kind of "curriculum", eventually with Open Office overhead slides ready to use for an introductory training on an adult education center (in Germany Volkshochschule (VHS)) available. Not that I know of, but it's a good idea, and I've had the wish to start compiling such material for quite a long time. Unfortunately that probably won't happen without a concrete opportunity. May be some skilled users ma offer such an itroduction to raise lilyponds popularity? Usually there are offered weekend workshops or courses regular an evening per week for people in work. Eventually it might be used in music education on schools? Good idea. I know that in some universities there are people offering LilyPond courses, with mixed result/acceptance. But it definitely should be much more, and I think people should get hooked to text based tools as early as possible, before they are too much tied to their shiny clickediclick tools. Urs Regards ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond teaching material
On Wed, 16 Sep 2015 13:04:24 +0200, David Kastrup wrote: Gilles writes: Hello. On Wed, 16 Sep 2015 11:49:04 +0200, BB wrote: I just read http://lilypond.org/doc/v2.18/Documentation/learning/entering-input.html (again). I find that is a good basis for such an introduction, IIRC, someone (among the most prominent current or past developers) once stated that this first example being compilable by lilypond had been a big mistake. Well, I think it should specify a note duration for the first note. Other than that, I find nothing wrong with it. Perhaps it was meant to show people that text input is not scary. But its simplicity is deceitful: no actual score is that simple; even a monophonic instrument part should not be encoded that way. Hacking down some melody tends to be rather similar to that. Many tunes in abc format look pretty much like that and transfer reasonably well to LilyPond input of that complexity. Would someone switch to lilypond just for this kind of work? I did not to argue in that direction (lesser complex scores), but even so: where is the title of the tune? ;-) Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Prall and trill in "articulate" script
Hello. It's the first time I use the "\articulate" command. Very nice improvement on the plain MIDI rendering! Two remarks: 1. "prall" is interpreted in a way that (IMO) better corresponds to "prallprall" (which itself is not implemented). [A comment in the code indicates that the "inverted mordent" option was not retained.] 2. A "trill" on a tied note only lasts as long as the first written note. The problem is alleviated by using a trill span, but then the trill is stopped at the start of the last written note's duration. Thanks, Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Delayed posts
On Mon, 16 Nov 2015 23:32:37 +0100, Simon Albrecht wrote: On 15.11.2015 20:44, Simon Albrecht wrote: Hello everybody, The notorious delay with which many posts arrive on this list gets annoying… At times there is no problem, but these days it’s really bad. Is there anything we could do? Or, _I_ could do, if it were a problem on my side? Same problem here... Best, Gilles ~ Simon ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problem with the script extract music
> I have a problem with the script extraxtMusic, which I have downloaded at
http://gillesth.free.fr/Lilypond/extractMusic/extractMusic.ly
> I get the error message
> mmR = {
> R1*100 \tag #'mmWarning R1 }
> And a message, that a barcheck has failed.
> Has someone an idea how to make it work?
Sorry to answer so late.
This message occurs when you try to cut a multimeasureRest using
\extractMusic, in the middle of the measure.
For example
music = R1*5
\extractMusic \music s1 s4
will produce an error because the result is R4, and R4 doesn't fill a whole
measure (in 4/4) . It is not a limitation or a bug of \extractMusic but the
behaviour of Lilypond with multimeasureRests
So you have to cut them always at a beginning of a measure then add rests
manually.
> global = {
> \globalA
> \globalB
> }
> HornB = \relative {
> \extractMusic \mmR \upToMeasure #12 { \upToMeasure #15 s8*5 }
> d4. e4
> R8*5
> }
The error is probably here, but you don't give us the \global definition, and
as \upToMeasure uses \global in his implementation, i cannot help you further.
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ties over several notes
Le vendredi 15 février 2013 11:38:08 Kieren MacMillan a écrit :
> Hi Stefan,
>
> > is there a way to connect several notes with ties with just one command?
>
> I think the Completion_heads_engraver does this for you.
> http://lilypond.org/doc/v2.17/Documentation/internals/completion_005fheads_0
1-
If you have several times the same rhythms and ties, you can perhaps use the
function \changePitch described here :
http://lsr.dsi.unimi.it/LSR/Item?id=654
[ There is a doc here :
http://gillesth.free.fr/Lilypond/changePitch/ ]
%
patI = \samePitch { c8~ c4. ~ c2~ c8 }
\relative {
c4.
\cPI d
e
}
2-
If you have several times the same number of ties but with different rhythms,
you can use rather \copyArticulations
snippet : http://lsr.dsi.unimi.it/LSR/Item?id=769
download link : http://gillesth.free.fr/Lilypond/copyArticulations/
%%
artiI = { c~ c~ c~ c}
\relative {
c4. \cAI { d8 d4. |
d2 d8 } e4.
}
But perhaps this one is not very quicker, here.
--
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Removing the start or the end of some music
If no one objects, your functions are sufficiently concise that I would suggest folding them directly into the extractMusic.ly file which is linked from the snippet URL, if the original author agrees. No problesm for me to add that, but you can notice that in the snippet ( http://lsr.dsi.unimi.it/LSR/Item?id=542 ), there is a link, pointed to the last version of "extractMusic.ly", and there is already some functions which already do the same things ( well there are called \extractBegin and \extractEnd). There is even a small doc for these functions (and also for others). Here is this link : http://gillesth.free.fr/Lilypond/extractMusic/ -- Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Is it possible to adapt Numbers as easy note heads [0.07143] to solfege ( d r m f s l t)?
I like to print solfege ( d r m f s l t) on to the note-head. The
following snippet print numbers onto the note-head. Is it possible to
adapt the following snippet to print solfege onto the note-head?
I don't know if it is want you want :
(and thanks to Frescobaldi to the automatic indentation ...)
%
#(define EzSolfegeEngraver#(define EzSolfegeEngraver
(list
(cons 'acknowledgers
(list
(cons 'note-head-interface
(lambda (engraver grob source-engraver)
(let* ((context (ly:translator-context engraver))
(tonic-pitch (ly:context-property context 'tonic))
(tonic-name (ly:pitch-notename tonic-pitch))
(delta (- 7 tonic-name))
(solfege-base (circular-list "S" "O" "L" "F" "E" "G"
"E"))
(solfege (take (drop solfege-base delta) 7))
(note-names (apply vector solfege)))
; (display solfege)(newline)
(ly:grob-set-property! grob 'note-names
note-names
EzNum = {
\easyHeadsOn
\override Staff.StaffSymbol #'staff-space = #1.5 %1.4
\override Staff.StaffSymbol #'line-thickness = #1.5 %1.4
\override Staff.NoteHead #'font-size = #+3.2 %=3.0
\override Staff.Clef #'font-size = #+1.35 %1.25
\override Staff.TimeSignature #'font-size = #+1.35 %1.25
\override Staff.Accidental #'font-size = #+1.35 %1.25
\override Voice.NoteHead #'font-size = #-5.25 %-5.0
}
global = { \key c\major \time 4/4 }
mux = \relative c' { \global \EzNum
c4 d e f g a b4 r
\key f\major
f g a bes c d e r
\key g\major
g, a b c d e fis r
}
\score {
\new Staff { \mux}
\layout {
\context {
\Voice
\consists \EzSolfegeEngraver
}
}
}
%%
--
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Is it possible to adapt Numbers as easy note heads [0.07143] to solfege ( d r m f s l t)?
#(define EzSolfegeEngraver#(define EzSolfegeEngraver
Oh sorry a copy-paste error.
%
#(define EzSolfegeEngraver
(list
(cons 'acknowledgers
(list
(cons 'note-head-interface
(lambda (engraver grob source-engraver)
(let* ((context (ly:translator-context engraver))
(tonic-pitch (ly:context-property context 'tonic))
(tonic-name (ly:pitch-notename tonic-pitch))
(delta (- 7 tonic-name))
(solfege-base (circular-list "S" "O" "L" "F" "E" "G"
"E"))
(solfege (take (drop solfege-base delta) 7))
(note-names (apply vector solfege)))
; (display solfege)(newline)
(ly:grob-set-property! grob 'note-names
note-names
EzNum = {
\easyHeadsOn
\override Staff.StaffSymbol #'staff-space = #1.5 %1.4
\override Staff.StaffSymbol #'line-thickness = #1.5 %1.4
\override Staff.NoteHead #'font-size = #+3.2 %=3.0
\override Staff.Clef #'font-size = #+1.35 %1.25
\override Staff.TimeSignature #'font-size = #+1.35 %1.25
\override Staff.Accidental #'font-size = #+1.35 %1.25
\override Voice.NoteHead #'font-size = #-5.25 %-5.0
}
global = { \key c\major \time 4/4 }
mux = \relative c' { \global \EzNum
c4 d e f g a b4 r
\key f\major
f g a bes c d e r
\key g\major
g, a b c d e fis r
}
\score {
\new Staff { \mux}
\layout {
\context {
\Voice
\consists \EzSolfegeEngraver
}
}
}
%%
--
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sub-music
http://lsr.dsi.unimi.it/LSR/Search?q=extract To get the last version and get documentations about the function extractMusic, please follow this link : http://lsr.dsi.unimi.it/LSR/Item?u=1&id=764 [This snippet is still not approved] Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sub-music
To get the last version and get documentations about the function extractMusic, please follow this link : http://lsr.dsi.unimi.it/LSR/Item?u=1&id=764 [This snippet is still not approved] Gilles Could you summarise the difference from the previous version for me, please? If you just click on the image of the old and new snippet, you'll see the same code, but in the LSR 764, there is a link to a directory where you can download the last version. ( http://gillesth.free.fr/Lilypond/extractMusic/ ) A lot of features have been added, and they are all shortly explained in a doc. ( http://gillesth.free.fr/Lilypond/extractMusic/extractMusic-doc.pdf ). Gilles NB Well, let me know is something is not clear in the doc, or if some sentences are not correct (my english is not as good i would wish). ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sub-music
I've put those updates into the old snippet (http://lsr.dsi.unimi.it/LSR/Item?id=542). If you're happy with that, the new one can be deleted, I think. That's perfect, thank you. New snippet (764) deleted. Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Function to limit range down?
I am transposing some arpeggio exercises and need to make sure notes do not go below e, on the bass clef. Here (see joined file) is a set of 3 functions which can be useful for that purpose. \correctOctave \correctOctaveRange \colorizeOutOfRange See comments in code source for an explanation of each of them. Gilles check-pitch.ly Description: Binary data ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Function to limit range down?
Maybe you already planned to, but please add such functions to the LSR. They will be for sure useful to other people! http://lsr.dsi.unimi.it/LSR/Item?u=1&id=773 Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Arpeggios from chordmode?
Is there as simple way to get chord mode to return:
c4 e g
instead of
4
Is something like that what you wanted ?
#(use-modules (ice-9 receive))
%% see http://www.gnu.org/software/guile/manual/guile.html#Multiple-Values
#(define (chords-list->seq-list lst)
(receive (notes others)
(partition (lambda(x) (ly:duration? (ly:music-property x
'duration)))
lst)
(map (lambda(x)
(let ((elts (list x)))
(if (pair? others)(begin
(set! elts (append elts others))
(set! others '(
(make-music 'EventChord 'elements elts)))
notes)))
chordsToSeq = #(define-music-function (parser location music)(ly:music?)
(music-map
(lambda (x)
(if (eq? 'EventChord (ly:music-property x 'name))
(make-music 'SequentialMusic 'elements
(chords-list->seq-list (ly:music-property x 'elements)))
x))
music))
music = \chordmode {d4:min7\f g:7 c:maj7}
\new Voice \chordsToSeq \music
%%
Gilles<>___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond with the Command Line
Le Mon, 01 Aug 2011 21:39:16 +0200, Graham Percival
a écrit:
Could you pass a
command on the command line and tell Lilypond to process the source file
and change it to a bass clef instead? without changing the source file
permanently? Could this be done using the Scheme evaluate function?
Yes. Use \tag, and look on LSR for more information. There's 1
or 2 examples of this there.
I have tested nevertheless this file on the command line (according to the
doc):
*
the file "test1" :
#(use-modules (guile-user)) %% make a warning !!! bug ?
clefSol = \clef treble
clefBass = \clef bass
%% #(define original-clef? #t)
#(define myclef (if (and (defined? 'original-clef?) original-clef?)
clefBass
clefSol))
music = { \myclef c'1 }
{ \music }
%%%
The command line that works in Windows is this :
lilypond -e "(define-public original-clef? #t)" test1.ly
*
Some comments :
1-In the doc, they say to put the scheme expression inside apostrophe
lilypond -e '(define-public original-clef? #t)' test1.ly
but this fails. (The apostrophes have perhaps other meanings in Windows).
2- The line #(use-modules (guile-user)) makes the warning :
WARNING: #f: imported module (guile-user) overrides core binding
`%module-public-interface'
3- "define" instead of "define-public" seems to work too :
lilypond -e "(define original-clef? #t)" test1.ly
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Arpeggios from chordmode?
Le Wed, 03 Aug 2011 05:10:11 +0200, Basso Ridiculoso
a écrit:
See enclosed file for example (requires Giles code below as an \include)
Just 2 comments.
1-You can use in your example \shiftDurations (well not a lot documented).
It will divise all whole notes by 4
Your code becomes :
%%
JazzBluesChords = {
\chordmode {
c1:7 | %1
f1:7 | %2
c1:7 | %3
g2:min7 c2:7 | %4
f1:7 | %5
f1:min7 | %6
e1:min7 | %7
a1:7 | %8
d1:min7 | %9
g1:7 | %10
c1:7 | %11
d2:min7 g2:7 | %12
\bar ":|"
}
}
JazzBluesProgression = \shiftDurations #2 #0 \JazzBluesChords
2- It still remains problems if a chord has 3 or 5 notes !
Well if you think it can be useful for people, i can try later to find a
way to fix that.
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: substitution for numerator
music = \relative c' {
\times 2/3 {c8 d e } \times 4/5 {c16 a g f e }
}
slurs = {
\tripletquintupletslur #2 #5 % the slur lasts 2 triplet and 5
quintuplet notes
}
\new Staff { \context Voice << { \music} {\slurs }>>}
%%
You can attach slur to invisible rests and "melt" them together later:
You can also try this snippet
http://lsr.dsi.unimi.it/LSR/Item?id=769
%%
\include "copyArticulations.ly"
music = \relative c' {
\times 2/3 {c8 d e } \times 4/5 {c16 a g f e } g2
}
pattern = { c c( c c c c c) c }
\copyArticulations \pattern \music
%%
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: no braces or brackets (quitar paréntesis)
I get { { f' f' f' f' } { bflat' bflat' bflat' bflat' } { f' f' f' f'
} }
and I would like to get { f' f' f' f' bflat' bflat' bflat'
bflat' f'
f' f' f' }
1-
You can try the following function :
#(define (clean-music mus)
"Try to reduce the number of sequential musics"
(let ((name (ly:music-property mus 'name)))
(cond
((eq? name 'SequentialMusic)
(ly:music-set-property! mus 'elements (fold-right
(lambda (evt prev-list)
(if (eq? (ly:music-property evt 'name) 'SequentialMusic)
(append (ly:music-property (clean-music evt) 'elements)
prev-list)
(cons (clean-music evt) prev-list)))
'()
(ly:music-property mus 'elements
((eq? name 'SimultaneousMusic)
(ly:music-set-property! mus 'elements
(map clean-music (ly:music-property mus 'elements
((memq name (list 'RelativeOctaveMusic 'UnrelativableMusic))
(ly:music-set-property! mus 'element (clean-music
(ly:music-property mus 'element)
mus))
you just have to modify your \chuchu function like that :
chuchu = #(define-music-function (parser location music)(ly:music?)
(clean-music
(music-map
(lambda (x)
(if (eq? 'EventChord (ly:music-property x 'name))
(toma x)
x))
music)))
2-
However, i don't know exactly what your are trying to achieve, but perhaps
you will be interested by this thread :
http://lists.gnu.org/archive/html/lilypond-user/2011-08/msg2.html
I have joined the latest version of chordsToSeq.ly
Gilles
chordsToSeq.ly
Description: Binary data
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Improving snippet 326
As i found the snippet :
http://lsr.dsi.unimi.it/LSR/Item?id=326
beautiful and useful, i have a little proposition to improve it.
With the current snippet, you have to do 2 versions: a layout version and
a midi version (using \tag).
By using this little function below (inspired from :
http://lsr.dsi.unimi.it/LSR/Item?id=694 ), only one version would be
necessary.
%%%
\version "2.14.2"
changeNotesPos =
#(define-music-function (parser location amount music) (integer? ly:music?)
"Change the display of notes by adding `amount in their staff line
position."
#{
\set staffLineLayoutFunction =
#(lambda (x) (+ (ly:pitch-steps x) $amount))
$music
\unset staffLineLayoutFunction
#})
%% test
music = \relative { c d ees f}
\new Staff \music
\new Staff \changeNotesPos #2 \music
I have joined a version of all the original snippet, just using the above
function instead.
I have no ways to know who wrote this useful snippet, but perhaps that the
author will think as me, that it would be an improvement for the users.
Gilles
snippet326.ly
Description: Binary data
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: articulation over several notes
Le Sun, 01 Jan 2012 05:53:45 +0100, me a écrit:C
Is there a way to specify articulation over several notes. Eg., relative c' {
c d e f | g a b c }. I would like to make the first four notes staccato and
the second 4 marcato. Just, clarifying, I understand that I can do c\staccato d\staccato etc. Can I do something like (c d e f)\staccato ?http://lsr.dsi.unimi.it/LSR/Item?id=769\copyArticulations c-> \relative c' { c d e f | g a b c } Gilles___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Suppressing left-hand piano dynamics
However, I have been unable to suppress dynamics from the left hand in
the piano accompaniment.
Well, i can not exactly explain why, but apparently the good manner to do
is
%% good
\partcombine
\new Voice \with { \remove "New_dynamic_engraver" }
{ \bassOne \bar "|."}
\new Voice \with { \remove "New_dynamic_engraver" }
{ \bassTwo \bar "|." }
and not
bad
\new Voice \with { \remove "New_dynamic_engraver" }
\partcombine { \bassOne \bar "|."} { \bassTwo \bar "|." }
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: synchronizing other parts w/cadenza
But I was annoyed by having two functions with very similiar code.
It is possible with ly:music-compress , to make a function that fit all
kind of music
NB
I have tested this snippet only with 2.14 but it should work with 2.15
%
\layout {
\context {
\Staff
\remove "Time_signature_engraver"
}
}
cadenzaToMusic =
#(define-music-function (parser location cadenzaMusic music)
(ly:music? ly:music?)
"Adjust the length of `music and the measureLength, to fit the length of
`cadenzaMusic"
(let* ((clen (ly:music-length cadenzaMusic))
(mlen (ly:music-length music))
(factor (ly:moment-div clen mlen))
(compressed (ly:music-compress music factor)))
;; (format #t "factor : ~a\n" factor)
#{
\set Timing.measureLength = $clen
$compressed
\unset Timing.measureLength
#}))
cadenzaText = \markup \box "cadenza!"
cnotes = \relative c'' { c8[ d e f g] }
snotes = \cadenzaToMusic \cnotes s1_\cadenzaText
mnotes = \cadenzaToMusic \cnotes R1^\fermataMarkup_\cadenzaText
nnotes = \cadenzaToMusic \cnotes \relative c''
{ c2^\fermata _\cadenzaText d^\fermata }
\score {
<<
\new Staff \cnotes
\new Staff \mnotes
\new Staff \snotes
\new Staff \nnotes
>>
}
%%<>___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \makeOctaves broken?
David Kastrup did a quick fix a few months
back:http://lists.gnu.org/archive/html/lilypond-user/2012-03/msg00114.html
I just tried it and it had a few problems:
- it didn't work within a relative section. It only worked within
relative sections before.
- Slurs and dynamics attached to single notes are lost during the
conversion to chords.
Below fixes the relative problem, but I haven't spent enough time on
it to figure out the second problem.
Slurs and dynamics for single note are now wrapped in the 'articulations
property.
So we have to extract those events to copy them to the 'elements property
of the event-chord.
I think that the receive scheme function is the simpler way to do that.
( http://www.gnu.org/software/guile/manual/guile.html#Multiple-Values )
%%%
\version "2.15.35"
#(use-modules (ice-9 receive)) %% for the use of receive
#(define (with-octave-up m octave)
(let* ((old-pitch (ly:music-property m 'pitch))
(new-note (ly:music-deep-copy m))
(new-pitch (ly:make-pitch
(- octave 1)
(ly:pitch-notename old-pitch)
(ly:pitch-alteration old-pitch
(set! (ly:music-property new-note 'pitch) new-pitch)
(list m new-note)))
#(define (octavize music t)
(map-some-music
(lambda (m)
(cond ((music-is-of-type? m 'event-chord)
(set!
(ly:music-property m 'elements)
(append-map!
(lambda (n)
(if (music-is-of-type? n 'note-event)
(with-octave-up n t)
(list n)))
(ly:music-property m 'elements)))
m)
((music-is-of-type? m 'note-event)
(receive (note-arti chord-arti)
(partition
; separates arti for NoteEvent from arti for EventChord
(lambda (evt)(memq (ly:music-property evt 'name)
(list 'StringNumberEvent 'StrokeFingerEvent
'FingeringEvent)))
(ly:music-property m 'articulations))
(ly:music-set-property! m 'articulations note-arti)
(make-event-chord (append
(with-octave-up m t) chord-arti
(else #f)))
music))
makeOctaves = #(define-music-function (parser location arg mus)
(integer? ly:music?)
(octavize mus arg))
\relative c'
{
\time 3/8
\key gis \minor
\makeOctaves #1 { dis8(\f e dis')~ dis8.( cis16 b8 }
\makeOctaves #-1 { ais' gis dis) cis( dis )\p }
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: controlling footnote separator line
Unfortunately I didn't find the property that controls the line
separating the footnote. from the score.
Is this possible?
is it documented (and I am blind)?
or is this impossible?
Well not easy to find.
In paper-defaults-init.ly, you have some variable controlling Footnotes.
By default, the settings are
\paper {
footnote-separator-markup = \markup \fill-line { \override
#'(span-factor . 1/2) \draw-hline }
footnote-padding = 0.5\mm
footnote-footer-padding = 0.5\mm
footnote-number-raise = 0.5\mm
footnote-numbering-function = #numbered-footnotes
reset-footnotes-on-new-page = ##t
}
If you set :
footnote-separator-markup = \markup \null
it will do the trick.
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: multiple tags
Is is possible to have simultaneous multiple tags?
What makes you think that?
As i had difficulties managing multiple tags, i have made for me some
little functions to simplify it.
With the joined file, your code would become, with the \keepWithTags :
%%
\include "tagUtil.ly"
control = {
s1*2
\tag #'threes { \time 3/4 s2. }
\tag #'twos { \time 2/4 s2 } }
tset = \relative c' {
c4 d e f
\tag #'up {g4 a b c }
\tag #'down { g4 f e d }
\tag #'threes { g4 f e }
\tag #'twos { g2 } }
\score {
\new Staff <<
\keepWithTag #'threes \control
\keepWithTags #'(up threes) \tset
>> }
\score {
\new Staff <<
\keepWithTag #'twos \control
\keepWithTags #'(down twos) \tset
>> }
You can see some examples in the file.
Gilles
tagUtil.ly
Description: Binary data
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond-user Digest, Vol 113, Issue 99
Can I just print the multiple of fifth's (or 10's) only - the in between
nar number should be blank?
%%
\version "2.15.37"
%%% solution 1
\relative c'' {
\override Score.BarNumber #'break-visibility = #'#(#f #t #t)
\override Score.BarNumber #'stencil =
#(lambda (grob)
(let* ((stil (ly:text-interface::print grob))
(text (ly:grob-property grob 'text))
(nmbr (string->number (markup->string text
(if (= (remainder nmbr 5) 0)
(ly:grob-set-property! grob 'color red)
(ly:grob-suicide! grob))
stil))
\repeat unfold 41 { c1 }
}
%%% solution 2 % easier
\relative c'' {
\override Score.BarNumber #'break-visibility = #'#(#f #t #t)
\set Score.barNumberVisibility = #(every-nth-bar-number-visible 5)
\override Score.BarNumber #'color = #red
\repeat unfold 41 { c1 }
}
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR snippet "Controlling of the pitch range in a score" broken at 2.15.40
The LSR snippet "Controlling of the pitch range in a score" contains the code for a function, colorizeOutOfRange. This function works at 2.14.2, but doesn't at 2.15.40. Well, i waited for the release of Lilypond 2.16, to annonce some snippets updates, but it seems that it's time to do that a few days before. So here are links, to have the snippets below, worked with Lilypond 2.15.41 (and higher i hope): ** http://lsr.dsi.unimi.it/LSR/Item?id=773 : "Controlling of the pitch range in a score" => http://gillesth.free.fr/Lilypond/check-pitch/ http://lsr.dsi.unimi.it/LSR/Item?id=654 : "A function to repeatedly print a given pattern with different notes" => http://gillesth.free.fr/Lilypond/changePitch/ (small doc included) http://lsr.dsi.unimi.it/LSR/Item?u=1&id=761 : "Adding notes to the notes of a melody" http://lsr.dsi.unimi.it/LSR/Item?u=1&id=545 : "Extracting notes inside chords into separate staves" => http://gillesth.free.fr/Lilypond/chord/ http://lsr.dsi.unimi.it/LSR/Item?u=1&id=769 : "Adding articulations from a template" => http://gillesth.free.fr/Lilypond/copyArticulations/ http://lsr.dsi.unimi.it/LSR/Item?id=542 : "Extracting unmodified fragments of a music expression" => http://gillesth.free.fr/Lilypond/extractMusic/ (small doc included) This one is not a snippet but a temporary solution for : http://code.google.com/p/lilypond/issues/detail?id=824 => http://gillesth.free.fr/Lilypond/addAt/ * Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Brazen feature request
The request is for six commands (NOT markups, but actual music commands
that affect the MIDI output and so on):
\segno
\fine
\tocoda
\coda
\dacapo
\dalsegno
Using the functions described here :
http://lsr.dsi.unimi.it/LSR/Item?id=542
i think you will be able quickly to achieve your goal without all this
commands.
%%
\include "extractMusic.ly"
global = {
s1*2
\bar "||"
\mark \markup { \musicglyph #"scripts.segno" }
s1*2
\mark \markup { \musicglyph #"scripts.coda" }
s1*2
\bar "||"
\once \override Score.RehearsalMark #'break-visibility = #'#(#t #t #f)
\mark \markup { \musicglyph #"scripts.segno" }
\break
s1*2^\markup{ \general-align #Y #CENTER {
\musicglyph #"scripts.coda" "CODA"}}
\bar "|."
}
segnoToMidi = #(define-music-function (parser location music) (ly:music?)
#{
\extractBegin $music \upToMeasure #3
\extractMusic $music \upToMeasure #3 \upToMeasure #7
\extractMusic $music \upToMeasure #3 \upToMeasure #5
\extractEnd $music \upToMeasure #7
#})
music = \relative {
c1 c
c2 d e e
f4 e f fis g1
d c
}
%%
\markup "Score output"
\score {
\new Staff << \global \music >>
\layout { }
}
\markup "Midi output"
\score {
\new Staff \segnoToMidi \music
\layout { } % to comment, to have only midi
\midi { }
}
%%
The can download extractMusic.ly for lilypond 2.15 here :
http://gillesth.free.fr/Lilypond/extractMusic/
For lilypond 2.14, choose in this directory :
extractMusic2.14.ly
You will also find in it, a small doc :
extractMusic-doc.pdf (well probably in bad english, sorry).
Gilles<>___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: smart rhythmic notation, can it be done?
is it possible to get an automatism for smart rhythmic notation.
You can use patterns
http://lsr.dsi.unimi.it/LSR/Item?id=654
but perhaps it is not what you wished
\include "extractMusic.ly"
% the following would be fastly written, bad looks bad:
Music= \relative c'' { c16 b8 a g f e d16\bar"||" }
% the following looks good, but would be more work to do
smartlynotatedMusic = \relative c'' { c16 b8 a16 ~ a g8 f16 ~ f e8 d16
\bar"||" }
% the following needs to prepare a pattern only once.
patI = { c8 \samePitch { c16 ~ c}}
patMusic = \relative c''{ c16 \cPI { b a g f e } d16 }
\score {
\new Staff {
\time 3/4
\Music
\break
\smartlynotatedMusic
\break
\patMusic
} }
Gilles
NB
For version 2.14 :
http://gillesth.free.fr/Lilypond/extractMusic/extractMusic2.14.ly
For 2.15 :
http://gillesth.free.fr/Lilypond/extractMusic/extractMusic.ly
Doc :
http://gillesth.free.fr/Lilypond/extractMusic/extractMusic-doc.pdf
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: smart rhythmic notation, can it be done?
is it possible to get an automatism for smart rhythmic notation.
You can use patterns
http://lsr.dsi.unimi.it/LSR/Item?id=654
but perhaps it is not what you wished
Oups ! I should forbid me to answer a question after midnight ...
Here is the good snippet ...
\include "changePitch.ly"
\version "2.14.1"
% the following would be fastly written, bad looks bad:
Music= \relative c'' { c16 b8 a g f e d16\bar"||" }
% the following looks good, but would be more work to do
smartlynotatedMusic = \relative c'' { c16 b8 a16 ~ a g8 f16 ~ f e8 d16
\bar"||" }
% the following needs to prepare a pattern
patI = { c8 \samePitch { c16 ~ c}}
patMusic = \relative c''{ c16 \cPI { b a g f e } d16 \bar"||" }
\score {
\new Staff {
\time 3/4
\Music
\break
\smartlynotatedMusic
\break
\patMusic
} }
and the good links
For version 2.14 :
http://gillesth.free.fr/Lilypond/changePitch/changePitch2.14.ly
For 2.15 :
http://gillesth.free.fr/Lilypond/changePitch/changePitch.ly
Doc :
http://gillesth.free.fr/Lilypond/changePitch/changePitch-doc.pdf
Sorry..
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: how to update this snippet to 2.16.
Le Sat, 25 Aug 2012 14:50:01 +0200, Stefan Thomas a écrit: Dear community, it seems, that the following snippet does not work anymore in 2.16. http://lsr.dsi.unimi.it/LSR/Snippet?id=346 I use it quite frequently. How can I update it? You can for example in line 61 : ((,trans-rec pitches) (ly:music-deep-copy ,pattern))) just change the word pitches, by (map event-chord-wrap! pitches) ((,trans-rec (map event-chord-wrap! pitches)) (ly:music-deep-copy ,pattern))) It works for me. However i don't pretend i understand all the snippet. Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: how to update the makerhythm-snippet
Dear community, I wanted to update this snippet: http://lsr.dsi.unimi.it/LSR/Snippet?id=390 But without sucess. Any ideas how this can be done? The snipped 390 has to be considered as deprecated because the snippet http://lsr.dsi.unimi.it/LSR/Item?id=654 does the same thing but is more powerful (it accepts for example articulations). So I would not mind to delete it, but if people do want to use it, we can, as usual now, use the Scheme function event-chord-wrap! (see http://lilypond.org/doc/v2.16/Documentation/changes/index.html ). So the line 76 (in the end of the makeRhythm function) : m))) would become : (event-chord-wrap! m Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: how to update the makerhythm-snippet
it really serves no purpose to use it [event-chord-wrap!] in snippets So i propose to delete this snippet 390 because it is no more useful. Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: how to update the makerhythm-snippet
I think only an LSR editor (like me) can do this. You want me to go ahead and delete it? Yes, please. Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: how to update the makerhythm-snippet
I think only an LSR editor (like me) can do this. You want me to go ahead and delete it [snippet 390]? Yes, please. Done. Thanks Phil. Just a last thing that i cannot do myself :-( As the snippet 654 refers to snippet 390, is it possible to replace, in 654, the sentence : "This snippet describes a function \changePitch which is an extension of snippet 390 ..." by something like that (feel free to reword) : "This snippet describes a function \changePitch, to repeatedly print a given rhythm with different notes. Its syntax is ..." ? -- Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problem with addTenuto
addTenuto = #(define-music-function (parser location x) (ly:music?)
#{
\copyArticulations {c--} $x
#})
The below quoted snippet shows that it works fine, every note gets it's
tenuto sign, rests are left without, but: I still searching for a
possiblity to let the second of two tied-notes without a tenuto. Has
anyone
I have added a function \skipTiedNotes as a separate one, because i am not
absolutely sure that it must be the default behavior.
So your function becomes :
%
addTenuto = #(define-music-function (parser location x) (ly:music?)
#{
\copyArticulations {c--} \skipTiedNotes $x
#})
\addTenuto \relative { c4 d e f g1 ~ g4 f e d r4 c d 2 }
%
As i am a good guy, i also change the line :
skipArti = \tag #skipCurrentArticulation s1*0
by
skipArti = \tag #skipCurrentArticulation <>
I have uploaded the new file here :
http://gillesth.free.fr/Lilypond/copyArticulations/copyArticulations.ly
--
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problem with addTenuto
Le Sun, 02 Sep 2012 14:25:07 +0200, Stefan Thomas a écrit: Dear community, for those who are interested: I've found a solution for my problem. I've found it in the older version of copyarticulations.ly It is not the older one. It is the newest. :-) I think you missed my message. http://lists.gnu.org/archive/html/lilypond-user/2012-08/msg00789.html It has been made Sat, 01 Sep 2012 02:26. In the first line of copyArticulations.ly, you can read : %% version 01/09/2012 11:07 : lilypond 2.16 or higher %% LSR = http://lsr.dsi.unimi.it/LSR/Item?u=1&id=769 Of course, the date format used here is : day/month/year. (I really don't like the format : month/day/year). Perhaps i should use the format : year/month/day, because the format : year/day/month doesn't exist (well i think). -- Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Possible feature request for 'q' shorthand or tie syntax
Le Thu, 20 Sep 2012 12:46:14 +0200, Stefan Thomas
a écrit:
\include "changepitch.ly"
AV = { c8 c4 }
av = #(define-music-function (parser location x) (ly:music?)
#{
\context Voice << { \changePitch \AV { $x $x } } { s8 ~ s8 } >>
#})
\new Staff \relative c' {
c4. \av es f4 fis4 \av fis g4
}
In changePitch.ly, there is a special function called \samePitch which can
be used for ties
[ It is shortly described in chapter 6 and 7 of changePitch-doc.pdf at
http://gillesth.free.fr/Lilypond/changePitch/ ]
%
\include "changePitch.ly"
av = #(define-music-function (parser location x) (ly:music?)
#{
\changePitch \samePitch { c8 ~ c4 } $x
#})
\new Staff \relative c' {
c4. \av es f4
fis4. \av fis g4
}
%
This example should work with any number of ties, but of course, will
produce music with the rhythm you set as pattern.
--
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Possible feature request for 'q' shorthand or tie syntax
av = #(define-music-function (parser location x) (ly:music?)
#{
\changePitch \samePitch { c8 ~ c4 } $x
#})
But of course, for this example, this will work without any added file :-)
av = #(define-music-function (parser location x) (ly:pitch?)
#{
$x 8 ~ $x 4
#})
\new Staff \relative c' {
c4. \av es f4
fis4. \av fis g4
}
--
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Possible feature request for 'q' shorthand or tie syntax
But of course, for this example, this will work without any added file
av = #(define-music-function (parser location x) (ly:pitch?)
#{
$x 8 ~ $x 4
#})
... but it will fail with chords
[ ly:pitch? return false of course, for ]
\new Staff \relative c' {
c4. \av f4 % error
}
Well ... stop of experimentations for me, for this evening.
--
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Possible feature request for 'q' shorthand or tie syntax
You noticed yourself that this does not work well with chords, but it
also does not play overly well with \relative if you write \av c' for
example.
In the \samePitch function, i try to play with the property
'to-relative-callback. It seems to work also here but of course, it is
heavier -:( (see below )
For chords, is it conceivable to imagine a ly:pitches? function, (so for
chords), that would be compatible in #{ #}, in the same way ly:pitch? is.
And even, an ly:pitch?-or-ly:pitches? function for notes and chords ?
(well, probably with better names ...)
--
Gilles
%%
#(define (set-rel-callback tied-music)
"set all pitches to the pitch of the first note, in relative mode."
(let((not-first? #f))
(map-some-music
(lambda (x)
(case (ly:music-property x 'name)
((or NoteEvent EventChord)
(if not-first?
(ly:music-set-property! x 'to-relative-callback
(lambda (x p) ; set pitch to the prev value
(ly:prob-set-property! x 'pitch p)
p)))
(set! not-first? x)
x)
(else #f)))
tied-music)))
av = #(define-music-function (parser location x) (ly:pitch?)
(set-rel-callback
#{
$x 8 ~ $x 4
#}))
\new Staff \relative c' {
c4. \av c' f4
fis4. \av fis, g4
}
%
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: rhythm fragments in different pitches
I am trying to code a piece with voices that use the same rhythmical fragment over and over again. [..] Perhaps this one : http://lsr.dsi.unimi.it/LSR/Item?id=654 But LSR gives also other answers with the keyword : rhythm http://lsr.dsi.unimi.it/LSR/Search?q=rhythm -- Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: rhythm fragments in different pitches
Le Sat, 22 Sep 2012 14:44:19 +0200, Gilles a
écrit:
I am trying to code a piece with voices that use the same rhythmical
fragment over and over again. [..]
Perhaps this one :
http://lsr.dsi.unimi.it/LSR/Item?id=654
Oh to bad. When i send my message, i had no answers from anybody to the
initial message... Sorry
I answer to all messages at one time :
> I get a whole set of errors
At the end of the snippet, there is a link "here", to download the *last*
version of the snippet. Old versions don't work with Lilypond 2.16.
Well, i must admit that i didn't test \changePitch with 2.17
> applyRhythm = #(define-music-function [...]
The code given by David is an example for all of conciseness, but has some
limitations
1- Doesn't work with chords
melody = \relative c { a g f e b} % error
2- All articulations in melody will be ignored
melody = \relative c { a\p d-> g( f e) b} will gave the same
result than
melody = \relative c { a d g f e b}
3- You cannot have rests in the patterns
so you cannot have a pattern like :
rhythm = { c8 r8 r8. c16 }
--
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: rhythm fragments in different pitches
Every code has limitations. Oh yes, of course. My message was just an information/advertisement for users looking for a rhythm pattern function. In a more general way, i really thank you, David, to post all these pieces of code, because it is very instructive for people trying to learn scheme. In your last code for example, i learn a util use of the circular-list that i could not imagine, and well, probably i will have to reconsider some pieces of my code ... -- Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Trying to set global staff size on the commandline using -e option
My command I am trying to run is
lilypond -e '#(set-global-staff-size 32)' --pdf myfile.ly
Hello James
I had a similar problem in the past
http://lists.gnu.org/archive/html/lilypond-user/2011-08/msg7.html
To run successfully your file, i have changed a bit your code and your
command line.
(Don't ask me why your code didn't work)
--snip--
\version "2.16.0"
#(use-modules (guile-user))
#(if (defined? 'mysize) (set-global-staff-size mysize))
% #(if (defined? 'mysize) (format #t "mysize : ~a\n" mysize ))
{ a b c d }
--snip--
-- command line --
lilypond -e "(define mysize 30)" --pdf myfile.ly
--
If you are not in Windows, perhaps you'll have to change "" by '
#(use-modules (guile-user)) gives error messages also for me
--
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: pitch name transpose into numeric per key signature
Le Sun, 28 Oct 2012 23:16:34 +0100, MING TSANG a
écrit:
(let* ...
(scalestep (modulo
(- (ly:pitch-notename pitch) (...base of key signature...)) 7))
(name (format #f "~a~a"
(string-ref "1234567" (scalestep))...
If i well understand what you want, there is a snippet very near of what
you are searching.
http://lsr.dsi.unimi.it/LSR/Snippet?id=818
The code below is a "mix" of the code you gave and this snippet.
%%
numbr = #(make-engraver (acknowledgers
((note-head-interface engraver grob source)
(let* (
(context (ly:translator-context engraver))
(tonic-pitch (ly:context-property context 'tonic))
(tonic-index (ly:pitch-notename tonic-pitch))
(event (ly:grob-property grob 'cause))
(grob-pitch (ly:event-property event 'pitch))
(grob-index (ly:pitch-notename grob-pitch))
(delta (modulo (- grob-index tonic-index) 7))
(name (list-ref '("1" "2" "3" "4" "5" "6" "7") delta))
(newgrob (ly:engraver-make-grob engraver 'TextScript event)))
(set! (ly:grob-property newgrob 'text) name)
music = \relative c' {
\key c\major c4 d e f g a b2 |\break
\key g\major g4 a b c d e fs2 | \break
\key ef\major ef,4 f g af bf c d2 | \break
\key d \major d,4 e fs g a b cs2 | \break
\key cf\major cf,4 df ef ff gf af bf2 | \break
}
\score{
\new Staff \with {\consists #numbr }
\music
\layout {}
}
%%%
--
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: pitch name transpose into numeric per key signature
The code below is a "mix" of the code you gave and this snippet. I forget \include "english.ly" (It's was the original language) -- Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: pitch name transpose into numeric per key signature
One question though: Can the numeric displayed above the staff?
Just set the property of newgrob to UP ( = 1 )
numbr = #(make-engraver (acknowledgers
((note-head-interface engraver grob source)
(let* (
(context (ly:translator-context engraver))
(tonic-pitch (ly:context-property context 'tonic))
(tonic-index (ly:pitch-notename tonic-pitch))
(event (ly:grob-property grob 'cause))
(grob-pitch (ly:event-property event 'pitch))
(grob-index (ly:pitch-notename grob-pitch))
(delta (modulo (- grob-index tonic-index) 7))
(name (list-ref '("1" "2" "3" "4" "5" "6" "7") delta))
(newgrob (ly:engraver-make-grob engraver 'TextScript event)))
(set! (ly:grob-property newgrob 'text) name)
(set! (ly:grob-property newgrob 'direction) UP)
%%
--
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: pitch name transpose into numeric per key signature
Additional question: Can the numeric line up horizontally?
I am 3 days late answering.
The traditional way to do that is to override the padding property, but I
wanted to explore the method using context, that I was not used to.
Here are the result of my tries.
%%
\include "english.ly"
%% http://lsr.dsi.unimi.it/LSR/Snippet?id=818
%%%
numbr = #(make-engraver (acknowledgers
((note-head-interface engraver grob source)
(let* (
(context (ly:translator-context engraver))
(tonic-pitch (ly:context-property context 'tonic))
(tonic-index (ly:pitch-notename tonic-pitch))
(event (ly:grob-property grob 'cause))
(grob-pitch (ly:event-property event 'pitch))
(grob-index (ly:pitch-notename grob-pitch))
(delta (modulo (- grob-index tonic-index) 7))
(name (list-ref '("1" "2" "3" "4" "5" "6" "7") delta))
(newgrob (ly:engraver-make-grob engraver 'TextScript event)))
(set! (ly:grob-property newgrob 'text) name)
;(set! (ly:grob-property newgrob 'direction) UP)
%%%
music = \relative c' {
\key c\major c4 e g b d f a2 |\break
\key g\major g,,4 b d fs a c e2 | \break
\key ef\major ef,4 g bf d f af c2 | \break
\key d \major d,,4 fs a cs e g b2 | \break
\key cf\major cf,,4 ef gf bf df ff af2 | \break
}
%%%
\markup "with padding"
\score{
\new Staff \with {
\consists #numbr
\override TextScript #'direction = #UP
\override TextScript #'padding = #3
}
\music
\layout {}
}
%%%
\markup "with a new context"
\score { <<
\new NumbrStaff \music
\new Staff \music
>>
\layout {
\context {
\type Engraver_group
\name NumbrStaff
\consists Output_property_engraver
\consists Key_engraver % needed for tonic pitch
\consists Note_heads_engraver % needed for pitch of note
\consists Text_engraver
\consists #numbr
\consists Axis_group_engraver
\override KeySignature #'stencil = ##f
\override KeyCancellation #'stencil = ##f
\override NoteHead #'stencil = ##f
% this section is a copy of NoteNames engraver in engraver-init.ly
\override VerticalAxisGroup #'staff-affinity = #UP
\override VerticalAxisGroup #'nonstaff-nonstaff-spacing =
#'((basic-distance . 0)
(minimum-distance . 2.8)
(padding . 0.2)
(stretchability . 0))
\override VerticalAxisGroup #'nonstaff-relatedstaff-spacing =
#'((basic-distance . 5.5)
(padding . 0.5)
(stretchability . 1))
\override VerticalAxisGroup
#'nonstaff-unrelatedstaff-spacing #'padding = 1.5
}
\context { \Score \accepts NumbrStaff }
}
}
%
-- Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Extract notes within music function
Is it possible to extract individual notes from the music passed to a
music function, e.g.:
\myFunction { c d e f }
Within myFunction, can I do something like
car notes
cdr notes
Here is a kind of template, but i am not absolutely sure it's what you
want.
myFunction = #(define-music-function (parser location music)(ly:music?)
(map-some-music
(lambda (evt)
(let ((name (ly:music-property evt 'name)))
(cond
((eq? name 'EventChord)
; to see the structure of a chord
(display-scheme-music evt); to comment
; do something with the chord
evt) ; return the modified chord - don't go deeper
((eq? name 'NoteEvent)
; to see the structure of a note
(display-scheme-music evt); to comment
; do something with note
evt) ; return the modified note - don't go deeper
(else #f ; => #f = continue, go deeper
music))
music = \relative { c2->\f 2-> }
\myFunction \music
--
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Extract notes within music function
Is it possible to do something just with the first and last notes of
music within? Can they be extracted from music as from a list? (Hence
my reference in the original post to car and cdr)?
In music-functions.scm, you have some useful functions. Here an
extract-music is used.
%%%
music = \relative { c2->\f d e 2-> }
#(let ((mylist
(extract-music music
;(lambda (evt)(eq? (ly:music-property evt 'name) 'NoteEvent)
(lambda (evt)(memq (ly:music-property evt 'name)
'(NoteEvent EventChord))
(display-scheme-music (car mylist))
(display " \n")
(display-scheme-music (last mylist)))
NB
Aleksandr, sorry for the double messages.
--
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Alignment of full-page scores in text documents
On Mon, 29 Jan 2018 09:03:46 +0100, Urs Liska wrote: Hi all, I'm trying to figure out the best setting for page margins for mixed text/music documents. The task is to automatically set the margins in LilyPond depending on a LaTeX document where full-page scores are included. We have the horizontal margins more or less fixed, by default LilyPond's staff symbol will exactly match LaTeX's linewidth. When naively setting LilyPond's vertical margins to those of the text the result is (expectedly) rather ppor, as you can see here: https://github.com/jperon/lyluatex/issues/29#issuecomment-361159545. What I would basically want to achieve is mathing the outermost *staff lines* with the text's type area. When manually trying different values I found that I would like the topmost staffline align not with the actual margin but the X-height of the corresponding text. This can be seen here: https://github.com/jperon/lyluatex/issues/29#issuecomment-361162799 On that same image the bottom staff line is aligned to the baseline of the text, and I'm not sure if that is the right choice. Somehow the score visually looks lower than the text, Isn't it because the "center of mass" of the notes in the last staff is below it? I'd guess that a similar (i.e. too high) effect would exist for the top staff if most notes were above it. My impression is that the latter image looks fine, once you assume that the "visual frame" is induced by the (empty) staves. Regards, Gilles and I wonder whether there should be a similar amount of padding like at the top margin. But of course there is no "natural" reference point here. What is your opinion on this issue? Best Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: from single staff to piano staff
try LSR: http://lsr.dsi.unimi.it/LSR/Item?id=545 The version for 2.16 is here : http://gillesth.free.fr/Lilypond/chord/ -- Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond Cheat Sheet 2.18
Good job! Thanks (I'll give the links on the French list when updated).
- Commentaire % … und %{ … %}
+ Commentaire % … et %{ … %}
[ ... ]
Perhaps too late, but
alterations doesn't fit to \language "français"
is -> d
ish -> sd
isis -> dd
isih -> dsd
es -> b
eh -> sb
eses -> bb
eseh -> bsb
NB
As it is my first post here in 2014, happy new year for everybody
--
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: extract notes into voices
Le vendredi 14 mars 2014, 00:47:28 Gilles a écrit :
> Le mercredi 12 mars 2014, 14:12:57 MING TSANG a écrit :
> > Hi, lilyponders,
> > I browse the LSR and find this extractNote. I is somthing that I can use.
> > Please refer to .pdf : Is it possible to modify this LSR so that bar 5
> > also
> > be extracted to soprano staff and alto staff? I don't know scheme code.
> > BTW
> > - congratulation to Janek and Urs and Oskar Fried project
> > Emmanuel,
> > Ming
>
> I have joined my original file (chord.ly) that contains the \extractNote
> function, a \extractVoice function, and 2 derivated functions
> \extractPartUpper and \extractPartLower, that you can use in your ly file.
>
> Note that the name of "chord.ly" is probably a bad choice and should rather
> be "chord&voice.ly" or something like that.
Ouch, as you enter notes in a chords beginning by the upper one ( generally a
chord is read from lowest to top), you have to re-define the \extractPartUpper
and \extractPartLower
extractPartUpper = #(define-music-function (parser location music )(ly:music?)
"Extract 1st note of each chords, and 1st element of simultaneous music"
#{ \extractNote #1 \extractVoice #1 $music#})
extractPartLower = #(define-music-function (parser location music )(ly:music?)
"Extract last note of each chords, and last element of simultaneous music"
#{ \extractNote #1000 \extractVoice #1000 $music#})
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: entering chords
Le dimanche 23 mars 2014, 03:59:21 MING TSANG a écrit : > c: the sample .ly has several functions -\extractNotes ; \ePU ; ePL etc. > and I find several things I don't understand. please refer to .pdf file. Dear Ming. As it seems that some points are not enough clear about "chord.ly", I tried to make a little doc about the functions contained in this file. You can download "chord-doc.pdf" here : http://gillesth.free.fr/Lilypond/chord/ You'll find also in this directory, the last version of "chord.ly" In this subject, I have to apologize to you about the file "chord.ly" I send to you in this thread : http://lists.gnu.org/archive/html/lilypond-user/2014-03/msg00317.html The \extractVoice function required an integer as parameter but an old version required a decimal number ! So your mistake was my fault. Sorry. Actually, there was here 2 features. So in this last version there is 2 functions : \extractVoice that requires an integer. \deepExtractVoice that requires a decimal number See the doc to know the difference. Feel free to ask some precisions here if you need it. -- Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Changes to LSR #542 (extractMusic et al.)
Le mardi 29 avril 2014, 16:20:32 Jim Long a écrit : > I'm trying to track down a problem I'm having with a file I store > as extractMusic.ily, which claims to descend from LSR #542. My > copy says it's for 2.16 or later, which makes it older than the > current snippet #542. > > My old version is attached. > > The new version is at: > > http://lsr.di.unimi.it/LSR/Snippet?id=542 > If you look at : http://lsr.di.unimi.it/LSR/Item?id=542 there is a link at the end of the snippet to get the full version -- Gilles ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Replying to posts
Hello. On Wed, 27 Apr 2016 13:44:39 +0200 (CEST), Martin Tarenskeen wrote: On Wed, 27 Apr 2016, David Kastrup wrote: Looks like I'm no longer welcome on this list. I'll unsubscribe and leave it to the people who understand the medium better. I assume that I'm more welcome on the developer list. People there are more likely to get along with conveying messages using text. Don't let a handful of over-sensitive people upset you. And the other way around I also want to ask them: don't let people like David Kastrup upset you either. I'm assuming that the majority of readers of this mailing-list couldn't care less what mailclient everyone is using, if their mail is html formatted or plain text, if we should top-post or not, etc. The primary issue is not about "a majority" (who may not have a clue why HTML mail ranges from bad to evil) but respect towards those who read the messages, and try to help the posters. It should take much less time for readers to figure out what the question is, than it took the posters to write them. If, out of lazyness, the latter plainly ignore the rules aimed at conveying more information than noise, the list owner should consider banning them, rather than risk putting off those who follow the rules. Regards, Gilles The majority of readers of this mailinglist just wants to discuss the usage of LilyPond. That's why this list is called "lilypond-user". Everyone who has valid questions, sensible answers, or interesting stories around this subject is more than welcome. And David fits this description perfectly. So please don't unsubscribe. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Replying to posts
On Fri, 29 Apr 2016 10:40:09 +1000, Andrew Bernard wrote: Hi Gilles, As far as I know this particular list does not have a list owner, and there are no published rules. List owner/adminstrator/moderator: ie. someone who has the privilege to unsubscribe other people. People here have given reasons that can translate into (implicit) rules. Another (meta-)rule is to behave the same way as others do (e.g. looking at the archives could give hints as to what is the norm). There are many web pages about (other) mailing lists etiquette. Regards, Gilles Andrew On 27/04/2016, 10:05 PM, "lilypond-user on behalf of Gilles" wrote: If, out of lazyness, the latter plainly ignore the rules aimed at conveying more information than noise, the list owner should consider banning them, rather than risk putting off those who follow the rules. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Changing and playing a different instrument in MIDI
On Fri, 22 Jul 2016 08:51:52 +0200, Mojca Miklavec wrote:
Hello,
I don't have much experience with MIDI. I just tried all the media
players on OS X and realized than only QuickTime Player 7 had some
very very basic support for playing MIDI files (I cannot even make it
play loud enough, let alone do anything else with it). None of the
others I have installed worked (VLC, MPlayerX, QuickTime Player,
RealPlayer, ...)
So I went on and made a package for TiMidity++ and freepats.
The problem is: I'm still unable to figure out how to change the
instrument to anything but Piano.
Here's a minimal example:
\score {
\new PianoStaff
<<
\new Voice = "melody" \fixed c'
{
\set midiInstrument = #"accordion"
\time 3/4
f4 g a
}
>>
\midi{ \tempo 4 = 100 }
}
But this doesn't help me in any way.
\set Staff.midiInstrument = "accordion"
HTH,
Gilles
[...]
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Music runs off the page (LY version 2.9.9)
On Mon, 12 Sep 2016 18:24:53 +1000, Brent Annable wrote: Hello everyone, I am not a frequent Lilypond user, and am writing to ask for a (hopefully quick) favour here. I hope that's okay. I wanted to transpose BWV 848 from c-sharp major into d-flat major to make it easier for me to read, so I downloaded some old Mutopia engraving files from IMSLP and added a simple 'transpose' command. That worked fine, except the final bars of the piece now run off the last page. I have attached the modified .ly file and PDF. Frescobaldi gives error messages for the following beaming instructions in the engraving file: #(override-auto-beam-setting '(end * * * *) 1 4 'PianoStaff) #(override-auto-beam-setting '(end * * * *) 1 2 'PianoStaff) #(override-auto-beam-setting '(end * * * *) 3 4 'PianoStaff) Could that have anything to do with it? My only Lilypond experience has been with version 2.14; this file is from 2.9 and the current version is 2.18, so I'm at a loss for why it isn't working. I'm hoping someone with a better knowledge of the program's history and syntax can help identify the problem? I would be very grateful. Did you run it through "convert-ly"? Regards, Gilles Many thanks for any help, Brent Annable. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Dorico release and tutorials
On Wed, 19 Oct 2016 12:44:22 +0200, Urs Liska wrote:
Am 19.10.2016 um 12:41 schrieb David Kastrup:
Pierre Perol-Schneider writes:
I just watched the vids. One thing I appreciate is the pages layout
possibilities.
It would be great if LP had something like:
\paper {
%defaults settings:
right-margin = 10
left-margin = 10
%specific page settings:
\page #1 {
right-margin = 20
left-margin = 20
}
page.1.right-margin = 20
page.1.left-margin = 20
}
I'm not saying that we currently have this, just that this would be
one
possible interface.
Doesn't the page number depend on how the previous material
has been typeset?
That looks very nice.
On a related note (not knowing whether Dorico has this) it would also
be
great to be able to specify the global-staff-size for individual
pages.
It's pretty common in larger orchestral scores that you have only a
small number of pages where you need the full orchestra and want to
have
smaller staff size.
It seems to me that, rather than "specify the global-staff-size
for individual pages", it should be "from now on, magnify the
global-staff-size so that systems fit the page".
Regards,
Gilles
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Dorico release and tutorials
Hi. On Wed, 19 Oct 2016 09:21:32 -0400, Kieren MacMillan wrote: Hi Gilles, Doesn't the page number depend on how the previous material has been typeset? Not if breaks are forced, etc. Unforced breaks can depend on previous margin settings, possibly making the numbering wrong when the user reruns the compilation with different settings. It seems to me that, rather than "specify the global-staff-size for individual pages", it should be "from now on, magnify the global-staff-size so that systems fit the page”. Why “rather”? Why not “in addition to”? Because (I guess that) the former will not likely produce the expected output, particularly when there are many pages. Unless you mean that the typesetting should only rely on forced breaks. Regards, Gilles Cheers, 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
