Re: New snippet: remove staff if another is alive (for wind divisi)
Super glad to see this conversation happening! David I'm so glad you've been working on the backend for divisi. Divisi staves have long been my biggest headache. Thomas, thanks for writing the improved version. I haven't had a chance to look at the code deeply yet — I will play around with it this weekend. One observation about the user interface: logically, if the combined 1+2 staff is hidden, both the staff for 1 and the staff for 2 should be printed. IMO one of the design goals for a divisi user interface should be to manage this automatically without the need to write separate simultaneous commands to hide or unhide each staff. There are only two possible states for a two-part divisi: combined or separate staves. Only a single command should be needed to toggle that state. Extrapolate for 3, 4 way divisi etc. As an aside, for what it's worth, from my perspective as a composer who uses a lot of divisi staves, I want to minimize separation of divisi commands from musical content, because the choice to divide or not depends on the musical content, which I may revise frequently. I recognize that many other Lilypond users prefer the style you used in your example, but I just thought I'd mention it, since if this is moving towards an officially supported interface, IMO it needs to support both styles. Saul On Tue, Aug 7, 2018 at 12:42 PM David Kastrup wrote: > Thomas Morley writes: > > > 2018-08-07 20:28 GMT+02:00 David Kastrup : > >> Thomas Morley writes: > > > Ok, let me chime in: I've basically developed some of the low-level > mechanisms for divisi staves. > >>> > >>> You mean that 'make-dead-when stuff? > >> > >> Well, that's the internal part of the low end. But it's usually driven > >> by the remove-layer property. You are not actually using it? > > > > Nope. > > I'll have a closer look at it, though. > > Maybe it's a failure. It may well have problems scaling since it > creates a single hierarchy. I know that one tenet or inspiration for > that kind of numerical hierarchy was that it was reasonably certain to > avoid creating strange loops. > > -- > David Kastrup > > ___ > 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: Barcheck failure warnings for lyrics in parallel mode
On Tue 07 Aug 2018 at 12:30:03 (-0700), Galen Menzel wrote: > Now, although `lyrics_c` is a silly way to write a lyric line, > `lyrics_b` seems reasonable to me. Is there a better way to define a > lyric line in a `parallelMusic` definition so that lilypond doesn’t > complain? And if not, is there a way to suppress these barcheck > failure warnings? From NR §1.2.5: Note that bar check marks in lyrics are evaluated at the musical moment when the syllable following the check mark is processed. If the lyrics are associated with the notes of a voice which has a rest at the beginning of a bar, then no syllable can be located at the start of that bar and a warning will be issued if a bar check mark is placed in the lyrics at that position. Set the context property ignoreBarChecks might work. (I'm not a parallel music writer.) Cheers, David. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Barcheck failure warnings for lyrics in parallel mode
Hi all,
I’m using 2.18.2.
The following code compiles with no issue and correctly places the
lyrics below the notes:
```
melody_a = { r2 a8 b8 r4 | r2 a8 b8 r4 }
lyrics_a = \lyricmode { one two three four }
\score {
<<
\new Voice = "melody" \relative c'' \melody_a
\new Lyrics \lyricsto melody \lyrics_a
>>
\layout { }
}
```
However, I prefer to write lines in parallel, as follows:
```
\parallelMusic #'(melody_b lyrics_b) {
% Bar 1
r2 a8 b8r4 |
\lyricmode {one two }|
% Bar 2
r2 a8b8r4 |
\lyricmode {three four } |
}
\score {
<<
\new Voice = "melody" \relative c'' \melody_b
\new Lyrics \lyricsto melody \lyrics_b
>>
}
```
This typesets correctly, but lilypond complains that the bars in the
parallel music don't have the same length, and issues a barcheck-failure
warning. My understanding is that this parallel line is basically
equivalent to defining `lyrics_b` as
```
lyrics_b = { \lyricmode { one two } | \lyricmode { three four } }
```
and indeed, if we create a non-parallel version with the lyrics defined
like this, lilypond also complains:
```
melody_c = { r2 a8 b8 r4 | r2 a8 b8 r4 }
lyrics_c = { \lyricmode { one two } | \lyricmode { three four } }
\score {
<<
\new Voice = "melody" \relative c'' \melody_c
\new Lyrics \lyricsto melody \lyrics_c
>>
\layout { }
}
```
Now, although `lyrics_c` is a silly way to write a lyric line,
`lyrics_b` seems reasonable to me. Is there a better way to define a
lyric line in a `parallelMusic` definition so that lilypond doesn’t
complain? And if not, is there a way to suppress these barcheck failure
warnings?
I’ve attached a small example that contains these three ways of
defining a lyric line.
I’d appreciate any advice here!
Best,
Galen%{
When compiling this example, lilypond emits barcheck-failure warnings
for the lyrics_b and lyrics_c lines.
%}
\language "english"
melody_a = { r2 a8 b8 r4 | r2 a8 b8 r4 }
lyrics_a = \lyricmode { one two three four }
\score {
<<
\new Voice = "melody" \relative c'' \melody_a
\new Lyrics \lyricsto melody \lyrics_a
>>
\layout { }
}
\parallelMusic #'(melody_b lyrics_b) {
% Bar 1
r2 a8 b8r4 |
\lyricmode {one two }|
% Bar 2
r2 a8b8r4 |
\lyricmode {three four } |
}
\score {
<<
\new Voice = "melody" \relative c'' \melody_b
\new Lyrics \lyricsto melody \lyrics_b
>>
}
melody_c = { r2 a8 b8 r4 | r2 a8 b8 r4 }
lyrics_c = { \lyricmode { one two } | \lyricmode { three four } }
\score {
<<
\new Voice = "melody" \relative c'' \melody_c
\new Lyrics \lyricsto melody \lyrics_c
>>
\layout { }
}
\version "2.18.2"
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New snippet: remove staff if another is alive (for wind divisi)
Thomas Morley writes: > 2018-08-07 20:28 GMT+02:00 David Kastrup : >> Thomas Morley writes: > Ok, let me chime in: I've basically developed some of the low-level mechanisms for divisi staves. >>> >>> You mean that 'make-dead-when stuff? >> >> Well, that's the internal part of the low end. But it's usually driven >> by the remove-layer property. You are not actually using it? > > Nope. > I'll have a closer look at it, though. Maybe it's a failure. It may well have problems scaling since it creates a single hierarchy. I know that one tenet or inspiration for that kind of numerical hierarchy was that it was reasonably certain to avoid creating strange loops. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond & Halfdiminished/Diminished symbols.
On 08/07, liebre...@grossmann-venter.com wrote: > The problem has been solved by Mason The problem was pretty much entirely solved by David N. I'm glad that the very minor change I made got it closer to what you need, but you should thank him for writing the excellent \include. Sorry for getting the thread off-topic by bringing up the license. David K is correct that it was notrelevant to my point. What I should have said is that the snippet can be tweaked for your use case, and that this doesn't require criticism of something that has been shared with you that was written with a different case in mind. That's all. Best, Mason signature.asc Description: PGP signature ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond & Halfdiminished/Diminished symbols.
I thank you for the kind help and being to the point with a solution. You're a good competent person and I appreciate it. On 2018-08-07 15:07, ma...@masonhock.com wrote: On 08/07, liebre...@grossmann-venter.com wrote: The problem has been solved by Mason The problem was pretty much entirely solved by David N. I'm glad that the very minor change I made got it closer to what you need, but you should thank him for writing the excellent \include. Sorry for getting the thread off-topic by bringing up the license. David K is correct that it was notrelevant to my point. What I should have said is that the snippet can be tweaked for your use case, and that this doesn't require criticism of something that has been shared with you that was written with a different case in mind. That's all. Best, Mason ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New snippet: remove staff if another is alive (for wind divisi)
2018-08-07 20:28 GMT+02:00 David Kastrup : > Thomas Morley writes: >>> Ok, let me chime in: I've basically developed some of the low-level >>> mechanisms for divisi staves. >> >> You mean that 'make-dead-when stuff? > > Well, that's the internal part of the low end. But it's usually driven > by the remove-layer property. You are not actually using it? Nope. I'll have a closer look at it, though. Cheers, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New snippet: remove staff if another is alive (for wind divisi)
Thomas Morley writes: > 2018-08-07 19:48 GMT+02:00 David Kastrup : >> Thomas Morley writes: >> >>> 2018-08-06 21:40 GMT+02:00 Thomas Morley : 2018-08-05 18:14 GMT+02:00 Thomas Morley : > Inspired by your work I come up with the attached. Attached an improved and simplified version. It's tested with 2/3/4-voices divisi, all in one score. Although not tested, I see no reason why it shouldn't work with even more voices. >>> >>> >>> Further improvements. >>> >>> It's now possible to omit 'catch-me, _iff_ single instrument-staves >>> and divisi-staves belong exculsively to the same container-context >>> like StaffGroup, GrandStaff, ChoirStaff or PianoStaff with removed >>> "Keep_alive_together_engraver", which is most likely always the case. >>> For ungrouped single/divisi 'catch-me is still neccesary. >> >> Ok, let me chime in: I've basically developed some of the low-level >> mechanisms for divisi staves. > > You mean that 'make-dead-when stuff? Well, that's the internal part of the low end. But it's usually driven by the remove-layer property. You are not actually using it? > It does not work in 2.18.2. Sure. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New snippet: remove staff if another is alive (for wind divisi)
2018-08-07 19:48 GMT+02:00 David Kastrup : > Thomas Morley writes: > >> 2018-08-06 21:40 GMT+02:00 Thomas Morley : >>> 2018-08-05 18:14 GMT+02:00 Thomas Morley : >>> Inspired by your work I come up with the attached. >>> >>> Attached an improved and simplified version. >>> It's tested with 2/3/4-voices divisi, all in one score. >>> Although not tested, I see no reason why it shouldn't work with even >>> more voices. >> >> >> Further improvements. >> >> It's now possible to omit 'catch-me, _iff_ single instrument-staves >> and divisi-staves belong exculsively to the same container-context >> like StaffGroup, GrandStaff, ChoirStaff or PianoStaff with removed >> "Keep_alive_together_engraver", which is most likely always the case. >> For ungrouped single/divisi 'catch-me is still neccesary. > > Ok, let me chime in: I've basically developed some of the low-level > mechanisms for divisi staves. You mean that 'make-dead-when stuff? It does not work in 2.18.2. The 'staff-grouper grob-object? > There are no user-level commands or music > functions or Scheme abstractions making use of them. There is no parser > support (like for << \\ >>) but it's likely that isn't really required. Up to now I can't think of any parser-supported syntax. Seems all works so far with simple overrides. > But there certainly is a need for a user level interface, and from the > description this sounds like you are off to a good start. > > Think you can turn this (assuming it isn't already) into something > obvious and general enough that it would be satisfying to document and > use it without having to meddle with the low-level mechanisms at least, > say, 85% of the time? With my most recent coding the user has to do three things: (1) Initiate a divisi-Staff, applying p.e. \override VerticalAxisGroup.details.combined = #'(1 2) (2) Awake the divisi-Staff via \switchOn in the musical-content (3) Let it all happen with \override VerticalAlignment.before-line-breaking = %#(divisis "flutes" "trumpets" "cors") %#(divisis) #(divisis "flutes") at Score level. That's all. The whole scheme-coding could be included. Though, there are some points I don't like or have concerns. @(1) The argument '(1 2) will result in: combine voices 1 and 2 and kill the the single printing of them. But it relies on unchanged order of the lists processed. I'm currently not sure this is warrented, although testings didn't fail so far. Ofcourse I used details.combined to avoid a real custom-grob-property, some for 'catch-me. If we think of implementing something like this coding we should probably turn those in own grob-properties @(2) It's done by switchOff = \set Staff.keepAliveInterfaces = #'() switchOn = \unset Staff.keepAliveInterfaces I'm not sure I like this, it feels clumsy. @(3) Here I'm fine so far, having a procedure doing all automagically, unless container-contexts are missing. Currently I'm a bit at a loss how to proceed. Ideas? Cheers, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond & Halfdiminished/Diminished symbols.
Quite frankly you were stabbing at me for no reason from onset. Even if I agreed with you, you kept stabbing. The problem has been solved by Mason and you keep harping along trying to look for anything to fight about. Since it is my thread I kindly request you not to respond to my posts even if you have the best solution. I prefer to keep the peace. I know you can do what you want, but it would be nice to keep things civil. /. On 2018-08-07 11:44, David Kastrup wrote: liebre...@grossmann-venter.com writes: Unfortunately you overlooked one little point. From the author " But perhaps there's something in the code that you can use towards your own goals. Like, for example,the routines for drawing the diminished and half-diminished circles. Like parsing input. Whatever. " Which gives the right to change the code at least for the diminished argument. Try reading what I actually wrote: What's relevant for this is mostly "in source of an interpreted language", since modifying and using code given to you for your own private use tends to be allowed by most copyright jurisdiction. The freedom of the GPL kicks in when you want to _share_ your modifications with others, for discussion, for integration into LilyPond, or for other purposes. In US copyright law that is consent and that is exactly what Mason did What about "modifying and using code given to you for your own private use tends to be allowed by most copyright jurisdiction." did you not understand? The most annoying thing about licensing discussions (and a whole lot of other discussions) is that people simply cannot be bothered to actually read what they are replying to and just put out their standard text blocks based on trigger words, violently refuting straw men. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New snippet: remove staff if another is alive (for wind divisi)
Thomas Morley writes: > 2018-08-06 21:40 GMT+02:00 Thomas Morley : >> 2018-08-05 18:14 GMT+02:00 Thomas Morley : >> >>> Inspired by your work I come up with the attached. >> >> Attached an improved and simplified version. >> It's tested with 2/3/4-voices divisi, all in one score. >> Although not tested, I see no reason why it shouldn't work with even >> more voices. > > > Further improvements. > > It's now possible to omit 'catch-me, _iff_ single instrument-staves > and divisi-staves belong exculsively to the same container-context > like StaffGroup, GrandStaff, ChoirStaff or PianoStaff with removed > "Keep_alive_together_engraver", which is most likely always the case. > For ungrouped single/divisi 'catch-me is still neccesary. Ok, let me chime in: I've basically developed some of the low-level mechanisms for divisi staves. There are no user-level commands or music functions or Scheme abstractions making use of them. There is no parser support (like for << \\ >>) but it's likely that isn't really required. But there certainly is a need for a user level interface, and from the description this sounds like you are off to a good start. Think you can turn this (assuming it isn't already) into something obvious and general enough that it would be satisfying to document and use it without having to meddle with the low-level mechanisms at least, say, 85% of the time? -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond & Halfdiminished/Diminished symbols.
David Nalesnik writes: >> On 2018-08-07 04:03, David Kastrup wrote: >> > >> > A license, as opposed to relying on people to stay nice, also protects >> > you against such worst case scenarios. >> > >> > Also many (but not necessarily all) code pieces from David may be >> > substantially derived from LilyPond code code licensed under the GPL. >> > In that case, the derived code cannot be licensed under different >> > conditions without being, in turn, in violation of the code it made use >> > of. > > Good grief :( I selected the MIT license because it's very common, and > in the spirit of, as you write, "feel free to use it, I don't care." For original code you don't want to bother with in any manner (in particularly not suing over), it's a good choice. But it makes it easier for people to stay in compliance if you actually add the license headers to the files. As I said: most of our interactions are governed by us being nice reasonable people that feel they are part of a community. In particular, there are lots of exchanges posting sample code without ever bothering to mention licensing. Strictly speaking, that puts them under default copyright, not permitting copying and modification outside of personal use. Who is going to sue? Within this kind of semi-personal communication, someone feeling pissed off. Taking code and redistributing as part of a proprietary program: that may annoy some people. Taking code and redistributing under the MIT license: unlikely. But then someone else may take the code and redistribute as part of a proprietary program. Licensing for most programmers is an annoying mess to think about, but there are people whose profession is thinking about that annoying mess and copyright does not always stay with the people you interacted with originally since it is a transferable assets, and not all asset transfers are voluntary (for example, bankruptcy and death usually involve transfer of assets). Licenses are the hard underpinnings of what originally is (and some think should be) just nice people interacting with one another. The GPL and the GNU project were born basically when RMS fell flat on his face regarding Gosling Emacs and nice people staying nice. Now it seems nobody understood my motivation of contradicting Mason who stated that "software freedom" enabled modifying and using what you posted, and my pedantry caused me to contradict him because in that particular case it was first the implied permission of your reply with code enabling personal use, and the freedoms granted by your GitHub license on the referenced code which would have permitted modification and redistributing _if_ the conditions of the MIT license had been met, which they hadn't. So basically he relied on you being a nice guy. And that is what most interactions on the list actually boil down to. The licenses are the hard underpinnings, but most of the time we are actually walking on thin air. It's just that should we fall, usually the hard underpinnings are close enough that it doesn't matter. So why talk about it at all? Because I am a pedant. Sometimes I just like to dissect things and see what is actually involved. Sorry for annoying anybody. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond & Halfdiminished/Diminished symbols.
On Tue, Aug 7, 2018 at 12:12 PM David Nalesnik wrote: > Good grief :( I selected the MIT license because it's very common, > and in the spirit of, as you write, "feel > free to use it, I don't care." > > Seems I'm not the only one--I read this in the openlilylib repo > (https://github.com/openlilylib/snippets/blob/master/LICENSE): > > "Since most of the snippets are separate entities, > they can be licensed individially. > There are no official rules on licensing (yet); > We suggest that unless otherwise specified > everything should be licensed under the MIT license > as found at http://opensource.org/licenses/MIT. > Any content of this repository that isn't explicitly > licensed is implicitly licensed under the rules of > this MIT license." > > Best, > David N And LilyBin: https://github.com/LilyBin/LilyBin/blob/master/LICENSE DN ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New snippet: remove staff if another is alive (for wind divisi)
2018-08-06 21:40 GMT+02:00 Thomas Morley : > 2018-08-05 18:14 GMT+02:00 Thomas Morley : > >> Inspired by your work I come up with the attached. > > Attached an improved and simplified version. > It's tested with 2/3/4-voices divisi, all in one score. > Although not tested, I see no reason why it shouldn't work with even > more voices. Further improvements. It's now possible to omit 'catch-me, _iff_ single instrument-staves and divisi-staves belong exculsively to the same container-context like StaffGroup, GrandStaff, ChoirStaff or PianoStaff with removed "Keep_alive_together_engraver", which is most likely always the case. For ungrouped single/divisi 'catch-me is still neccesary. Cheers, Harm \version "2.19.82" \pointAndClickOff %% relies on: %% %% VerticalAxisGroup.details.catch-me %% VerticalAxisGroup.details.combined %% %% About `catch-me` %% Inside of container-contexts like StaffGroup, GrandStaff, ChoirStaff or %% PianoStaff with removed "Keep_alive_together_engraver" %% `catch-me` may be omitted. %% To get divisis work outside of such containers `catch-me` needs to be set %% to a value matching one of the optional arguments of the divisis-procedure %% Currently we use strings for `catch-me` and the arguments of the %% divisis-procedure, a symbol would work as well. %% %% About `combined` %% `combined` labels divisi-staffs. It is supposed to be a list of positive %% integers, representing the combined instruments. %% p.e. To combine flute-III and flute-IV, set `combined` to '(3 4) %% %% %% More inline comments below %% %% %% Limitations: %% Staves can't be started/ended mid-line. %% TODOs %% Killing/awakening relies on the order single instrument-staves are entered. %% Is it safe to assume the order of lists with VerticalAxisGroups will %% not be confused? %% c/p from lily-library.scm #(define (split-at-predicate pred lst) "Split LST into two lists at the first element that returns #f for (PRED previous_element element). Return the two parts as a pair. Example: (split-at-predicate < '(1 2 3 2 1)) ==> ((1 2 3) . (2 1))" (let ((i (and (pair? lst) (list-index (lambda (x y) (not (pred x y))) lst (cdr lst) (if i (call-with-values (lambda () (split-at lst (1+ i))) cons) (list lst #(define (sort-vags vags) ;; Returns sublists of VAGs in same StaffGrouper (define (helper l1 l2) (if (null? l1) (reverse l2) (let ((splitted-l1 (split-at-predicate (lambda (x y) (equal? (ly:grob-object x 'staff-grouper) (ly:grob-object y 'staff-grouper))) l1))) (helper (cdr splitted-l1) (cons (car splitted-l1) l2) (helper vags '())) #(define (select-vags vags) ;; Return two sublists containing VerticalAxisGroups with and without ;; setted 'combined. (call-with-values (lambda () (partition (lambda (vag) (pair? (assoc-get 'combined (ly:grob-property vag 'details) '( vags)) (lambda (x y) (list x y #(define (kill-selected-vags sorted-vags) ;; `sorted-vags` is supposed to be a list of two sublists, containing ;; VerticalAxisGroups for divisi and non-divisi-staves (if (pair? (car sorted-vags)) (for-each (lambda (i) ;; if divisi staves are alive, kill selected other staves ;; relying on the combined-values (for-each (lambda (x) (ly:pointer-group-interface::add-grob x 'make-dead-when (list-ref (car sorted-vags) i))) ;; get a list of VerticalAxisGroups used with ;; divisi-staves (map (lambda (index) (list-ref (cadr sorted-vags) (1- index))) ;; get the 'combined-value from 'details, which is ;; supposed to be a list. ;; TODO 'combined is read here and in `splitted` above. ;; Find a method to spare one go (assoc-get 'combined (ly:grob-property (list-ref (car sorted-vags) i) 'details) '() (iota (length (car sorted-vags)) #(define (divisis . divisi-groups) ;; Kill selected other Staffs, if divisi-Staffs are alive. ;; Do it separatly for every instrument-group specified by `divisi-groups`. (lambda (grob) ;; `grob` is supposed to be `VerticalAlignment`, per default living in ;; Score-context (let* (;; Get all `VerticalAxisGroup`s from `VerticalAlignment` ;; Those are the relevant grobs to look at to make others dead ;; or not (vags-array (ly:grob-object grob 'elements)) (vags-list ;; empty lists removed (if (null? vags-array) '() (remove
Re: Lilypond & Halfdiminished/Diminished symbols.
> On 2018-08-07 04:03, David Kastrup wrote: > > ma...@masonhock.com writes: > > > >> Then it's a good thing that David shared his code as free (as in > >> freedom[1]) software, so that it can be modified for your unique use > >> case. > > > > What's relevant for this is mostly "in source of an interpreted > > language", since modifying and using code given to you for your own > > private use tends to be allowed by most copyright jurisdiction. The > > freedom of the GPL kicks in when you want to _share_ your modifications > > with others, for discussion, for integration into LilyPond, or for > > other > > purposes. > > > >> The modified file is attached, and example usage is below. > > > > Well, that kind of thing (_you_ modifying the copy and reposting on the > > list) definitely requires the actual freedom of the code. > > > > So what are the original terms? Looking at David's original GitHub > > page, I see "MIT license". The terms of the MIT license are quite > > permissive but contain > > > > The above copyright notice and this permission notice shall be > > included in all copies or substantial portions of the Software. > > > > which hasn't happened here. So you are in breach of the license and > > the > > reference to "freedom" is a red herring. What's really involved here > > is > > that David is a nice guy unlikely to sue people reusing his code and > > you > > are relying on that. Now of course the _spirit_ of the license is > > "feel > > free to use it, I don't care" so that assumption is likely pretty good > > but that does not save you against David having a really bad day. > > > > And when talking about licenses, really bad days are what they are good > > for. A really bad day may involve bankruptcy and all your private > > assets being acquired by Microsoft. That kind of thing often involves > > a > > substantial change of mind of the new copyright owner. > > > > A license, as opposed to relying on people to stay nice, also protects > > you against such worst case scenarios. > > > > Also many (but not necessarily all) code pieces from David may be > > substantially derived from LilyPond code code licensed under the GPL. > > In that case, the derived code cannot be licensed under different > > conditions without being, in turn, in violation of the code it made use > > of. Good grief :( I selected the MIT license because it's very common, and in the spirit of, as you write, "feel free to use it, I don't care." Seems I'm not the only one--I read this in the openlilylib repo (https://github.com/openlilylib/snippets/blob/master/LICENSE): "Since most of the snippets are separate entities, they can be licensed individially. There are no official rules on licensing (yet); We suggest that unless otherwise specified everything should be licensed under the MIT license as found at http://opensource.org/licenses/MIT. Any content of this repository that isn't explicitly licensed is implicitly licensed under the rules of this MIT license." Best, David N ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Compile PDF, PNG and SVG in one run?
Hi, I have to produce multiple files from one .ly file, and since it isn't actually one but >500 files I would like to make it automatic. Of course I know how to achieve this with a wrapper script, but I'd prefer to find a way with only one compilation (i.e. parsing) per file. I know I can produce PDF and PNG by using --pdf --png on the command line but it seems impossible to have svg too. Is there anything I've overlooked? Would it be possible to somehow store the parsed \score block and use something like ly:book-process to produce different file formats? Thanks Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond & Halfdiminished/Diminished symbols.
liebre...@grossmann-venter.com writes: > Unfortunately you overlooked one little point. > > From the author > " > But perhaps there's something in the code that you can use towards > your own goals. Like, for example,the routines for drawing the > diminished and half-diminished circles. > Like parsing input. Whatever. > " > > Which gives the right to change the code at least for the diminished > argument. Try reading what I actually wrote: >> What's relevant for this is mostly "in source of an interpreted >> language", since modifying and using code given to you for your own >> private use tends to be allowed by most copyright jurisdiction. The >> freedom of the GPL kicks in when you want to _share_ your >> modifications with others, for discussion, for integration into >> LilyPond, or for other purposes. > In US copyright law that is consent and that is exactly what Mason did What about "modifying and using code given to you for your own private use tends to be allowed by most copyright jurisdiction." did you not understand? The most annoying thing about licensing discussions (and a whole lot of other discussions) is that people simply cannot be bothered to actually read what they are replying to and just put out their standard text blocks based on trigger words, violently refuting straw men. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond & Halfdiminished/Diminished symbols.
Unfortunately you overlooked one little point. From the author " But perhaps there's something in the code that you can use towards your own goals. Like, for example,the routines for drawing the diminished and half-diminished circles. Like parsing input. Whatever. " Which gives the right to change the code at least for the diminished argument. In US copyright law that is consent and that is exactly what Mason did no more so I dont know why he need be reminded of any transgressions. He clearly acted on the consent only. As thread starter, I got to the point, non argumentative, help from Mason which is how things should be done. On 2018-08-07 04:03, David Kastrup wrote: ma...@masonhock.com writes: Then it's a good thing that David shared his code as free (as in freedom[1]) software, so that it can be modified for your unique use case. What's relevant for this is mostly "in source of an interpreted language", since modifying and using code given to you for your own private use tends to be allowed by most copyright jurisdiction. The freedom of the GPL kicks in when you want to _share_ your modifications with others, for discussion, for integration into LilyPond, or for other purposes. The modified file is attached, and example usage is below. Well, that kind of thing (_you_ modifying the copy and reposting on the list) definitely requires the actual freedom of the code. So what are the original terms? Looking at David's original GitHub page, I see "MIT license". The terms of the MIT license are quite permissive but contain The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. which hasn't happened here. So you are in breach of the license and the reference to "freedom" is a red herring. What's really involved here is that David is a nice guy unlikely to sue people reusing his code and you are relying on that. Now of course the _spirit_ of the license is "feel free to use it, I don't care" so that assumption is likely pretty good but that does not save you against David having a really bad day. And when talking about licenses, really bad days are what they are good for. A really bad day may involve bankruptcy and all your private assets being acquired by Microsoft. That kind of thing often involves a substantial change of mind of the new copyright owner. A license, as opposed to relying on people to stay nice, also protects you against such worst case scenarios. Also many (but not necessarily all) code pieces from David may be substantially derived from LilyPond code code licensed under the GPL. In that case, the derived code cannot be licensed under different conditions without being, in turn, in violation of the code it made use of. Basically, the bulk of our interactions are governed by everyone being nice, and that's how most programmers interacted with each other half a century ago. But when push comes to shove and/or the legal department comes into play and sees purportive company assets being juggled with, a license as a fallback may make a difference. The GPL as the legal basis for GNU was created after push came to shove regarding Gosling Emacs. So while we act regarding the letter of the licenses we are working with rather intermittently, it turns out that the actual underlying licenses leave very little substance for legal departments and miffed persons to get really nasty with rather than mostly annoying. Not a perfect world, but it's less dangerous to pretend it is than before we picked licenses. [1] https://www.gnu.org/philosophy/free-sw.html ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Re-sizing score on the fly
On 08/07/2018 11:37 AM, Johan Vromans wrote:
On Tue, 7 Aug 2018 18:25:53 +1000, Don Gingrich
wrote:
Then the multiplier would reside in the included files, the
variable would be in the score file, and by including
the correct file I could have either type of score.
Why not set the staff size in the included file, just like the paper
settings?
I assume that some scores are meant to have a smaller staff size than
others, hence the need for a separate multiplier.
Say score A has "design size" ("natural size"? whatever) of 16 and
should be scaled up to 1.25*16 = 20, while score B with a smaller piece
has "design size" of 20 and should be scaled up by the same factor to
1.25*20 = 24.
Anyway, regardless of the use case, the following piece of code should
do it:
#(define design-staff-size 16)
#(define staff-size-multiplier 1.25)
#(set-global-staff-size (* design-staff-size staff-size-multiplier))
The "(* variable multiplier)" part is Scheme syntax for "apply the
multiplication function to design-staff-size and staff-size-multiplier".
The definitions of the two variables can be anywhere before the call to
set-global-staff-size, including includes. IIUC, this is what you want
to achieve?
HTH,
Alex
smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Re-sizing score on the fly
On Tue, 7 Aug 2018 18:25:53 +1000, Don Gingrich wrote: > Then the multiplier would reside in the included files, the > variable would be in the score file, and by including > the correct file I could have either type of score. Why not set the staff size in the included file, just like the paper settings? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re-sizing score on the fly
This is an unusual problem. I've got a bunch of
scores that I process to PDF and include in a a
LaTeX "container" document to produce a booklet
of nearly 200 pages at this point. But I also want
to be able to print them as individual scores.
When I'm "including" a score, I push the margins
to nearly the edge so that when they are "included"
they are the proper size on the page and allow for
page numbers (and I could probably put a header
in the top margin or footnote identifying the book
in the bottom margin.
What I'm also doing is using two different files
to set margins on the page, etc.
For include I use:
\version "2.18.2"
\paper {
paper-width = 21.0\cm
paper-height = 29.7\cm
top-margin = 1.0\cm
bottom-margin = 2.0\cm
left-margin = 0.5\cm
right-margin = 0.5\cm
indent = 0
%%set to ##t if your score is less than one page:
ragged-last-bottom = ##t
}
For separate I use:
\version "2.18.2"
\paper {
paper-width = 21.0\cm
paper-height = 29.7\cm
line-width = 190\mm
left-margin = 1.0\cm
top-margin = 1.0\cm
bottom-margin = 2.0\cm
indent = 0
%%set to ##t if your score is less than one page:
ragged-last-bottom = ##t
ragged-bottom = ##f
}
And I've been using:
\include "/home/don/Documents/music/busking/stand-alone.ly"
or
\include "/home/don/Documents/music/busking/booklet.ly"
My template for a lead sheet has both and I "comment-out"
the one that doesn't apply.
The problem comes in with the
#(set-global-staff-size 21.8)
directive.
Because I'm ageing (aren't we all), I try to make the
staves and lyrics as large as possible. But, as large
as possible for an included file over two pages can
mean three pages when it's stand-alone, or smaller than
it could have been if it was set for stand-alone and is
then printed with the smaller margins for inclusion.
Is there a way to use a "multiplier" that I could set in
the above two files and multiply in the
set-global-staff-size to make this "automagic"?
variable=xxx
multiplier=y.yy
#(set-global-staff-size variable*multiplier)
Then the multiplier would reside in the included files, the
variable would be in the score file, and by including
the correct file I could have either type of score.
I'm fairly certain that if I could use a relative path
in the include and a series of hard links between a pair
of directories on my Linux system, I should be able to
maintain two sets of scores from a single "master" set.
This would make me very happy. :-)
If you've got this far, thank you for your patience.
Cheers,
-Don
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond & Halfdiminished/Diminished symbols.
Forgot to copy list.
On 08/06, ma...@masonhock.com wrote:
> On 08/06, liebre...@grossmann-venter.com wrote:
> > Sure, but from a programming point of view it is better to have all
> > characters the same size, then if in the exponent or subscript then shrink
> > them.
>
> That makes sense when rendering characters in general, which is what \markup
> is for and how it behaves. What we're discussing is a tool for roman numeral
> analysis, and in roman numeral analysis the diminished and half-diminished
> symbols are always superscripts. The syntax is well-optimized for normal
> usage. I wouldn't want to have to specify that half diminished symbol as a
> superscript when the superscript position should be the default placement.
>
> > It is my personal choice to use it like that regardless of what the
> > Conservatoire requires.
> > I sometime need the half diminished and diminished as the only character
>
> Then it's a good thing that David shared his code as free (as in freedom[1])
> software, so that it can be modified for your unique use case. Even without
> understanding Scheme, it wasn't too hard for me to copy/paste/modify the
> functions for "h" and "o" to create "H" and "O" which produce larger versions
> of the symbol while leaving "h" and "o" intact for normal usage. If you wish,
> you can tweak the size of the symbols further by experimenting with the
> numbers in the paragraphs beginning with "#(define
> (make-diminished-large-markup font-size)" and "#(define
> (make-half-diminished-large-markup font-size)".
>
> The modified file is attached, and example usage is below.
>
> -
> \version "2.19.82"
> \language "english"
>
> \include "roman_numeral_analysis_tool.ily"
>
> bassline = \relative c' {
> \key c \minor
> \clef bass
> c, b c d |
> ef f g c, |
> }
>
> analysis = \lyricmode {
> \markup \rN { i }
> \markup \rN { O 7 }
> \markup \rN { i }
> \markup \rN { V 6 4 }
> \markup \rN { i 6 }
> \markup \rN { H 6 5 }
> \markup \rN { V }
> \markup \rN { i }
> }
>
> \score {
> \new Staff <<
> \new Voice = "bass" { \bassline }
> \new Lyrics \lyricsto "bass" { \analysis }
> >>
> }
> -
>
> Mason
>
> [1] https://www.gnu.org/philosophy/free-sw.html
>
> %% A function to create Roman numerals for harmonic analysis.
> %%
> %% Syntax: \markup \rN { ...list of symbols... }
> %%
> %% List symbols in this order (as needed): Roman numeral (or note name),
> %% quality, inversion figures from top to bottom, "/" (if a secondary
> %% function), Roman numeral (or note name). Usually, you can skip unnecessary
> %% items, though a spacer may be needed in some cases. Use "" instead of the
> %% initial symbol to start with the quality or inversion, for example.
> Elements
> %% must be separated by whitespace.
> %%
> %% Notenames are represented by their English LilyPond names. In addition,
> you
> %% may capitalize the name for a capitalized note name.
> %%
> %% Preceding a string representing a Roman numeral with English alterations
> %% (f, flat, s, sharp, ff, flatflat, ss, x, sharpsharp, natural)
> %% will attach accidentals, for example, "fVII" -> flat VII; "sharpvi" ->
> sharp vi.
> %% You may precede inversion numbers with alterations, though "+" is not
> %% presently supported.
> %%
> %% Qualities: use "o" for diminished, "h" for half-diminished, "+" for
> augmented,
> %% and "f" for flat. Other indications are possible such as combinations of
> "M"
> %% and "m" (M, m, MM7, Mm, mm, Mmm9, etc.); add, add6, etc.
> %%
> %% To scale all numerals: \override LyricText #'font-size = #2
> %% or \override TextScript #'font-size = #2
> %% To scale individual numerals: \markup \override #'(font-size . 2) \rN {
> ... }
>
>
>
> THE APPROACH %%
>
> %% In our approach, a Roman numeral consists of
>
> %% 1. A "base". OPTIONAL. This may be a Roman numeral (some combination of
> I, i, V,
> %% and v, unenforced); a note name; or some other string. Roman numerals may
> be
> %% preceded by an accidental, and a note name may be followed by one.
>
> %% 2. a quality indicator. OPTIONAL. Eventually, this will simply be
> something to
> %% set as a superscript following the base, whether or not it is actually a
> %% indicator of quality.
>
> %% 3. A single inversion number, or more than one, to be set as a column.
> OPTIONAL.
> %% An initial accidental is supported. (This will be extended to "anything
> you want
> %% to appear in a column after the quality indicator.")
>
> %% 4. "/" followed by a "secondary base" for indicating tonicization.
> OPTIONAL.
> %% As with 1. this may a Roman numeral or note name, and may include an
>
Re: Lilypond & Halfdiminished/Diminished symbols.
On 08/06, liebre...@grossmann-venter.com wrote:
> Sure, but from a programming point of view it is better to have all
> characters the same size, then if in the exponent or subscript then shrink
> them.
That makes sense when rendering characters in general, which is what \markup is
for and how it behaves. What we're discussing is a tool for roman numeral
analysis, and in roman numeral analysis the diminished and half-diminished
symbols are always superscripts. The syntax is well-optimized for normal usage.
I wouldn't want to have to specify that half diminished symbol as a superscript
when the superscript position should be the default placement.
> It is my personal choice to use it like that regardless of what the
> Conservatoire requires.
> I sometime need the half diminished and diminished as the only character
Then it's a good thing that David shared his code as free (as in freedom[1])
software, so that it can be modified for your unique use case. Even without
understanding Scheme, it wasn't too hard for me to copy/paste/modify the
functions for "h" and "o" to create "H" and "O" which produce larger versions
of the symbol while leaving "h" and "o" intact for normal usage. If you wish,
you can tweak the size of the symbols further by experimenting with the numbers
in the paragraphs beginning with "#(define (make-diminished-large-markup
font-size)" and "#(define (make-half-diminished-large-markup font-size)".
The modified file is attached, and example usage is below.
-
\version "2.19.82"
\language "english"
\include "roman_numeral_analysis_tool.ily"
bassline = \relative c' {
\key c \minor
\clef bass
c, b c d |
ef f g c, |
}
analysis = \lyricmode {
\markup \rN { i }
\markup \rN { O 7 }
\markup \rN { i }
\markup \rN { V 6 4 }
\markup \rN { i 6 }
\markup \rN { H 6 5 }
\markup \rN { V }
\markup \rN { i }
}
\score {
\new Staff <<
\new Voice = "bass" { \bassline }
\new Lyrics \lyricsto "bass" { \analysis }
>>
}
-
Mason
[1] https://www.gnu.org/philosophy/free-sw.html
%% A function to create Roman numerals for harmonic analysis.
%%
%% Syntax: \markup \rN { ...list of symbols... }
%%
%% List symbols in this order (as needed): Roman numeral (or note name),
%% quality, inversion figures from top to bottom, "/" (if a secondary
%% function), Roman numeral (or note name). Usually, you can skip unnecessary
%% items, though a spacer may be needed in some cases. Use "" instead of the
%% initial symbol to start with the quality or inversion, for example. Elements
%% must be separated by whitespace.
%%
%% Notenames are represented by their English LilyPond names. In addition, you
%% may capitalize the name for a capitalized note name.
%%
%% Preceding a string representing a Roman numeral with English alterations
%% (f, flat, s, sharp, ff, flatflat, ss, x, sharpsharp, natural)
%% will attach accidentals, for example, "fVII" -> flat VII; "sharpvi" -> sharp
vi.
%% You may precede inversion numbers with alterations, though "+" is not
%% presently supported.
%%
%% Qualities: use "o" for diminished, "h" for half-diminished, "+" for
augmented,
%% and "f" for flat. Other indications are possible such as combinations of "M"
%% and "m" (M, m, MM7, Mm, mm, Mmm9, etc.); add, add6, etc.
%%
%% To scale all numerals: \override LyricText #'font-size = #2
%% or \override TextScript #'font-size = #2
%% To scale individual numerals: \markup \override #'(font-size . 2) \rN { ... }
THE APPROACH %%
%% In our approach, a Roman numeral consists of
%% 1. A "base". OPTIONAL. This may be a Roman numeral (some combination of I,
i, V,
%% and v, unenforced); a note name; or some other string. Roman numerals may be
%% preceded by an accidental, and a note name may be followed by one.
%% 2. a quality indicator. OPTIONAL. Eventually, this will simply be
something to
%% set as a superscript following the base, whether or not it is actually a
%% indicator of quality.
%% 3. A single inversion number, or more than one, to be set as a column.
OPTIONAL.
%% An initial accidental is supported. (This will be extended to "anything you
want
%% to appear in a column after the quality indicator.")
%% 4. "/" followed by a "secondary base" for indicating tonicization. OPTIONAL.
%% As with 1. this may a Roman numeral or note name, and may include an
accidental.
%% The input syntax is chosen to be friendly to the user rather than the
computer.
%% In particular, the user usually need only type the symbols needed when
%% reading the analytical symbol aloud. This is not perfect: spacers
%% may be necessary for omissions. Additionally, we try to interpret
