Re: What is the problem with \relative? (Was: Do we really offer the future?)
Hello Urs Urs Liska wrote ... Another important topic for commercial users may be the management of the source code for all PDFs (and other output). What do you mean here? And finally multiple people may have to working parallel on the same score. This is something that is already working absolutely great with LilyPond scores. Urs ... I just think on my 'huge score'. 24 pieces (movements) originally published with 'Piano Direction' istead of a score, I put the 17 parts (including the 'piano direction' and 'piano solo' together to a score. Per instrument each piece a single soucre file, one compilable LY per each combination (piece and instrument, as well as 'score of a single piece') for the 'editing workflow', and one compilable LY per each instrument part, transposed alternative instrument part and score (all 24 pieces) for the 'publishing workflow', some common includes (e.g. Title of the pieces) did result in more than 900 LY files. I can imagine, if ten persons are working parallel to make such an edition avalible in a short time, it's not a good idea to just save the file on a comon shared folder, with the danger to overwrite a file a colleague had modified and saved just a short time before. Well, I admit, in CAD usage the reuse of existing objects is much more complex. Urs Liska wrote Compared to the CAD software, Lilypond is missing (around it's kernel): - a graphical user interface (GUI) to enter/edit the source (with a simplified graphical representation of the music notes) I'm not clear what you mean here, but in any case this too is an issue for the IDE. Frescobaldi provides the Quick Insert panel. You can select multiple notes in the input file or the music view and then apply e.g. staccato to all notes at once. On my way-too-long wish/todo list is an object inspector/editor for Frescobaldi, which should basically be rather straightforward to implement. This panel would be aware of the grob the cursor is currently in (or the grob that has been selected in the Music View) and then show all available properties that can be tweaked for that element (actually Frescobaldi already knows about these properties which it uses for autocompletion). Then there should be convenient ways to edit values in that dialog. - automatic source code update to new versions (from open file to file loaded into the RAM of the editor) Is this really important? I'd be scared when my editor does that automatically. - point-and-click positions have idenpendent IDs, which are stable during editing the source (e.g. if you edit the LY files and insert a line) Frescobaldi does that. ... My observation on CAD usage is, approx. 3 % of the users are going to use features which are similar to programmng. The remaining 97 % use the GUI only and avoid using such features, they have to think as a programmer. I hope, for music notation users this ratio is better, but I don't believe it'll reach 20 %. So, a good GUI editor for LY files could increase the acceptance of the users a lot. And it's an important question for such a GUI, how versions updates will be handled - but this also depends on your file managment (will you save the history in the editing process?) What's to expect if you restart editing a 20 years old publication? Can only the guru process all required updated, or is the work of the guru limited to fix the remaining problems (by using an utf8 text file editor) only? IMHO, the publishing companies would prefer a complete suite of lilypond (the kernel), an editing GUI (for user acceptance) and file management (recommended at least for cooperation of multiple users) ArnoldTheresius -- View this message in context: http://lilypond.1069038.n5.nabble.com/Do-we-really-offer-the-future-tp174675p175458.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: how apt are comparisons to TeX/LaTeX?
So the first question is: how much of lilypond's goals and design are based on TeX/LaTeX? This is just my understanding, but I believe LilyPond is intended to be a music-engraving equivalent of LaTeX. IIRC it actually began life as a LaTeX package (MusicTeX? or was it another one?). Along these lines comes a series of other questions: Is what you see is what you mean input is the goal? Yes I think so. I think the goal is to produce as close to optimal printed output as possible with as little manual editing as possible. I think separating content and presentation is also a goal. Is there the same TeX=detailed typesetting (engraving), LaTeX=hides users from the details of those details (mostly) concept for Lilypond? [I believe that this is one way to roughly characterize the difference] Not really. I think LilyPond contains a little of both, but is more like LaTeX than plain TeX. Just my two cents, Kevin ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: how apt are comparisons to TeX/LaTeX?
Am 27.04.2015 um 12:46 schrieb Kevin Barry: So the first question is: how much of lilypond's goals and design are based on TeX/LaTeX? This is just my understanding, but I believe LilyPond is intended to be a music-engraving equivalent of LaTeX. IIRC it actually began life as a LaTeX package (MusicTeX? or was it another one?). I'm not sure about the package thing (althought I doubt it) but initially LilyPond's actual grob placement was done by TeX. So I'd say initially LilyPond was like a LaTeX layer around TeX. Along these lines comes a series of other questions: Is what you see is what you mean input is the goal? Yes I think so. I think the goal is to produce as close to optimal printed output as possible with as little manual editing as possible. I think separating content and presentation is also a goal. I think this isn't really correct. WYSIWYM is used for tools like LyX that give you a rough approximation of the final output so you can see what you mean. This is really not what LilyPond is about. I think Denemo is offering just that, a preliminary visual representation while you enter the music and that you can at any time make perfect by calling LilyPond upon the input file. Urs Is there the same TeX=detailed typesetting (engraving), LaTeX=hides users from the details of those details (mostly) concept for Lilypond? [I believe that this is one way to roughly characterize the difference] Not really. I think LilyPond contains a little of both, but is more like LaTeX than plain TeX. Just my two cents, Kevin ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
Am 23.04.2015 um 17:04 schrieb Gilles: Hello. On Thu, 23 Apr 2015 12:09:29 +0200, Urs Liska wrote: Hi all, First of all: I have _not_ asked the LilyPond team to spend any resources for whatever. First of all, nobody wrote that you did. Well, let's say that perhaps your initial reply offered the possibility of misinterpretation. Second: The intention of my post is _not_ to find ways to help publishers do their business, to help them increase their profit, to please them, to sell LilyPond's soul to the sharks or whatever some commenters wanted to read from it. I must admit it's somewhat disappointing to be misunderstood that way, Perhaps your initial post offered the possibility of misinterpretation. Re-reading it again I see that I didn't explicitly write that my interest is in getting LilyPond a stronger support by opening the door for new users and customers. And maybe it was naive to assume that I could take this for granted from all the other things I have written over the last two years (from that perspective: what other motivation should I have than to strengthen LilyPond's position?). Probably both is due to the fact that I instantly wrote these messages on may way back home in the bus, after two days at the fair ... But I can't read anything from it that points to a anything that altruistically takes on the perspective of the publishing industry. and I somehow feel attacked below the belt by such comments. Nobody attacked you. [Not even if you actually held the idea of defending big publishers profits (which would be your right).] I'm sorry that you misinterpreted an honest response to your honest request for comment as a treacherous personal attack. I didn't say treacherous and I explicitly didn't mean you exclusively (otherwise I'd have said so). ### To whom LilyPond should strive to offer the future? IMHO, certainly not to the [...] big house[s] with traditions, regulations and limitations. What's for the LilyPond team in spending resources trying to work around those self-inflicted limitations? and Can you tell me why we should be interested in helping music publishers exactly? I don't inherently care about the fate of publishing houses. But I think there are a few self-inflicted limitations in LilyPond's attitude that should be overcome to assist LilyPond to survive or at least to prevent it from eventually being doomed to insignificance. I assure you that I understand your frustration (from personal experience in another project). As much as I agree with the risk, prediction of doom is not a working argument (from personal experience in another project...). You asked for my motivation and intention. And as I care about LilyPond's future and significance this is the answer. The main point here is not about helping publishers do their business but (and that is a point that hasn't been discussed at all in this thread) to help LilyPond evolving through an increased user and developer base. I do agree with that goal, and I did mention the idea of a project towards that goal (albeit using another direction that would probably displease the big publishers). So then it might be more fruitful to call that another idea, rather than categorically dismissing the efforts of someone who invests considerable time and effort in LilyPond. LilyPond's developer base is too thin, to a dramatic extent in my opinion. ... I agree as I said above (that lacking resources is a risk). I understood your original post as doing more with less, in the sense that we (community) should (in order to solve the problem) work towards satisfying the limitations of big publishers. I might have misinterpreted, but you did not give explicit examples beyond the existence of problems with big publishers (or IOW big publishers having a problem with LilyPond). OK. This sentence with limitations in it was probably sloppy. What I mainly referred to as limitations is the fact that changing technology is a major consideration for anybody, and that I was lacking the striking arguments for pushing someone in the right direction. IIUC, your idea is that the user base would grow if LilyPond were used by big publishers. This I can perhaps imagine. [Although from what I read on this list, a SCORE program exists that is/was used by publishers and yet does not seem to have a large user base.] Yes, SCORE is a commercial program that is still in limited use and which is regarded as superior to all others by some publishers. AFAIK Schott and Carus are two bigger publishers who use SCORE. There's another text based notation program, Amadeus, that is used by a handful of engravers for an even lower number of publishers, with Henle presumably being the most prominent example. So one new aspect in the discussion is my observation that being based on plain text is not the fundamental obstacle for being adopted in a commercial market. There must be other aspects
Re: Function to add a drone staff?
I've added this dronify snippet to the LSR, for future reference: http://lsr.di.unimi.it/LSR/Item?u=1id=997 -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/Function-to-add-a-drone-staff-tp174261p175515.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Color tweaks (edition engraver)
Hey David,
this is terrific. Nice that something I've done comes back to me this
way ...
When I'll have the time I'll look into integrating this into
Frescobaldi's Layout Control Options.
Urs
Am 27.04.2015 um 23:14 schrieb David Nalesnik:
On Mon, Apr 27, 2015 at 12:16 PM, David Nalesnik
david.nales...@gmail.com mailto:david.nales...@gmail.com wrote:
On Mon, Apr 27, 2015 at 12:12 PM, David Nalesnik
david.nales...@gmail.com mailto:david.nales...@gmail.com wrote:
Here's a code snippet to show that it is possible to tell if a
grob has been altered. Right now you have to add the
procedure for each grob you want to examine.
The following covers all changed grobs. Thanks, Urs, for your posting
at http://lilypondblog.org/2014/04/music-functions-4-recursion/ -- I
adapted one of your functions there to apply the override to all
objects with a stencil property. (Rather than using a long string of
laboriously typed overrides.)
--DN
\version 2.19.17
#(define (grobs-with-stencils)
(let loop ((all all-grob-descriptions) (result '()))
(if (null? all)
result
(if (assoc-get 'stencil (cdar all))
(loop (cdr all) (cons (caar all) result))
(loop (cdr all) result)
#(define (mark-tweak grob)
(let* ((default (assoc-get (grob::name grob) all-grob-descriptions))
(default-after-line (assoc-get 'after-line-breaking default))
(props (ly:grob-basic-properties grob))
;; Our procedure has been added to the head of grob's basic
;; properties. Let's not count it as a tweak!
(props
(remove
(lambda (p)
(and (procedure? (cdr p))
(eq? (procedure-name (cdr p)) 'mark-tweak)))
props))
(diff (lset-difference eq? props default)))
;; Tweaks will not appear in the basic properties alist of our
grob, but
;; we can find them through the music event which led to the
grob. This
;; is available through the stream-event which caused our grob.
(if (null? diff)
(let* ((cause (event-cause grob))
(tweaks (and cause
(ly:music-property
(ly:event-property cause 'music-cause)
'tweaks
(if (pair? tweaks)
(set! (ly:grob-property grob 'color) red)))
(set! (ly:grob-property grob 'color) green))
;; Return any default setting of after-line-breaking.
(or default-after-line '(
markAllAlteredGrobs =
#(define-music-function (parser location) ()
(let loop ((grobs (grobs-with-stencils)))
(if (null? grobs)
#{ #}
#{
\override #(list 'Score (car grobs) 'after-line-breaking) =
#mark-tweak
#(loop (cdr grobs))
#})))
{
\markAllAlteredGrobs
c'
\once \override NoteHead.font-size = 3
c'
c'
\tweak font-size 3 c'
c'
%\override Slur.after-line-breaking = #mark-tweak
c'( e')
\shape #'((0 . 0) (0 . -0.5) (0 . -0.5) (0 . 0)) Slur
c'( e')
c'( e')
c'-\tweak Slur.positions #'(-5 . -5) ( e')
\override Hairpin.color = #blue
c'\ e'\!
c' e'\arpeggio
\once \override Staff.Arpeggio.positions = #'(-6 . 6)
c' e'\arpeggio
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Color tweaks (edition engraver)
On Mon, Apr 27, 2015 at 04:44:52PM +0200, Urs Liska wrote: What we have in Frescobaldi depends on what we can catch by either listening through engravers or by redefining command. So far I haven't found a notion of a grob knowing if it has been tweaked or not. As a Scheme/Lilypond novice sitting on the sidelines, I have a difficult time judging whether my comments are obvious, stupid, trival, useless, impractical, or some exquisite combination of all five, but (oh, and there's poorly thought-out) If the grob doesn't know whether it's been tweaked, then perhaps \tweak could do it? Or, perhaps one could create a wrapper directive \ctweak which invokes \tweak to perform the specific tweak that was requested, and then \ctweak could also color the grob that got tweaked? Having to change one's code from tweak to ctweak and back may be less than ideal. Perhaps a global variable (ugh) could be used by \ctweak, defaulting to black, so that by default \tweak and \ctweak are equivalent, except that a user of \ctweak could alter the global color variable to something other than black, resulting in all the \ctweaks appearing in that color. I can't think offhand how to extend this to support users who use a color other than black as the base color for engraved grobs, or for how to show tweaked grobs which already use \ctweak's global tweak color. But if \tweak is defined in terms of Scheme/Guile code (I'm ignorant on that point), perhaps a Scheme guru can write a first-order approximation of \ctweak that could be included in any project's source code where it is desired. A deeper change might be to add a property to all grobs that contains a tweak-count, initialized to 0. \tweak would increment the count of each grob it touches, and then the grobs would know whether they've been tweaked or not. Pretty sure this is the obvious option in paragraph 1. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Creating LilyPond Object Models
Hi Urs, It was inspired mostly by Carl’s post and working on Jianpu notation. A tutorial on this is not a bad idea. That said: (1) it would benefit from fitting into, or coming after, a broader overview of LilyPond like Carl has written (2) it sounds like the way we create scheme engravers may change in the near future (based on David Kastrup’s post from earlier today) so probably best to wait until after that (3) it might be good to add some more documentation of this to the official extending manual first. For now maybe I’ll just add my example with comments to the LSR as a quick temporary measure. Cheers, -Paul On Apr 26, 2015, at 12:08 PM, Urs Liska u...@openlilylib.org wrote: Hi Paul, I don't know if that's in any way related to our talk yesterday or if it has exclusively been triggered by Carl starting it. But this is very much a skeleton of what I was talking about! It would be absolutely great if you could pour that into a tutorial on the basics of writing Scheme engravers. Maybe users will usually not need this kind of information, but OTOH users often need solutions that can be provided using this technique. So having a slow-paced introductions may well lead to a greater number of people daring to dive into these waters. Best Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
getting involved with LilyPond (was: Do we really offer the future?)
Hi Kevin, 2015-04-24 6:49 GMT+02:00 Kevin Tough ke...@toughlife.org: On Thu, 2015-04-23 at 13:06 -0500, David Nalesnik wrote: (Please take this as a plea for more help with the project! It is not intended to downplay the efforts by the contributors to this thread.) Hi David and others, as a old hobby I programmed with VS. I use Linux and through Fedora I found Lilypond. Although at the moment I have no time for programming I will hope to change things in the future. As a prospective future contributor to code for Lilypond is it easy enough to start with QT4 using their free open source licensing model or what direction would you suggest. I really like Vim but am not anywhere near a power user yet. In that case I definitely recommend you to use an IDE like QtCreator (I have used it myself for LilyPond work), it will make your life much easier. Anyway, it would be great to see you contributing! I've just returned to LilyPond after a long break and I'm interested in helping other people getting involved. If you'd like some general help/guidance, let me know and I'll do what I can. best, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: teaching a university module on engraving with lilypond
Dear Kevin, On Apr 27, 2015, at 10:18 AM, Kevin Barry barr...@gmail.com wrote: The scope of the course will be to teach some of the finer points of engraving (Gould is the module reference text) and then get them to produce their own editions of out-of-copyright scores which we will then try to upload to mutopia (and perhaps imslp, but I haven't looked into that). This sounds fantastic, congrats! If you are looking for scores to work on you might start here: https://github.com/MutopiaProject/MutopiaProject/issues/355 These are scores that are popular on IMSLP (in terms of downloads) but aren’t (yet) available on mutopia. And there may be more where those came from if you inquire on the mutopia mailing list. All the best, -Paul___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Concepts that may be missing (or are at least hidden) in LilyPond
On 27/04/2015 15:45, Urs Liska wrote: Maybe LilyPond could run through only the first stage (i.e. without producing graphical or MIDI output) and analyze the score. On that way it parses all existing contexts and could maybe determine the positions of all music content. It could then output some kind of list representation that allows an editor like Frescobaldi to determine the locations of all objects inside the requested area in order to take action. Maybe this could also take care of noticing open spanners that are closed inside the range, so that an editor can also offer solutions or ask the user what to do with these. Of course this is a highly simplified sketch, and there's much that has to be considered. But it *could* be an approach. Urs This only first stage run could also make possible to have a quick feedback, so that the editor can show where there are errors without having to compile the score. Anton Curl ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Creating LilyPond Object Models
Am 27.04.2015 um 23:24 schrieb Paul Morris: Hi Urs, It was inspired mostly by Carl’s post and working on Jianpu notation. A tutorial on this is not a bad idea. That said: (1) it would benefit from fitting into, or coming after, a broader overview of LilyPond like Carl has written (2) it sounds like the way we create scheme engravers may change in the near future (based on David Kastrup’s post from earlier today) so probably best to wait until after that (3) it might be good to add some more documentation of this to the official extending manual first. For now maybe I’ll just add my example with comments to the LSR as a quick temporary measure. All agreed Urs Cheers, -Paul On Apr 26, 2015, at 12:08 PM, Urs Liska u...@openlilylib.org wrote: Hi Paul, I don't know if that's in any way related to our talk yesterday or if it has exclusively been triggered by Carl starting it. But this is very much a skeleton of what I was talking about! It would be absolutely great if you could pour that into a tutorial on the basics of writing Scheme engravers. Maybe users will usually not need this kind of information, but OTOH users often need solutions that can be provided using this technique. So having a slow-paced introductions may well lead to a greater number of people daring to dive into these waters. Best Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Color tweaks (edition engraver)
On Mon, Apr 27, 2015 at 12:16 PM, David Nalesnik david.nales...@gmail.com
wrote:
On Mon, Apr 27, 2015 at 12:12 PM, David Nalesnik david.nales...@gmail.com
wrote:
Here's a code snippet to show that it is possible to tell if a grob has
been altered. Right now you have to add the procedure for each grob you
want to examine.
The following covers all changed grobs. Thanks, Urs, for your posting at
http://lilypondblog.org/2014/04/music-functions-4-recursion/ -- I adapted
one of your functions there to apply the override to all objects with a
stencil property. (Rather than using a long string of laboriously typed
overrides.)
--DN
\version 2.19.17
#(define (grobs-with-stencils)
(let loop ((all all-grob-descriptions) (result '()))
(if (null? all)
result
(if (assoc-get 'stencil (cdar all))
(loop (cdr all) (cons (caar all) result))
(loop (cdr all) result)
#(define (mark-tweak grob)
(let* ((default (assoc-get (grob::name grob) all-grob-descriptions))
(default-after-line (assoc-get 'after-line-breaking default))
(props (ly:grob-basic-properties grob))
;; Our procedure has been added to the head of grob's basic
;; properties. Let's not count it as a tweak!
(props
(remove
(lambda (p)
(and (procedure? (cdr p))
(eq? (procedure-name (cdr p)) 'mark-tweak)))
props))
(diff (lset-difference eq? props default)))
;; Tweaks will not appear in the basic properties alist of our grob,
but
;; we can find them through the music event which led to the grob.
This
;; is available through the stream-event which caused our grob.
(if (null? diff)
(let* ((cause (event-cause grob))
(tweaks (and cause
(ly:music-property
(ly:event-property cause 'music-cause)
'tweaks
(if (pair? tweaks)
(set! (ly:grob-property grob 'color) red)))
(set! (ly:grob-property grob 'color) green))
;; Return any default setting of after-line-breaking.
(or default-after-line '(
markAllAlteredGrobs =
#(define-music-function (parser location) ()
(let loop ((grobs (grobs-with-stencils)))
(if (null? grobs)
#{ #}
#{
\override #(list 'Score (car grobs) 'after-line-breaking) =
#mark-tweak
#(loop (cdr grobs))
#})))
{
\markAllAlteredGrobs
c'
\once \override NoteHead.font-size = 3
c'
c'
\tweak font-size 3 c'
c'
%\override Slur.after-line-breaking = #mark-tweak
c'( e')
\shape #'((0 . 0) (0 . -0.5) (0 . -0.5) (0 . 0)) Slur
c'( e')
c'( e')
c'-\tweak Slur.positions #'(-5 . -5) ( e')
\override Hairpin.color = #blue
c'\ e'\!
c' e'\arpeggio
\once \override Staff.Arpeggio.positions = #'(-6 . 6)
c' e'\arpeggio
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
Am 27.04.2015 um 08:16 schrieb Michael Hendry: See https://github.com/wbsoft/frescobaldi/issues/573 In that wish I asked if it is useful or just a personal use case. So anybody who wants to use indented lines for such cases might add a comment there (to upvote it). I have added the following comment on GitHub: I agree that the loss of user-intended indentation is a problem with Frescobaldi's format feature, but I don't think this is a complete solution. As I understand it, the idea is that the %/ combination signifies that the _following_ line is to be given one extra ration of indentation, so code entered thus... a b c d b c d e %/ c d e f d e f g ...becomes... a b c d b c d e %/ c d e f d e f g ...with the fourth line dropping back to Frescobaldi's default indentation. This means that every line that is to be indented will have to be preceded by %/, and that there is no way of forcing double indentation. How would you propose switching off the %// indentation if it isn't automatically switched off in following bars? Thanks for the comments. I think they are partially valid and partially not, but that would become obvious when someone (maybe me) starts working on it. Anyway it's good they're documented. Urs Michael ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
On 27 Apr 2015, at 00:18, Urs Liska u...@openlilylib.org wrote: Am 27.04.2015 um 01:12 schrieb Simon Albrecht: Am 26.04.2015 um 23:53 schrieb Michael Hendry: On 26 Apr 2015, at 15:36, H. S. Teoh hst...@quickfur.ath.cx mailto:hst...@quickfur.ath.cx wrote: On Sun, Apr 26, 2015 at 10:23:26AM -0400, Kieren MacMillan wrote: Hi, Am I the only one who puts bar checks at *both* the beginning and end of a bar? | a4 b c d | | e f g a | You’re the only one I’ve ever heard of doing so. =) Exactly ½ of your bar checks are redundant, of course. [...] I realize it's redundant, but I use it as a visual aid. :-) I like formatting my input in paragraphs of 4 or 8 bars each, and having a visual marker for both the start and end of a bar lets me easily tell where a bar starts / ends when its contents don't fit on a single line (or is more readable wrapped to multiple lines): | a4 a a a | | a4 a a a | | a4 -\tag #'no-partcombine -\f -\tag #'midi -\ff a a a | | a4 a a a | | b4 b b b | | b4 b b b | | b4 b b b | | b4 b b b | ... etc. In the 3rd bar above the trailing | lets me immediately see that the end of the bar is on the 3rd line, and that the previous two lines are incomplete, whereas if I only wrote | on one end of the bar, it would take more effort to scan with my eye to find the bar boundaries. I’m not convinced that you gain any benefit from using the bar check at the beginning of the bar, if your’e going to put one at the end. Have a look at this... a4 a a a | a4 a a a | a4 -\tag #'no-partcombine -\f -\tag #'midi -\ff a a a | a4 a a a | b4 b b b | b4 b b b | b4 b b b | b4 b b b | …where the beginnings of the bars line up vertically, and any bars which spill over on to the next line are indented. Does it lose anything from not having leading bar checks? Yes: you can indent them manually, but if you use Frescobaldi’s auto-indenting tool (which is very recommendable) this info will get lost. Yours, Simon See https://github.com/wbsoft/frescobaldi/issues/573 https://github.com/wbsoft/frescobaldi/issues/573 In that wish I asked if it is useful or just a personal use case. So anybody who wants to use indented lines for such cases might add a comment there (to upvote it). I have added the following comment on GitHub: I agree that the loss of user-intended indentation is a problem with Frescobaldi's format feature, but I don't think this is a complete solution. As I understand it, the idea is that the %/ combination signifies that the _following_ line is to be given one extra ration of indentation, so code entered thus... a b c d b c d e %/ c d e f d e f g ...becomes... a b c d b c d e %/ c d e f d e f g ...with the fourth line dropping back to Frescobaldi's default indentation. This means that every line that is to be indented will have to be preceded by %/, and that there is no way of forcing double indentation. How would you propose switching off the %// indentation if it isn't automatically switched off in following bars? Michael Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Trouble with alternative melody and lyrics
Dear List,
I have a song with two verses. The lyrics to the second stanza
occasionally have an extra syllable, such that there is a rest on that beat
in the first verse but a note in the second verse. I'm trying to address
this using the code found in notation manual (v. 2.18.2) in Section 2.1.3
Stanzas, subsection Switching to an alternative melody. See
http://www.lilypond.org/doc/v2.18/Documentation/notation/stanzas#stanzas-with-different-rhythms.
But I cannot get the lyrics to recognize and line up with the added beat in
the second stanza. An example, as minimal as I was able to get it, follows
below. Can anyone help? Also, is there a simpler approach that works for
this, so I don't have to define a new alternative voice every time this
situation occurs?
Thanks,
Pete
\version 2.18.2
melody_verse = \relative c' {
c4
\new Voice = alternative {
\voiceTwo
f4
}
{ \voiceOne
d'4\rest
\oneVoice
}
g,4 a |
}
\score {
\new Staff {
\new Voice = main {
\repeat volta 2 { \melody_verse }
}
}
\new Lyrics \lyricsto main {
{ One three four. }
\new Lyrics {
\set associatedVoice = alternative
Uno
\set associatedVoice = main
dos tres quatro.
}
}
}
% End of example.
___
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?)
Am 27.04.2015 um 10:35 schrieb ArnoldTheresius: Hello Urs Urs Liska wrote ... Another important topic for commercial users may be the management of the source code for all PDFs (and other output). What do you mean here? And finally multiple people may have to working parallel on the same score. This is something that is already working absolutely great with LilyPond scores. Urs ... I just think on my 'huge score'. 24 pieces (movements) originally published with 'Piano Direction' istead of a score, I put the 17 parts (including the 'piano direction' and 'piano solo' together to a score. Per instrument each piece a single soucre file, one compilable LY per each combination (piece and instrument, as well as 'score of a single piece') for the 'editing workflow', and one compilable LY per each instrument part, transposed alternative instrument part and score (all 24 pieces) for the 'publishing workflow', some common includes (e.g. Title of the pieces) did result in more than 900 LY files. I can imagine, if ten persons are working parallel to make such an edition avalible in a short time, it's not a good idea to just save the file on a comon shared folder, with the danger to overwrite a file a colleague had modified and saved just a short time before. This is true. So I would *never* suggest working on a substantial project on a shared drive. But your situation is already *fr* betten than if you'd have binary/graphical documents. If you are going to collaborate you should definitely use a version control system such as Git (or any other). And then you can benefit to 100% from the text based file format, and this is where my comment about working absolutely great is targeting at. Maybe you didn't see http://lilypondblog.org/category/productions/das-trunkne-lied/ and particularly http://lilypondblog.org/2014/10/segmented-workflows/, where I describe exactly such a project. I have just asked my terminal to count the .ly/.ily files in the project directory, and the answer was 2917. We have used the collaborative approach with huge success so far. Well, I admit, in CAD usage the reuse of existing objects is much more complex. Urs Liska wrote Compared to the CAD software, Lilypond is missing (around it's kernel): - a graphical user interface (GUI) to enter/edit the source (with a simplified graphical representation of the music notes) I'm not clear what you mean here, but in any case this too is an issue for the IDE. Frescobaldi provides the Quick Insert panel. You can select multiple notes in the input file or the music view and then apply e.g. staccato to all notes at once. On my way-too-long wish/todo list is an object inspector/editor for Frescobaldi, which should basically be rather straightforward to implement. This panel would be aware of the grob the cursor is currently in (or the grob that has been selected in the Music View) and then show all available properties that can be tweaked for that element (actually Frescobaldi already knows about these properties which it uses for autocompletion). Then there should be convenient ways to edit values in that dialog. - automatic source code update to new versions (from open file to file loaded into the RAM of the editor) Is this really important? I'd be scared when my editor does that automatically. - point-and-click positions have idenpendent IDs, which are stable during editing the source (e.g. if you edit the LY files and insert a line) Frescobaldi does that. ... My observation on CAD usage is, approx. 3 % of the users are going to use features which are similar to programmng. The remaining 97 % use the GUI only and avoid using such features, they have to think as a programmer. I hope, for music notation users this ratio is better, but I don't believe it'll reach 20 %. So, a good GUI editor for LY files could increase the acceptance of the users a lot. And it's an important question for such a GUI, how versions updates will be handled - but this also depends on your file managment (will you save the history in the editing process?) What's to expect if you restart editing a 20 years old publication? Can only the guru process all required updated, or is the work of the guru limited to fix the remaining problems (by using an utf8 text file editor) only? Well, I have the impression you should have a look at http://lilypondblog.org/tag/version-control/ ;-) IMHO, the publishing companies would prefer a complete suite of lilypond (the kernel), an editing GUI (for user acceptance) and file management (recommended at least for cooperation of multiple users) Actually that's what I have in mind: LilyPond, Frescobaldi, Git (with either GitHub or a self-installed GitLab). As it's a suite it requires to set up a few things in line, which could still be simplified by either creating a setup program that installs the necessary things and guides the user through the setup of personal things like accounts. But OTOH I'm not
Re: Putting text IN the staff
On 27/04/2015 08:14, Anthonys Lists wrote:
Simple problem, I can't find the solution ... :-)
Basically, what I want is \StaffOff ...text... \StaffOn.
Something like this? The values for offset and makegap have to be
fiddled with to get proper alignment for the text you use.
\version 2.19.18
makeGap = { \repeat unfold 2 { \hideNotes c1 \unHideNotes \noBreak } }
{
c''1
\noBreak \stopStaff \cadenzaOn
-\tweak extra-offset #'(1 . 3)_\markup\small { Text here }
\makeGap
\cadenzaOff \startStaff
c''1
}
___
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?)
2015-04-25 19:17 GMT+02:00 Martin Tarenskeen m.tarensk...@zonnet.nl:
It should be mentioned that Frescobaldi creates converts
{c'' d'' e'' f'' g''}
to old style \relative syntax like:
\relative c'' {c d e f g}
instead of the new syntax I like to use these days:
\relative {c'' d e f g}
I've added a request here:
https://github.com/wbsoft/frescobaldi/issues/682
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Height of start bar brace
Thanks, Nathan, that works. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Concepts that may be missing (or are at least hidden) in LilyPond
Am 27.04.2015 um 15:00 schrieb Carl Sorensen: On 4/26/15 10:55 PM, Andrew Bernard andrew.bern...@gmail.com wrote: In what way are measures missing? Half the world calls them Œbars¹ by the way - that¹s what they are under in the index. Are you simply referring to terminology in the documentation? LilyPond creates bars (the things that divide measures) just fine. LilyPond has a Timing engraver that keeps track of the current time within a measure (so you get warnings if you place a bar check that doesn't coincide with the end of a measure). But if you look, for example, at the Music Encoding Initiative (MEI), they have a container called the measure, which contains musical elements over a certain period of time[1]. So notes are placed into measures. Presumably this then allows a text parser to search through the data schema, find measures, and eliminate them. LilyPond has no data structure for a measure. The only timing relationships in the LilyPond model are sequential (one note follows a previous note) and simultaneous (two notes start at the same time). The full timing of the score is worked out by Iterators when the score is produced. There are some advantages to the LilyPond way of doing it. LilyPond easily supports different time signatures in different staffs. Music is easily copied, because it has no absolute timing information. There are also disadvantages to the LilyPond way. It is common for people to think things like the crescendo should cover measures 2-4. There is no way to express this kind of relationship in LilyPond. I'm not convinced that LilyPond should add a measure object to its language. I would strongly oppose to *replacing* the current approach with a container based approach (I don't think you are even considering that, I just want to make that clear). Apart from the polymetrics stuff the container imposes significant limitations with regard to items crossing the measure boundaries. Or (in the case of Finale and Sibelius at least) with incomplete measures. AFAICS from blog post etc. it is really painful to talk one of these programs into writing tuplets over bars (maybe even beams over barlines?), and when you try to edit existing music and delete something from a measure you can't really leave that measure without the program complaining (or doing stupid things). For a concept of measures 2-4 we already have a powerful technology right before us: the edition-engraver. It is not fully mature and ready to be included in LilyPond itself. But apart from providing means to completely separate content from separation it is also good at injecting stuff measure-wise. For example right now it is possible to write: \editionModList full-score Score \break #'(7 16 22 (27 2/4) 30) to apply line breaks (or whatever) at this list of measures (including partial measures) What would be good to have is a notion of select everything in measures 2-4 - over all possible parts as this is something that is currently more or less impossible. Urs But I am convinced that LilyPond really doesn't have the concept of a measure object in its schema right now. Thanks, Carl 1. http://music-encoding.org/documentation/guidelines2013/cmn#cmnMeasures ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Concepts that may be missing (or are at least hidden) in LilyPond
On 4/26/15 10:55 PM, Andrew Bernard andrew.bern...@gmail.com wrote: In what way are measures missing? Half the world calls them Œbars¹ by the way - that¹s what they are under in the index. Are you simply referring to terminology in the documentation? LilyPond creates bars (the things that divide measures) just fine. LilyPond has a Timing engraver that keeps track of the current time within a measure (so you get warnings if you place a bar check that doesn't coincide with the end of a measure). But if you look, for example, at the Music Encoding Initiative (MEI), they have a container called the measure, which contains musical elements over a certain period of time[1]. So notes are placed into measures. Presumably this then allows a text parser to search through the data schema, find measures, and eliminate them. LilyPond has no data structure for a measure. The only timing relationships in the LilyPond model are sequential (one note follows a previous note) and simultaneous (two notes start at the same time). The full timing of the score is worked out by Iterators when the score is produced. There are some advantages to the LilyPond way of doing it. LilyPond easily supports different time signatures in different staffs. Music is easily copied, because it has no absolute timing information. There are also disadvantages to the LilyPond way. It is common for people to think things like the crescendo should cover measures 2-4. There is no way to express this kind of relationship in LilyPond. I'm not convinced that LilyPond should add a measure object to its language. But I am convinced that LilyPond really doesn't have the concept of a measure object in its schema right now. Thanks, Carl 1. http://music-encoding.org/documentation/guidelines2013/cmn#cmnMeasures ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: mutopia's shortcomings
I may have missed it if someone said it in the previous messages (apologies if so), but one of the benefits of mutopia over imslp is that the scores are for paper sizes that anyone can print. Most hand engraved scores are considerably bigger than A4 (and for good reason). A student who prints a Beethoven sonata from imslp will have to reduce Klavierformat to A4 which would result in something difficult to read. Mutopia provides a useful alternative. By the way I'm interested in people's opinions about B4 vs A4. For piano music which is preferable? On Fri, Apr 24, 2015 at 10:27 PM, Gilles gil...@harfang.homelinux.org wrote: 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 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Concepts that may be missing (or are at least hidden) in LilyPond
Hi Andrew, In what way are measures missing? Here’s one example: you can add/modify/delete a Staff [context] with a single command; you cannot add/modify/delete a Measure. 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
Higher-level score handling needed? (was: Do we really offer the future?)
Hello folks, Some remarks for what they're worth... JM -- LP is basically staff oriented, and we specify a linear sequence of notes and the like for each staff. The reactions on the « Do we really offer the future? » thread as well as many questions that arose recently on this list show a need for a higher-level way of dealing with scores, that could allow in particular for: - better repeat/alternative handling; - handling bars globally in a cross-staff way; - vertical staff and system spacing issues; - better handling of end of lines, in particular regarding bar/repeat signs and marks. This would mean building a representation of the « architecture » of the score as internal data by the tool. It’s my understanding that that’s what Denemo is doing. Or maybe the user should start from the global architecture of the score (number of systems, staves and bars, where the repeats/alternatives occur and for how many times, where vertical spacing should be augmented, …) and then « populate » the resulting « canevas ». This is analogous to the relational database world, in which you first specify the structure and then supply the contents. I don’t think a much faster version of LP, thru parallelism say, will exist soon. The approach I’m thinking of could help have a number of instances of LP produce the view for individual staves in parallel while the user is interactively populating them. Wether LP can evolve toward this need or some other tool using it behind the scenes is a better approach would have to be seen, of course. HTH! ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
teaching a university module on engraving with lilypond
Dear All, Three recent threads (are we the future, mutopia, and new users' feelings about the docs) have prompted me to start a new one rather than write separate replies to each. Apologies in advance for the length, but I would be very grateful for some replies. I am very happy to say that a module I offered at the university where I teach, on preparing scores with lilypond, has been taken up by the students (whether the course runs or not is their choice so I consider it a democratic victory!), and will run for twelve weeks this forthcoming October-December. I will have about ten sophister B.A. students (music students at the end of their degrees). The scope of the course will be to teach some of the finer points of engraving (Gould is the module reference text) and then get them to produce their own editions of out-of-copyright scores which we will then try to upload to mutopia (and perhaps imslp, but I haven't looked into that). So a few things: 1. I'm viewing this as an opportunity to `turn' a few of our students (who mostly seem to use pirated copies of Sibelius). I haven't researched the module yet but I hope that I will have some exemplary scores to show off LilyPond when the time comes around. The only commercially available one that I am aware of is Urs and Janek's Fried songbook. (By the way, I read in another thread that they sold framed A3 pages from it - are they still doing that? I would love one) If anyone can point me in the direction of more LilyPond-engraved material that would be great. 2. There seems to be a consensus among a small group here that LilyPond's default output isn't really publishing standard. I've never engraved a full score with it (I do examples and diagrams for my own work or the work of other academics), so I've never really bumped up against this issue. Can anyone list the things that they routinely improve? I know Kieran and some others proposed creating some stylesheets to help in this area (and somewhere I have a very nice engraving of the first page of Beethoven's Op. 10 sonatas) - was there any progress with that? 3. Since I will, in effect, be creating a tutorial for new LilyPond users, perhaps I could encourage some collaboration here, and make the results freely available. MuseScore has an excellent series of tutorial videos, for example. I'm not necessarily saying that format would be best for LilyPond, but I do think there is room in the ecosystem for a tutorial in addition to the (excellent) learning manual, which I paid a considerable price in terms of time for not reading more thoroughly the first time around... Thanks for reading, Kevin ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: mutopia's shortcomings
Hi Joram, 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. An excellent question/point. 1. How stable is the interface of the edition engraver? Right now, not sufficiently for Mutopia’s needs, I would offer. However, I know that Jan-Peter is actively working on it, so things should settle down relatively soon. Will the commands to use it change? See below. 2. Will it always be in the current place of OpenLilyLib? See below. 3. Might it get integrated into the core of LilyPond? This is the key question. Of course, I think it’s abolute must. Personally, I would assign it as high a priority as MusicXML import/export and other features with higher visibility/“wow factor”, given how mature its code is relative to those other items. If/when it is integrated into the core distribution, the functionality would likely increase and the syntax settle down more quickly, and be far more stable. However, I have no idea about the timeline or even interest for such a thing — that would be a question for Lily’s main code gatekeeper(s). 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. Agreed. 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
Re: mutopia's shortcomings
Hi all, For me one of the biggest advantage of Mutopia (as a singer) is the possibility of transposing songs in every tones! Some years ago I submitted a few *mélodies* on Mutopia. My coding policy was tweaking the least, that for two reasons : 1) I thought the file is more maintainable with only raw code + is easily readable and modifiable. 2) I thought Lilypond will improve so that it will ask for less tweaks. I agree : – that Mutopia files aren’t (all) beautiful (and I contributed that way) – that layout and content should be separate (I try to do it most of the time) – that it is too soon to use edition-engraver for Mutopia files Regards, Calixte. 2015-04-27 16:38 GMT+02:00 Urs Liska u...@openlilylib.org: Am 27.04.2015 um 16:15 schrieb Noeck: Dear Kieren, With the edition-engraver, there is (a) no need to mix layout with contents 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? not production-ready. Will the commands to use it change? Probably yes. 2. Will it always be in the current place of OpenLilyLib? Definitely not. As 90% of openLilyLib that will be migrated to the new, real infrastructure, once this is ready enough. Currently OLL is more or less a bunch of more or less useful code snippets. Through the reorganization it will become a set of well-defined libraries that can be used like libraries and that are documented like software libraries. The last part is what hasn't been implemented yet, and i do *not* want significant portions of code to be migrated before we can guarantee that. 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) We have the intention to do so. For now it is good to have it in openLilyLib, a place that is much more public than Jan-Peter's own repository, so we can test, discuss and develop it until it (hopefully) becomes mature and robust enough to be integrated in LilyPond itself. HTH Urs 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. To be clear, I like the edition engraver very much. Cheers, Joram ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Concepts that may be missing (or are at least hidden) in LilyPond
Am 27.04.2015 um 15:37 schrieb Kieren MacMillan: Hi Urs, I would strongly oppose to *replacing* the current approach with a container based approach (I don't think you are even considering that, I just want to make that clear). +1 What would be good to have is a notion of select everything in measures 2-4 - over all possible parts as this is something that is currently more or less impossible. Better perhaps would be “select everything from moment X to moment Y (which may or may not correspond to a barline in one or more voices)”. Your example would be a proper subset of that functionality. Ah, you're right. That makes me think of one implication of the question: About what level are we talking about right now? Are we talking about modifying the input files or about modifying the produced scores? This makes a significant difference. When we're talking about modifying the input files (which is what we usually want when we say: copy/remove from moment X to Y) This is something LilyPond wouldn't be responsible for, it's definitely something for the editors. But maybe LilyPond could be of help here. Maybe LilyPond could run through only the first stage (i.e. without producing graphical or MIDI output) and analyze the score. On that way it parses all existing contexts and could maybe determine the positions of all music content. It could then output some kind of list representation that allows an editor like Frescobaldi to determine the locations of all objects inside the requested area in order to take action. Maybe this could also take care of noticing open spanners that are closed inside the range, so that an editor can also offer solutions or ask the user what to do with these. Of course this is a highly simplified sketch, and there's much that has to be considered. But it *could* be an approach. Urs 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
Re: Concepts that may be missing (or are at least hidden) in LilyPond
Hi there, after just reading all these important threads partially, I want to jump in. I want to encourage Urs' position - and if I understand correctly, Carl does not object ;) The lilypond way of working made it easy for me, to spot errors in a score I received as musicXML. There where several partial bars, which where actually not right. And Lilypond gave the right warnings. When I am back into lily-business, I want to extend the edition-engraver to do act on the content. Say, I want to add a crescendo in Context X from measure 27 3. 4th to measure 29 2. 4th or the like. Other topics are beaming, slurs, ties and so on (it should be doable ;) ). But there is still one aspect missing: If I want to delete measure X from all parts of a score, I am adviced to organize my code carefully before that. So IMO this might be a topic rather for documentation than for an additional feature. Cheers, Jan-Peter Am 27.04.2015 um 15:23 schrieb Urs Liska: There are some advantages to the LilyPond way of doing it. LilyPond easily supports different time signatures in different staffs. Music is easily copied, because it has no absolute timing information. There are also disadvantages to the LilyPond way. It is common for people to think things like the crescendo should cover measures 2-4. There is no way to express this kind of relationship in LilyPond. I'm not convinced that LilyPond should add a measure object to its language. I would strongly oppose to *replacing* the current approach with a container based approach (I don't think you are even considering that, I just want to make that clear). Apart from the polymetrics stuff the container imposes significant limitations with regard to items crossing the measure boundaries. Or (in the case of Finale and Sibelius at least) with incomplete measures. AFAICS from blog post etc. it is really painful to talk one of these programs into writing tuplets over bars (maybe even beams over barlines?), and when you try to edit existing music and delete something from a measure you can't really leave that measure without the program complaining (or doing stupid things). For a concept of measures 2-4 we already have a powerful technology right before us: the edition-engraver. It is not fully mature and ready to be included in LilyPond itself. But apart from providing means to completely separate content from separation it is also good at injecting stuff measure-wise. For example right now it is possible to write: \editionModList full-score Score \break #'(7 16 22 (27 2/4) 30) to apply line breaks (or whatever) at this list of measures (including partial measures) What would be good to have is a notion of select everything in measures 2-4 - over all possible parts as this is something that is currently more or less impossible. Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Color tweaks (edition engraver)
Dear all, dear Urs, I would like to color tweaks of a particular edition of the edition engraver. I know that there is a checkbox in Frescobaldi to color, so it seems possible to color tweaked grobs in general. What I would like is to specify a color (of my choice) for each of the editions I define in the edition engraver. Do you see an easy way or should I rather add a color override for each modification by hand? Cheers, Joram ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: mutopia's shortcomings
Dear Kieren, With the edition-engraver, there is (a) no need to mix layout with contents 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? 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. To be clear, I like the edition engraver very much. Cheers, Joram ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: mutopia's shortcomings
Am 27.04.2015 um 16:15 schrieb Noeck: Dear Kieren, With the edition-engraver, there is (a) no need to mix layout with contents 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? not production-ready. Will the commands to use it change? Probably yes. 2. Will it always be in the current place of OpenLilyLib? Definitely not. As 90% of openLilyLib that will be migrated to the new, real infrastructure, once this is ready enough. Currently OLL is more or less a bunch of more or less useful code snippets. Through the reorganization it will become a set of well-defined libraries that can be used like libraries and that are documented like software libraries. The last part is what hasn't been implemented yet, and i do *not* want significant portions of code to be migrated before we can guarantee that. 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) We have the intention to do so. For now it is good to have it in openLilyLib, a place that is much more public than Jan-Peter's own repository, so we can test, discuss and develop it until it (hopefully) becomes mature and robust enough to be integrated in LilyPond itself. HTH Urs 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. To be clear, I like the edition engraver very much. Cheers, Joram ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Color tweaks (edition engraver)
Am 27.04.2015 um 16:27 schrieb Noeck: Dear all, dear Urs, I would like to color tweaks of a particular edition of the edition engraver. I know that there is a checkbox in Frescobaldi to color, so it seems possible to color tweaked grobs in general. No, I don't think this is possible, although I would really like to have that feature (to immediately make visible what is original and what is manual). What we have in Frescobaldi depends on what we can catch by either listening through engravers or by redefining command. So far I haven't found a notion of a grob knowing if it has been tweaked or not. What I would like is to specify a color (of my choice) for each of the editions I define in the edition engraver. Do you see an easy way or should I rather add a color override for each modification by hand? I don't think that's possible, but I think it would be a useful enhancement to the edition-engraver. So you might add a wish on openLIiylIb's tracker.? Urs Cheers, Joram ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Trouble with alternative melody and lyrics
Peter wrote Monday, April 27, 2015 8:25 AM
I have a song with two verses. The lyrics to the second stanza occasionally
have an extra syllable, such that there is a rest on that beat in the first
verse but a note in the second verse. I'm trying to address this using the
code found in notation manual (v. 2.18.2) in Section 2.1.3 Stanzas,
subsection Switching to an alternative melody. See
http://www.lilypond.org/doc/v2.18/Documentation/notation/stanzas#stanzas-with-different-rhythms.
But I cannot get the lyrics to recognize and line up with the added beat in
the second stanza. An example, as minimal as I was able to get it, follows
below. Can anyone help? Also, is there a simpler approach that works for
this, so I don't have to define a new alternative voice every time this
situation occurs?
I'd use a simpler approach, like this (it's usually easiest to keep as many
notes as possible in the music associated with the lyrics, using skip or to
skip them as necessary):
\version 2.18.2
melody_verse = \relative c' {
c4
{ \once \voiceTwo f }
\new Voice { d'4\rest }
g,4 a |
}
\score {
\new Staff {
\new Voice = main {
\repeat volta 2 { \melody_verse }
}
}
\new Lyrics \lyricsto main {
One three four.
}
\new Lyrics \lyricsto main {
Uno dos tres quatro.
}
}
Trevor
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: teaching a university module on engraving with lilypond
On 4/27/15 7:18 AM, Kevin Barry barr...@gmail.com wrote: 3. Since I will, in effect, be creating a tutorial for new LilyPond users, perhaps I could encourage some collaboration here, and make the results freely available. MuseScore has an excellent series of tutorial videos, for example. I'm not necessarily saying that format would be best for LilyPond, but I do think there is room in the ecosystem for a tutorial in addition to the (excellent) learning manual, which I paid a considerable price in terms of time for not reading more thoroughly the first time around... Given the fact that you paid a price for not reading the Learning Manual more thoroughly, would it not make sense to use the Learning Manual as your text for the module? If there are problems with the Learning Manual, let's fix them. If there are optional tutorials that you want to have as part of your module that can be worked on independently after working through the core part of the Learning Manual, I think we could add them. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Concepts that may be missing (or are at least hidden) in LilyPond
Hi Urs, I would strongly oppose to *replacing* the current approach with a container based approach (I don't think you are even considering that, I just want to make that clear). +1 What would be good to have is a notion of select everything in measures 2-4 - over all possible parts as this is something that is currently more or less impossible. Better perhaps would be “select everything from moment X to moment Y (which may or may not correspond to a barline in one or more voices)”. Your example would be a proper subset of that functionality. 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
Re: mutopia's shortcomings
Hi Gilles, 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”). With the edition-engraver, there is (a) no need to mix layout with contents, and (b) the opportunity to store an arbitrary number of edition descriptions which can be compiled from the [one] content source. 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
Re: Limits of algorithmic typesetting (was: Re: mutopia's shortcomings)
Hi Calixte, I think the question is more: “will machines be able to engrave scores that don’t need tweaks or human correction at all.” Yes. Maybe, but in my opinion — except if you implement something like an AI — it will never have the difference that makes traditional engraving so lovely (everything is not perfectly aligned and straight, whatever). Never say “never”. ;) But I would happily wager that it won’t happen in my lifetime (pace Kurzweil). 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
Re: Concepts that may be missing (or are at least hidden) in LilyPond
On 4/27/15 6:37 AM, Kieren MacMillan kieren_macmil...@sympatico.ca wrote: Hi Urs, I would strongly oppose to *replacing* the current approach with a container based approach (I don't think you are even considering that, I just want to make that clear). +1 Just to clarify my intent -- I'm not proposing *anything* about changing LilyPond right now. I'm trying to find out what things may be missing from LilyPond, so we can have a discussion about what to do about them. For the record, I believe that LilyPond's music architecture is superior to both MusicXML and MEI. I really think that the LilyPond music tree (which results from parsing an input file), if all the contexts have been explicitly defined, is the best logical representation of music that I have seen. And I agree with the thoughts expressed elsewhere that selecting and deleting measures is an *editor* function, not a *lilypond* function. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: teaching a university module on engraving with lilypond
Hi Kevin, Am 27.04.2015 um 16:18 schrieb Kevin Barry: Dear All, Three recent threads (are we the future, mutopia, and new users' feelings about the docs) have prompted me to start a new one rather than write separate replies to each. Apologies in advance for the length, but I would be very grateful for some replies. I am very happy to say that a module I offered at the university where I teach, on preparing scores with lilypond, has been taken up by the students (whether the course runs or not is their choice so I consider it a democratic victory!), and will run for twelve weeks this forthcoming October-December. I will have about ten sophister B.A. students (music students at the end of their degrees). Congratulations! The scope of the course will be to teach some of the finer points of engraving (Gould is the module reference text) and then get them to produce their own editions of out-of-copyright scores which we will then try to upload to mutopia (and perhaps imslp, but I haven't looked into that). So a few things: 1. I'm viewing this as an opportunity to `turn' a few of our students (who mostly seem to use pirated copies of Sibelius). I haven't researched the module yet but I hope that I will have some exemplary scores to show off LilyPond when the time comes around. The only commercially available one that I am aware of is Urs and Janek's Fried songbook. (By the way, I read in another thread that they sold framed A3 pages from it - are they still doing that? I would love one) If anyone can point me in the direction of more LilyPond-engraved material that would be great. What I know from the community is https://edition-kainhofer.com/de/ and http://www.xn--schne-noten-tfb.de/ The framed A3 pages were an item in our (failed) crowdfunding initiative to make the edition free. As nobody took that one we didn't actually produce one, so nothing is in stock. However, one could always think about that. 2. There seems to be a consensus among a small group here that LilyPond's default output isn't really publishing standard. Definitely not. But I don't think *any* notation program does that. IMO LilyPond's default output is much closer to publishing standard than Finale's or Sibelius' (I don't know about Amadeus or SCORE). But there are two different things to this topic: The overall layout and appearance and the detail engraving issues. The latter is the question of how many items you have to touch and fix to get the details to your publication standards, the former the issue of global settings. I've never engraved a full score with it (I do examples and diagrams for my own work or the work of other academics), so I've never really bumped up against this issue. Can anyone list the things that they routinely improve? I know Kieran and some others proposed creating some stylesheets to help in this area (and somewhere I have a very nice engraving of the first page of Beethoven's Op. 10 sonatas) - was there any progress with that? Partially. There is at least the place ready for it in openLilyLib, and some thought has been given about a possible interface and code design - but not too much. This is blocked by my work on font selection. I've written about my progress on a font selection interface in this post: http://lilypondblog.org/2015/03/managing-alternative-fonts-with-lilypond/ But while continuing my work on that track I realized that some if not most of the work should go into LilyPond itself. So currently I'm preparing a patch that will significantly simplify and enhance the possibilities to switch text and music fonts in LilyPond. Only when that's ready and through I will continue with the stylesheets library (not only because of the time but of course because that relies on the font interface). I think when the time is ready I'll ask for some discussion here. 3. Since I will, in effect, be creating a tutorial for new LilyPond users, perhaps I could encourage some collaboration here, and make the results freely available. MuseScore has an excellent series of tutorial videos, for example. You know http://benlemon.me/blog/music/lilypond/operation-lilypond ? I'm not necessarily saying that format would be best for LilyPond, but I do think there is room in the ecosystem for a tutorial in addition to the (excellent) learning manual, which I paid a considerable price in terms of time for not reading more thoroughly the first time around... Definitely. If someone takes responsibility for this it would be great. Urs Thanks for reading, Kevin ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Color tweaks (edition engraver)
Hi David, thank you very much! This is great. It is by far enough for my purposes. For an automatic option like in Frescobaldi it has some issues still – as you describe. There is something which has to be fixed, though. All clefs get colored, Can this be avoided (even at the cost of not coloring them even if tweaked)? The best way to check, of course, is to run it with a large, heavily tweaked score. That's my purpose, so I will give you feedback soon. The first impression is that it colors too much (hairpins, dynamics and ranges of note heads). The reason for this is that 'after-line-breaking is often used for advanced tweaks Out of curiosity, could you explain to me what after-line-breaking is doing and why it is used so often for advanced tweaks? Thanks again, Joram ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Color tweaks (edition engraver)
Hi Urs, On Mon, Apr 27, 2015 at 4:57 PM, Urs Liska u...@openlilylib.org wrote: Hey David, this is terrific. Nice that something I've done comes back to me this way ... When I'll have the time I'll look into integrating this into Frescobaldi's Layout Control Options. Thanks! There is something which has to be fixed, though. All clefs get colored, apparently because the (glyph . name) pair isn't present in the basic-properties alist. This would have to be discounted. I wonder if there are any other situations like this. The best way to check, of course, is to run it with a large, heavily tweaked score. Oh, yes, and one more thing. A more refined way to discount the after-line-breaking override our function creates is needed (see code comments). The reason for this is that 'after-line-breaking is often used for advanced tweaks, and we don't want to lose these; furthermore. these should get colored, too. I'll keep you posted if I come up with solutions. Best, David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Color tweaks (edition engraver)
Hi Joram, On Mon, Apr 27, 2015 at 5:30 PM, Noeck noeck.marb...@gmx.de wrote: Hi David, thank you very much! This is great. It is by far enough for my purposes. For an automatic option like in Frescobaldi it has some issues still – as you describe. There is something which has to be fixed, though. All clefs get colored, Can this be avoided (even at the cost of not coloring them even if tweaked)? Sure, but I wouldn't want to settle! The best way to check, of course, is to run it with a large, heavily tweaked score. That's my purpose, so I will give you feedback soon. The first impression is that it colors too much (hairpins, dynamics and ranges of note heads). Make sure those aren't instances of \override rather than \once \override ... The reason for this is that 'after-line-breaking is often used for advanced tweaks Out of curiosity, could you explain to me what after-line-breaking is doing and why it is used so often for advanced tweaks? It's described as a dummy property, so you can set it to various callbacks without worrying that you will overwrite something important. (There are a certain few grobs--Hairpin is an example--which have default settings for this property, however.. To deal with that, I make sure that the default value of 'after-line-breaking is returned after I have made my changes to 'color.) There are two such dummy properties distinguished by when they are called: before-line-breaking and after-line-breaking. The timing can be crucial. Let's say you want to change pieces of broken spanners. You need to look for the pieces within 'after-line-breaking, because the spanner will still be whole when 'before-line-breaking is evaluated. The issue with the current file is (1) calling the music function adds a pair for after-line-breaking at the head of the properties alist; (2) a user's advanced functions will add a pair for after-line-breaking as well (3) we want to get rid of (1) when deciding whether to color, but we need (2) to be evaluated This can be resolved, but I'm too tired to deal with it right now. Hope this helps! David P.S. I'm wondering if it would be cleaner to modify the music expression--that is, what is returned by \displayMusic, rather than the approach taken here. I'll have a look. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Tie engraver
Greetings All, The tie machinery for ties between chords puts them all one way, up or down, when using a simple tilde for tying. I have to adjust every pair of tied chords, of which I have several thousand in my score, to have some ties down and some up, according to the wishes of the composer. I understand the tie engraver can’t know what I want, but in the general case, is there any way you can specify that for say, two note chords, the top tie goes up and the bottom one goes down, and for three note chords, the top two go up and the bottom one down, for four note chords the top two go up and the bottom two go down, and so on, for higher degrees? I know you can use the tie-configuration property for individual chords, but that is not what this question is about. Any clues? I hope this is clear without a snippet to illustrate. Andrew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Automatically convert beams [ ] into slurs ( ) to indicate melisma (was undefined)
Calixte Faure wrote
Traditionally, vocal scores are written without beams, except for melisma.
But modern scores tend to keep beams everywhere and put slurs to indicate
melisma.
Is it possible to have both output with one source, without complicating
the typesetting?
I have this in mind :
vocal = \relative c'{
c4 d8 e f[ g] a4
}
and a magic command (say \beamToSlur) would switch [ ] to ( ).
I've added this \beamsToSlurs snippet to the LSR:
http://lsr.di.unimi.it/LSR/Item?u=1id=998
I don't think the music example illustrates the use case as well as it
could. If anyone has a better example, reply with it here and I can replace
the music in the snippet with it.
-Paul
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/undefined-tp174666p175527.html
Sent from the User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tie engraver
Hi Andrew,
On Mon, Apr 27, 2015 at 8:34 PM, Andrew Bernard andrew.bern...@gmail.com
wrote:
Greetings All,
The tie machinery for ties between chords puts them all one way, up or
down, when using a simple tilde for tying.
The following snippet has one upward tie and two downward ties.
{
c' e' g'~ c' e' g'
}
If you use \voiceOne, \voiceTwo, etc., the ties will be oriented in the
same direction, as convention would dictate:
{
\voiceOne c' e' g'~ c' e' g'
}
Is this what's happen with your score? You shouldn't have to adjust the
direction of ties in the majority of cases.
--David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tie engraver
Am 28.04.2015 um 03:41 schrieb David Nalesnik:
Hi Andrew,
On Mon, Apr 27, 2015 at 8:34 PM, Andrew Bernard
andrew.bern...@gmail.com mailto:andrew.bern...@gmail.com wrote:
Greetings All,
The tie machinery for ties between chords puts them all one way,
up or down, when using a simple tilde for tying.
The following snippet has one upward tie and two downward ties.
{
c' e' g'~ c' e' g'
}
If you use \voiceOne, \voiceTwo, etc., the ties will be oriented in
the same direction, as convention would dictate:
{
\voiceOne c' e' g'~ c' e' g'
}
Is this what's happen with your score? You shouldn't have to adjust
the direction of ties in the majority of cases.
But *if* you have to do it you can still write
{
c'^~ e'_~ g'^~ c' e' g'
}
to conveniently set the direction of the individual ties.
Urs
--David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Color tweaks (edition engraver)
Hi Urs, thanks. I hoped it was easier. But then I will just color them by hand. Cheers, Joram ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: teaching a university module on engraving with lilypond
On Mon, Apr 27, 2015 at 4:07 PM, Carl Sorensen c_soren...@byu.edu wrote: Given the fact that you paid a price for not reading the Learning Manual more thoroughly, would it not make sense to use the Learning Manual as your text for the module? If there are problems with the Learning Manual, let's fix them. If there are optional tutorials that you want to have as part of your module that can be worked on independently after working through the core part of the Learning Manual, I think we could add them. The learning manual will be a core part of the module of course, but I don't expect it to take much time to get through (I will have 22 hours of contact during the module). In general I would like to focus on practical work first, and explain the theory later. You know http://benlemon.me/blog/music/lilypond/operation-lilypond ? No I didn't know about this, and thank you for linking it. I will take a good look. Kevin ___ 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: Putting text IN the staff
On 27/04/15 09:30, Nick Payne wrote:
On 27/04/2015 08:14, Anthonys Lists wrote:
Simple problem, I can't find the solution ... :-)
Basically, what I want is \StaffOff ...text... \StaffOn.
Something like this? The values for offset and makegap have to be
fiddled with to get proper alignment for the text you use.
\version 2.19.18
makeGap = { \repeat unfold 2 { \hideNotes c1 \unHideNotes \noBreak } }
{
c''1
\noBreak \stopStaff \cadenzaOn
-\tweak extra-offset #'(1 . 3)_\markup\small { Text here }
\makeGap
\cadenzaOff \startStaff
c''1
}
That looks perfect, thanks! I'll tackle it later this evening, when my
wife goes out and I can play on the computer.
Cheers,
Wol
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: mutopia's shortcomings
Hi Gilles, This seemed great It *is* great — trust me. =) I looked for it in the documentation; and did not find it… Hopefully someday you will. 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. It also doesn’t make sense to feed a self-fueling spiral of wider non-acceptance by actively avoiding the use of a tool as game-changing as the edition-engraver. Instead, why not download it (from OLL), try it out, and — if it proves as beneficial to you as it is to some of us — help try to get it polished and accepted into the standard Lilypond distro? Just a “glass half-full” thought amongst this mostly “glass half-empty” thread. 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
Re: Color tweaks (edition engraver)
Hi Joram, hi Urs, I shall add this to my todo list. Hope to be able to work on it. Cheers, Jan-Peter Am 27. April 2015 17:51:31 MESZ, schrieb Noeck noeck.marb...@gmx.de: Hi Urs, thanks. I hoped it was easier. But then I will just color them by hand. Cheers, Joram ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user -- ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Color tweaks (edition engraver)
Hi,
On Mon, Apr 27, 2015 at 9:44 AM, Urs Liska u...@openlilylib.org wrote:
Am 27.04.2015 um 16:27 schrieb Noeck:
Dear all, dear Urs,
I would like to color tweaks of a particular edition of the edition
engraver. I know that there is a checkbox in Frescobaldi to color, so it
seems possible to color tweaked grobs in general.
No, I don't think this is possible, although I would really like to have
that feature (to immediately make visible what is original and what is
manual).
What we have in Frescobaldi depends on what we can catch by either
listening through engravers or by redefining command. So far I haven't
found a notion of a grob knowing if it has been tweaked or not.
Here's a code snippet to show that it is possible to tell if a grob has
been altered. Right now you have to add the procedure for each grob you
want to examine.
\version 2.19.17
#(define (mark-tweak grob)
(let* ((default (assoc-get (grob::name grob) all-grob-descriptions))
(props (ly:grob-basic-properties grob))
;; Our procedure has been added to the head of grob's basic
;; properties. Let's not count it as a tweak!
(props
(remove
(lambda (p)
(and (procedure? (cdr p))
(eq? (procedure-name (cdr p)) 'mark-tweak)))
props))
(diff (lset-difference eq? props default)))
;; Tweaks will not appear in the basic properties alist of our grob,
but
;; we can find them through the music event which led to the grob.
This
;; is (currently) available through the stream-event which caused our
grob.
(if (null? diff)
(let* ((cause (event-cause grob))
(tweaks (and cause
(ly:music-property
(ly:event-property cause 'music-cause)
'tweaks
(if (pair? tweaks)
(set! (ly:grob-property grob 'color) red)))
(set! (ly:grob-property grob 'color) green
{
\override NoteHead.after-line-breaking = #mark-tweak
c'
\once \override NoteHead.font-size = 3
c'
c'
\tweak font-size 3 c'
c'
\override Slur.after-line-breaking = #mark-tweak
c'( e')
\shape #'((0 . 0) (0 . -0.5) (0 . -0.5) (0 . 0)) Slur
c'( e')
}
%%%
Hope this is helpful.
David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
manuals page [WAS Re: teaching a university module on engraving with lilypond]
2015-04-27 17:25 GMT+02:00 Kevin Barry barr...@gmail.com: You know http://benlemon.me/blog/music/lilypond/operation-lilypond ? No I didn't know about this, and thank you for linking it. I will take a good look. This is listed here under Other material: http://www.lilypond.org/website/manuals.html Kevin probably missed it because he doesn't check that page often. But anyway it's not that easy to spot. I took a few seconds to look at that page with critical eyes and found that it could be improved a lot. As is, it's a kind of strict list which doesn't really guide a new user through the manuals. I wonder if Urs already started some work in this area, but I know he has more compelling tasks at the moment. Some thoughts: - remove Regular use vs Infrequent use sections - move FAQ and Video tutorials in the Introduction section, which could be renamed to First steps or New users or Introduction for new users - I'd rather use a conversational approach instead of unordered lists: Please be aware that LilyPond is a text-based(link) music engraver and read the FAQ(link) before You can see LilyPond in action in the following video tutorials made by Ben Lemon... (a small iframe of youtube video would be great). Then explain that the first manual to be read should be Learning and Usage, followed by Notation. - All other manuals are for regular or advanced users. - I would put a list of all the manuals at the end (or on the right column) and the Manual formats section could be an introduction to this list. So a possible layout could be a 2 column page: on the left two sections (New users, Advanced users) and on the right the manual list. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Trouble with alternative melody and lyrics
Peter,
I like Trevor's suggestions. I'd also recommend the following:
1. In the first verse lyrics, change to (i.e., remove the space).
This makes One line up better with the notehead. You can also do \skip 4
instead. For some reason, in 2.18.2, using creates a manual melisma,
which is not what you want in the first verse, I think.
2. Add \once \tiny to the note that is only used in the second verse (for
clarity):
{ \once \tiny \once \voiceTwo f }
...
- Abraham
On Mon, Apr 27, 2015 at 9:07 AM, Trevor Daniels [via Lilypond]
ml-node+s1069038n175485...@n5.nabble.com wrote:
Peter wrote Monday, April 27, 2015 8:25 AM
I have a song with two verses. The lyrics to the second stanza
occasionally have an extra syllable, such that there is a rest on that beat
in the first verse but a note in the second verse. I'm trying to address
this using the code found in notation manual (v. 2.18.2) in Section 2.1.3
Stanzas, subsection Switching to an alternative melody. See
http://www.lilypond.org/doc/v2.18/Documentation/notation/stanzas#stanzas-with-different-rhythms.
But I cannot get the lyrics to recognize and line up with the added beat in
the second stanza. An example, as minimal as I was able to get it, follows
below. Can anyone help? Also, is there a simpler approach that works for
this, so I don't have to define a new alternative voice every time this
situation occurs?
I'd use a simpler approach, like this (it's usually easiest to keep as
many notes as possible in the music associated with the lyrics, using skip
or to skip them as necessary):
\version 2.18.2
melody_verse = \relative c' {
c4
{ \once \voiceTwo f }
\new Voice { d'4\rest }
g,4 a |
}
\score {
\new Staff {
\new Voice = main {
\repeat volta 2 { \melody_verse }
}
}
\new Lyrics \lyricsto main {
One three four.
}
\new Lyrics \lyricsto main {
Uno dos tres quatro.
}
}
Trevor
___
lilypond-user mailing list
[hidden email] http:///user/SendEmail.jtp?type=nodenode=175485i=0
https://lists.gnu.org/mailman/listinfo/lilypond-user
--
If you reply to this email, your message will be added to the discussion
below:
http://lilypond.1069038.n5.nabble.com/Trouble-with-alternative-melody-and-lyrics-tp175453p175485.html
To start a new topic under User, email ml-node+s1069038n...@n5.nabble.com
To unsubscribe from Lilypond, click here
http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=2code=dGlzaW1zdC5saWx5cG9uZEBnbWFpbC5jb218Mnw4MzU3Njg3MDU=
.
NAML
http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Trouble-with-alternative-melody-and-lyrics-tp175453p175500.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Color tweaks (edition engraver)
On Mon, Apr 27, 2015 at 12:12 PM, David Nalesnik david.nales...@gmail.com wrote: Here's a code snippet to show that it is possible to tell if a grob has been altered. Right now you have to add the procedure for each grob you want to examine. Oh, I should mention that overrides have been colored green and tweaks red, for no real reason. DN ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: manuals page [WAS Re: teaching a university module on engraving with lilypond]
On 4/27/15 10:47 AM, Federico Bruni fedel...@gmail.com wrote: 2015-04-27 17:25 GMT+02:00 Kevin Barry barr...@gmail.com: - I'd rather use a conversational approach instead of unordered lists: Please be aware that LilyPond is a text-based(link) music engraver and read the FAQ(link) before You can see LilyPond in action in the following video tutorials made by Ben Lemon... (a small iframe of youtube video would be great). Then explain that the first manual to be read should be Learning and Usage, followed by Notation. I think that such an approach could be helpful. But Notation shouldn't be read. It should only be referenced. And I think we should make that clear whenever we talk about it. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Is GridLY the future? (Was: Do we really offer the future?)
2015-04-23 12:37 GMT+02:00 Urs Liska u...@openlilylib.org: Am 22.04.2015 um 22:58 schrieb Thomas Morley: I don't think it's a problem to get new functionality into LilyPond, _if_ it's coded properly. Sometimes people are scared by a maybe too rough tone, though. [...] It *is* a problem, and not only about code quality. More than once I abandoned a patch before the quality of the code was even considered but because of fruitless discussions about use cases, when for example using LilyPond to copy from existing sheet music is labelled a private use-case of a single developer. So actually I'm not too motivated providing patches for LilyPond when I can also implement what I need in openLilyLib. I think this is still better for LilyPond than if I' had completely quit. Actually I'm quite convinced that this situation has a notable impact on the overall development activiyt. I agree with Urs - in my opinion LilyPond is not developer-friendly enough. Actually it's one of the reasons why I was away for so long - the friction in the community caused me to loose some motivation to work on LilyPond. And I'm not the only one. best, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Is GridLY the future? (Was: Do we really offer the future?)
2015-04-28 7:27 GMT+02:00 Janek Warchoł janek.lilyp...@gmail.com: I agree with Urs - in my opinion LilyPond is not developer-friendly enough. Actually it's one of the reasons why I was away for so long - the friction in the community caused me to loose some motivation to work on LilyPond. And I'm not the only one. Just to make things clear: this is not necessarily anyone's _personal_ fault. Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Is GridLY the future?
Sometimes people are scared by a maybe too rough tone, though. It *is* a problem, and not only about code quality. More than once I abandoned a patch before the quality of the code was even considered but because of fruitless discussions about use cases, when for example using LilyPond to copy from existing sheet music is labelled a private use-case of a single developer. Well, someone playing the `advocatus diaboli' is quite important IMHO: in many cases, defending your own code leads to further improvements and refinements. So actually I'm not too motivated providing patches for LilyPond when I can also implement what I need in openLilyLib. I think this is still better for LilyPond than if I' had completely quit. Yes. Having the stuff in openLilyLib means that you can play with it until the code is mature enough for integration into lilypond. It is by no means a disaster if code doesn't get immediately accepted into lilypond! In case you are convinced of your stuff, simply try again later on. Actually I'm quite convinced that this situation has a notable impact on the overall development activiyt. I don't think so. Have you ever observed the development of Emacs or the Linux kernel, for example by reading the `emacs-devel' list? The rules there are *much* stricter than lilypond's one w.r.t. coding style, overall structure, etc., and in spite of this there is *a lot* of development going on. I agree with Urs - in my opinion LilyPond is not developer-friendly enough. Actually it's one of the reasons why I was away for so long - the friction in the community caused me to loose some motivation to work on LilyPond. And I'm not the only one. Indeed, this is unfortunate. Ideas to improve the overall situation are highly welcome – IIRC, Graham made a lot of good suggestions how to lead contributors. However, what we need is more developers that are *really* interested in developing lilypond! People who are scared away by a few harsh but factual comments don't count IMHO. Of course, ad-hominem attacks are definitely a no-go, but everything else has to be seen in the light of improving lilypond. I'm reading basically all e-mails on both lilypond-user and lilypond-devel, and I never observe this hostility noted by others. It seems that I'm an insensitive guy :-) Werner ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: mutopia's shortcomings
2015-04-27 19:02 GMT+02:00 Kieren MacMillan kieren_macmil...@sympatico.ca: 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. It also doesn’t make sense to feed a self-fueling spiral of wider non-acceptance by actively avoiding the use of a tool as game-changing as the edition-engraver. Instead, why not download it (from OLL), try it out, and — if it proves as beneficial to you as it is to some of us — help try to get it polished and accepted into the standard Lilypond distro? While it may or may not be a good idea to use EditionEngraver for big scores / big collections of scores, it definitely will be great if many people will try using it and report any issues. best, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Concepts that may be missing (or are at least hidden) in LilyPond
Hi, On Sun, Apr 26, 2015 at 11:17 PM, Carl Sorensen c_soren...@byu.edu wrote: Hi all, I'm still trying to get a list of musical concepts that you commonly use to talk about music that are either missing or hard to find in LilyPond. So far we have a set of two: Instruments Measures Are there any others that you can think of? What about the concept of a word in lyrics? Right now we have items of LyricText but nothing that explicitly groups them. One potential usage is in allowing syllables to snap together if they are too close together for a hyphen to appear. You can see a mock-up of the process though a newly defined LyricWord grob here http://www.mail-archive.com/lilypond-user%40gnu.org/msg90951.html . (This snippet is also at openLilyLib: https://github.com/openlilylib/openlilylib/tree/master/notation-snippets/lyric-syllable-magnetic-snap .) I suppose such a thing could also be used for reading off a text sans hyphens. David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
