Re: Segmentation Fault in 2.18 (was Re: Learn from Finale 2014 (seriously)?)
I just came across a workaround for this LilyPond crash - adding \once \override MultiMeasureRestNumber #'transparent = ##t before the multi-measure rests in the second voice results in the typesetting finishing correctly. I came across this because I was getting the number printed twice in some circumstances (even though the rest was only printed once), and this fixed that bug. The only remaining tweak is to adjust the vertical positioning of the multi-measure rest, then Denemo will have a complete package of commands for printing a score and parts where some parts have multi-measure rests that are shared. Richard On Sat, 2014-02-01 at 15:04 +, Richard Shann wrote: On Thu, 2013-11-14 at 21:14 +0100, Jan-Peter Voigt wrote: On 14.11.2013 16:19, Joseph Rushton Wakeling wrote: there is an update of this snippet in the mail archives and I will post my version later. Fantastic, thank you! :-) so, here is the version I regularly use ... in fact, this is taken from some e-mail on this list some time ago. It also merges MultiMeasure rests. I was just putting this code into Denemo and I noticed it merged a multi-measure rest in the top voice with a sequence of whole measure rests in the second voice, but it caused a segmentation fault in LilyPond when it tries to merge multi measure rests from both voices. The test file that shows this is attached. The include file is also attached, it is the mergeRests.ly from the original message with the example removed and convert-ly run on it to update it from 2.16.1 - the resultant version reads 2.17.97 which I recall is a known bug. I guess this part of the thread needs to switch to lilypond-devel or lilypond-bug, now - I originally started this email just to enquire about merging multi-measure rests ... Richard ___ 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: Segmentation Fault in 2.18 (was Re: Learn from Finale 2014 (seriously)?)
On Thu, Feb 27, 2014 at 10:27:53AM +, Richard Shann wrote: I just came across a workaround for this LilyPond crash - adding I have been getting very occasional segfaults with Lily since at least 2.17. I have never been able to create a minimal example because as soon as I change anything the code works fine. Paul Scott \once \override MultiMeasureRestNumber #'transparent = ##t before the multi-measure rests in the second voice results in the typesetting finishing correctly. I came across this because I was getting the number printed twice in some circumstances (even though the rest was only printed once), and this fixed that bug. The only remaining tweak is to adjust the vertical positioning of the multi-measure rest, then Denemo will have a complete package of commands for printing a score and parts where some parts have multi-measure rests that are shared. Richard On Sat, 2014-02-01 at 15:04 +, Richard Shann wrote: On Thu, 2013-11-14 at 21:14 +0100, Jan-Peter Voigt wrote: On 14.11.2013 16:19, Joseph Rushton Wakeling wrote: there is an update of this snippet in the mail archives and I will post my version later. Fantastic, thank you! :-) so, here is the version I regularly use ... in fact, this is taken from some e-mail on this list some time ago. It also merges MultiMeasure rests. I was just putting this code into Denemo and I noticed it merged a multi-measure rest in the top voice with a sequence of whole measure rests in the second voice, but it caused a segmentation fault in LilyPond when it tries to merge multi measure rests from both voices. The test file that shows this is attached. The include file is also attached, it is the mergeRests.ly from the original message with the example removed and convert-ly run on it to update it from 2.16.1 - the resultant version reads 2.17.97 which I recall is a known bug. I guess this part of the thread needs to switch to lilypond-devel or lilypond-bug, now - I originally started this email just to enquire about merging multi-measure rests ... Richard ___ 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
Segmentation Fault in 2.18 (was Re: Learn from Finale 2014 (seriously)?)
On Thu, 2013-11-14 at 21:14 +0100, Jan-Peter Voigt wrote:
On 14.11.2013 16:19, Joseph Rushton Wakeling wrote:
there is an update of this snippet in the mail archives and I will post
my version later.
Fantastic, thank you! :-)
so, here is the version I regularly use ... in fact, this is taken from
some e-mail on this list some time ago. It also merges MultiMeasure rests.
I was just putting this code into Denemo and I noticed it merged a
multi-measure rest in the top voice with a sequence of whole measure
rests in the second voice, but it caused a segmentation fault in
LilyPond when it tries to merge multi measure rests from both voices.
The test file that shows this is attached. The include file is also
attached, it is the mergeRests.ly from the original message with the
example removed and convert-ly run on it to update it from 2.16.1 - the
resultant version reads 2.17.97 which I recall is a known bug.
I guess this part of the thread needs to switch to lilypond-devel or
lilypond-bug, now - I originally started this email just to enquire
about merging multi-measure rests ...
Richard
\version 2.18.0
\include merge-rests.ily
% The music follows
MvmntIVoiceI = {
\voiceOne a'2. r4
\set Score.skipBars = ##t R1*4/4*2 }
MvmntIVoiceII = {
\voiceTwo e'2. r4
\set Score.skipBars = ##t R1*4/4*2 }
%Default Score Layout
\score {
\new Staff
\new Voice = VoiceIMvmntI { \MvmntIVoiceI }
\new Voice = VoiceIIMvmntI { \MvmntIVoiceII }
\layout {
\mergeRests
}
}
\version 2.17.97
%%% merge rests
#(define (rest-score r)
(let ((score 0)
(yoff (ly:grob-property-data r 'Y-offset))
(sp (ly:grob-property-data r 'staff-position)))
(if (number? yoff)
(set! score (+ score 2))
(if (eq? yoff 'calculation-in-progress)
(set! score (- score 3
(and (number? sp)
(= 0 2 sp)
(set! score (+ score 2))
(set! score (- score (abs (- 1 sp)
score))
#(define (merge-rests-on-positioning grob)
(let* ((can-merge #f)
(elts (ly:grob-object grob 'elements))
(num-elts (and (ly:grob-array? elts)
(ly:grob-array-length elts)))
(two-voice? (= num-elts 2)))
(if two-voice?
(let* ((v1-grob (ly:grob-array-ref elts 0))
(v2-grob (ly:grob-array-ref elts 1))
(v1-rest (ly:grob-object v1-grob 'rest))
(v2-rest (ly:grob-object v2-grob 'rest)))
(and
(ly:grob? v1-rest)
(ly:grob? v2-rest)
(let* ((v1-duration-log (ly:grob-property v1-rest 'duration-log))
(v2-duration-log (ly:grob-property v2-rest 'duration-log))
(v1-dot (ly:grob-object v1-rest 'dot))
(v2-dot (ly:grob-object v2-rest 'dot))
(v1-dot-count (and (ly:grob? v1-dot)
(ly:grob-property v1-dot 'dot-count -1)))
(v2-dot-count (and (ly:grob? v2-dot)
(ly:grob-property v2-dot 'dot-count -1
(set! can-merge
(and
(number? v1-duration-log)
(number? v2-duration-log)
(= v1-duration-log v2-duration-log)
(eq? v1-dot-count v2-dot-count)))
(if can-merge
;; keep the rest that looks best:
(let* ((keep-v1? (= (rest-score v1-rest)
(rest-score v2-rest)))
(rest-to-keep (if keep-v1? v1-rest v2-rest))
(dot-to-kill (if keep-v1? v2-dot v1-dot)))
;; uncomment if you're curious of which rest was chosen:
;;(ly:grob-set-property! v1-rest 'color green)
;;(ly:grob-set-property! v2-rest 'color blue)
(ly:grob-suicide! (if keep-v1? v2-rest v1-rest))
(if (ly:grob? dot-to-kill)
(ly:grob-suicide! dot-to-kill))
(ly:grob-set-property! rest-to-keep 'direction 0)
(ly:rest::y-offset-callback rest-to-keep)))
(if can-merge
#t
(ly:rest-collision::calc-positioning-done grob
#(define merge-multi-measure-rests-on-Y-offset
;; Call this to get the 'Y-offset of a MultiMeasureRest.
;; It keeps track of other MultiMeasureRests in the same
NonMusicalPaperColumn
;; and StaffSymbol. If two are found, delete one and return 1 for Y-offset of
;; the other one.
(let ((table (make-weak-key-hash-table)))
(lambda (grob)
(let* ((ssymb (ly:grob-object grob 'staff-symbol))
(nmcol (ly:grob-parent grob X))
(ssymb-hash (or (hash-ref table ssymb)
(hash-set! table ssymb (make-hash-table
Re: Learn from Finale 2014 (seriously)?
Am 14.11.2013 12:03, schrieb SoundsFromSound: To be honest, the first thing my eyes went to was the tremolo notehead mess. That looks painful. The duplicate rests section didn't register with my brain until a few seconds later. I certainly prefer the 2014 look more with the merging, for sure, but my eyes didn't process that as standout focus point nearly as much as that tremolo did. Interesting. They noticed too ;-) http://www.finalemusic.com/blog/rolls-tremolos-jari-williamsson-and-finale-2014/ ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Learn from Finale 2014 (seriously)?
2013/11/20 Urs Liska u...@openlilylib.org: Am 14.11.2013 12:03, schrieb SoundsFromSound: To be honest, the first thing my eyes went to was the tremolo notehead mess. That looks painful. They noticed too ;-) http://www.finalemusic.com/blog/rolls-tremolos-jari-williamsson-and-finale-2014/ Fascinating - someone wrote code that fixes their crappy tremolos, and instead of incorporating this fix, they let it live as a plugin (which, by definition, won't be used by everyone). How miserable. Anyone wants to write a blog post about it? ;-) I'm too busy now. Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Learn from Finale 2014 (seriously)?
Janek Warchoł janek.lilyp...@gmail.com schrieb: 2013/11/20 Urs Liska u...@openlilylib.org: Am 14.11.2013 12:03, schrieb SoundsFromSound: To be honest, the first thing my eyes went to was the tremolo notehead mess. That looks painful. They noticed too ;-) http://www.finalemusic.com/blog/rolls-tremolos-jari-williamsson-and-finale-2014/ Fascinating - someone wrote code that fixes their crappy tremolos, and instead of incorporating this fix, they let it live as a plugin (which, by definition, won't be used by everyone). How miserable. Anyone wants to write a blog post about it? ;-) I'm too busy now. Janek Miserable, yes. But be careful pointing at others: you're replyig in the context of a thread about a missing LilyPond feature for which there's a halfway working solution in the LSR and a better one in the mailing list archives. How miserable. ;-) 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
Re: Learn from Finale 2014 (seriously)?
2013/11/20 Urs Liska u...@openlilylib.org: Janek Warchoł janek.lilyp...@gmail.com schrieb: 2013/11/20 Urs Liska u...@openlilylib.org: Am 14.11.2013 12:03, schrieb SoundsFromSound: To be honest, the first thing my eyes went to was the tremolo notehead mess. That looks painful. They noticed too ;-) http://www.finalemusic.com/blog/rolls-tremolos-jari-williamsson-and-finale-2014/ Fascinating - someone wrote code that fixes their crappy tremolos, and instead of incorporating this fix, they let it live as a plugin (which, by definition, won't be used by everyone). How miserable. Anyone wants to write a blog post about it? ;-) I'm too busy now. Miserable, yes. But be careful pointing at others: you're replyig in the context of a thread about a missing LilyPond feature for which there's a halfway working solution in the LSR and a better one in the mailing list archives. How miserable. ;-) Indeed, i've arrived at the exact same conclusion. Hmm Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Learn from Finale 2014 (seriously)?
Janek Warchoł janek.lilyp...@gmail.com writes: 2013/11/20 Urs Liska u...@openlilylib.org: Am 14.11.2013 12:03, schrieb SoundsFromSound: To be honest, the first thing my eyes went to was the tremolo notehead mess. That looks painful. They noticed too ;-) http://www.finalemusic.com/blog/rolls-tremolos-jari-williamsson-and-finale-2014/ Fascinating - someone wrote code that fixes their crappy tremolos, and instead of incorporating this fix, they let it live as a plugin (which, by definition, won't be used by everyone). How miserable. They might need a copyright assignment for that to be on the safe side, and the plugin might solve the problem at a location that does not make sense for the codebase proper. We have a whole lot of solutions for various problems in the LSR instead of LilyPond's codebase as well. Anyone wants to write a blog post about it? ;-) I'm too busy now. Well, I do find it amusing, but it's not like we are in a position to gloat regarding user contributions. The good thing is that power users/programmers can contribute to the _core_ and are not reduced to producing plugins. And a considerable part of the core is manageable via Scheme rather than C++ and does not require recompilation for munging LilyPond. At least we are getting our stem lengths consistently better (not just tremoli). The Finale stem lengths, also regarding beamed notes, looks rather consistently disproportionate when compared with actual engraved scores (not just in comparison to LilyPond). -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Learn from Finale 2014 (seriously)?
2013/11/20 David Kastrup d...@gnu.org: Janek Warchoł janek.lilyp...@gmail.com writes: 2013/11/20 Urs Liska u...@openlilylib.org: Am 14.11.2013 12:03, schrieb SoundsFromSound: To be honest, the first thing my eyes went to was the tremolo notehead mess. That looks painful. They noticed too ;-) http://www.finalemusic.com/blog/rolls-tremolos-jari-williamsson-and-finale-2014/ Fascinating - someone wrote code that fixes their crappy tremolos, and instead of incorporating this fix, they let it live as a plugin (which, by definition, won't be used by everyone). How miserable. They might need a copyright assignment for that to be on the safe side, and the plugin might solve the problem at a location that does not make sense for the codebase proper. We have a whole lot of solutions for various problems in the LSR instead of LilyPond's codebase as well. indeed, you're right. The good thing is that power users/programmers can contribute to the _core_ and are not reduced to producing plugins. And a considerable part of the core is manageable via Scheme rather than C++ and does not require recompilation for munging LilyPond. At least we are getting our stem lengths consistently better (not just tremoli). The Finale stem lengths, also regarding beamed notes, looks rather consistently disproportionate when compared with actual engraved scores (not just in comparison to LilyPond). true. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Learn from Finale 2014 (seriously)?
2013/11/15 Wilbert Berendsen wbs...@xs4all.nl:
Op Thu, 14 Nov 2013 09:52:06 +0100
Urs Liska u...@openlilylib.org schreef:
Hi all,
this has just appeared:
http://www.finalemusic.com/blog/quick-peeks-at-finale-2014-consolidate-rests/
and I think what they describe as inferior behaviour in Finale 2012
is (nearly) exactly what we have to do (OK, we don't have to manually
drag rests to an appropriate place but let LilyPond do this with
\oneVoice.
But I often have to do things like
{
\voiceOne d'4 \oneVoice r \voiceOne d'
}
\new Voice {
\voiceTwo d4 s d
}
which really is equivalent to the initial example of the Finale post.
Does anybody have an idea how one could improve this situation for
LilyPond?
https://github.com/wbsoft/lilymusic/blob/master/include/merge-rests.ily
--
Wilbert Berendsen
(http://www.wilbertberendsen.nl)
I'd prefer
http://www.mail-archive.com/lilypond-user@gnu.org/msg69703.html
Cheers,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Learn from Finale 2014 (seriously)?
It would be a great idea (although I haven't idea about the way to implement it into LilyPond). But I noticed how ugly the tremelo-notehead collision is, with Finale 2014 default settings ;-) Philippe -- View this message in context: http://lilypond.1069038.n5.nabble.com/Learn-from-Finale-2014-seriously-tp153908p153909.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: Learn from Finale 2014 (seriously)?
Hi Urs,
there is a snippet in LSR:
http://lsr.dsi.unimi.it/LSR/Item?id=336
which did this for a long time. To me it seems, that finale learned from
lilypond ;)
I adapted it and integrated it in my own always-to-load-extensions and
use it in all my choral transcriptions.
Best, Jan-Peter
Am 14.11.2013 09:52, schrieb Urs Liska:
Hi all,
this has just appeared:
http://www.finalemusic.com/blog/quick-peeks-at-finale-2014-consolidate-rests/
and I think what they describe as inferior behaviour in Finale 2012 is
(nearly) exactly what we have to do (OK, we don't have to manually drag
rests to an appropriate place but let LilyPond do this with \oneVoice.
But I often have to do things like
{
\voiceOne d'4 \oneVoice r \voiceOne d'
}
\new Voice {
\voiceTwo d4 s d
}
which really is equivalent to the initial example of the Finale post.
Does anybody have an idea how one could improve this situation for LilyPond?
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Learn from Finale 2014 (seriously)?
Am 14.11.2013 11:16, schrieb Jan-Peter Voigt: Hi Urs, there is a snippet in LSR: http://lsr.dsi.unimi.it/LSR/Item?id=336 which did this for a long time. To me it seems, that finale learned from lilypond ;) I adapted it and integrated it in my own always-to-load-extensions and use it in all my choral transcriptions. Best, Jan-Peter According to http://www.sibeliusblog.com/news/finale-2014-released/ most of Finale's new features are designed to offer functionality that largely compares with what has been possible in Sibelius for quite some time. That these features are now the chief selling points of Finale lends itself to various conclusions --- one of which is a recognition of the incredible talent that Avid lost when they downsized and eventually fired its London-based developers last year. ;-) Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Learn from Finale 2014 (seriously)?
Am 14.11.2013 11:08, schrieb Karl Hammar: Urs Liska: Does anybody have an idea how one could improve this situation for LilyPond? You have to be more specific, what is it you want ? I'm not wanting anything specific, just raise this issue. It seems that there already _is_ a solution, so everything is fine :-) If you want to merge rests, have a look at: http://turkos.aspodata.se/git/musik/CamilleSaintSa%C3%ABns/oratorio_de_noel/04_air.ly Will do ASAP. Thanks Urs Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ 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: Learn from Finale 2014 (seriously)?
To be honest, the first thing my eyes went to was the tremolo notehead mess. That looks painful. The duplicate rests section didn't register with my brain until a few seconds later. I certainly prefer the 2014 look more with the merging, for sure, but my eyes didn't process that as standout focus point nearly as much as that tremolo did. Interesting. flup2 wrote It would be a great idea (although I haven't idea about the way to implement it into LilyPond). But I noticed how ugly the tremelo-notehead collision is, with Finale 2014 default settings ;-) Philippe - composer | sound designer LilyPond Tutorials (for beginners) -- http://bit.ly/bcl-lilypond -- View this message in context: http://lilypond.1069038.n5.nabble.com/Learn-from-Finale-2014-seriously-tp153908p153918.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: Learn from Finale 2014 (seriously)?
Urs Liska u...@openlilylib.org writes:
But I often have to do things like
{
\voiceOne d'4 \oneVoice r \voiceOne d'
}
\new Voice {
\voiceTwo d4 s d
}
For this purpose I once wrote a function:
\dual {
g'4 \rr4 g'
} {
d'4 s d'
}
-- Johan
rr =
#(define-music-function
(parser location dur)
(ly:duration?)
#{ \oneVoice #(make-music 'RestEvent 'duration dur) \voiceOne #}
)
dual =
#(define-music-function
(parser location one two)
(ly:music? ly:music?)
#{ { \voiceOne #one }
\new Voice { \voiceTwo #two }
\oneVoice
#}
)
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Learn from Finale 2014 (seriously)?
On 14/11/13 11:16, Jan-Peter Voigt wrote: there is a snippet in LSR: http://lsr.dsi.unimi.it/LSR/Item?id=336 which did this for a long time. Please note that multi-measure rests are not automatically combined. In addition, it hardly matches the ease of the Sibelius/Finale features if the user has to copy-paste a bunch of Scheme code into their project to achieve the desired result. I'm not trying to bash anyone's work, just to note that when comparing to other projects, one should not focus on who did it first, one should focus on who does it best -- and how to match that best performance. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Learn from Finale 2014 (seriously)?
Johan Vromans jvrom...@squirrel.nl writes:
For this purpose I once wrote a function:
rr =
#(define-music-function
(parser location dur)
(ly:duration?)
#{ \oneVoice #(make-music 'RestEvent 'duration dur) \voiceOne #}
)
rr =
#(define-music-function
(parser location dur)
(ly:duration?)
#{ \tweak direction #CENTER r$dur #})
would seem saner.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Learn from Finale 2014 (seriously)?
Hi Joseph, Am 14.11.2013 14:45, schrieb Joseph Rushton Wakeling: Please note that multi-measure rests are not automatically combined. there is an update of this snippet in the mail archives and I will post my version later. In addition, it hardly matches the ease of the Sibelius/Finale features if the user has to copy-paste a bunch of Scheme code into their project to achieve the desired result. You're right, but I would take this as a proposal to add this as a standard command to lily. I'm not trying to bash anyone's work, just to note that when comparing to other projects, one should not focus on who did it first, one should focus on who does it best -- and how to match that best performance. One can always compare, who does it best. But IMO the metric of doing it good,better,best is not a one-dimensional one. Cheers, Jan-Peter ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Learn from Finale 2014 (seriously)?
On 14/11/13 15:05, Jan-Peter Voigt wrote: there is an update of this snippet in the mail archives and I will post my version later. Fantastic, thank you! :-) You're right, but I would take this as a proposal to add this as a standard command to lily. Yes, I agree. In fact for optimal usability, I think it should be an on-by-default feature, as the most likely use-case for voices sharing a staff is for the rests to be combined where possible. One can always compare, who does it best. But IMO the metric of doing it good,better,best is not a one-dimensional one. Oh, sure. It's just that I get uncomfortable whenever I see people respond to news of a good feature in another piece of software with remarks along the lines of, Hey, but we do [other feature] better or Hey, you can already do that by [complicated method that's much harder than the other software]. I think that it's always very important to try and understand why people see value in other software, and what things it provides that one's own tools don't. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Learn from Finale 2014 (seriously)?
David Kastrup d...@gnu.org writes:
rr =
#(define-music-function
(parser location dur)
(ly:duration?)
#{ \tweak direction #CENTER r$dur #})
would seem saner.
Thanks for the suggestion. I needed
#{ \tweak #'direction #'CENTER r$dur #})
but it sure looks nice(r).
Do you know how to make the duration optional?
-- Johan
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Learn from Finale 2014 (seriously)?
Johan Vromans jvrom...@squirrel.nl writes:
David Kastrup d...@gnu.org writes:
rr =
#(define-music-function
(parser location dur)
(ly:duration?)
#{ \tweak direction #CENTER r$dur #})
would seem saner.
Thanks for the suggestion. I needed
#{ \tweak #'direction #'CENTER r$dur #})
but it sure looks nice(r).
Do you know how to make the duration optional?
Not worth it. Optional arguments at the end of the argument list can
only be skipped using \default, and writing
\rr \default
would not really save effort.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Learn from Finale 2014 (seriously)?
I've always used Phil's solution (manually placing one rest and using s for the other), but, come to think of it, it would be nice for this to be done automatically. -- View this message in context: http://lilypond.1069038.n5.nabble.com/Learn-from-Finale-2014-seriously-tp153908p153952.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: Learn from Finale 2014 (seriously)?
2013/11/14 Michael Rivers michaeljriv...@gmail.com I've always used Phil's solution (manually placing one rest and using s for the other), but, come to think of it, it would be nice for this to be done automatically. After typing a full orchestral movement and solving the merge problem with just one copy + paste and a \include command, I must agree. Awesome snippet! I will try the updated one latter.I also named the file mergeRests.ly! lol Caio ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Learn from Finale 2014 (seriously)?
Am 2013-11-14 um 23:26 schrieb Phil Burfitt phil.burf...@talktalk.net: I may be stating the obvious...but I've always used b4\rest (or whatever note position you want the rest) in one voice and s4 in the other voices. Not that elegant, but simple. But doesn’t that play the b4 in MIDI? Greetlings, Hraban --- fiëé visuëlle Henning Hraban Ramm http://www.fiee.net http://angerweit.tikon.ch/lieder/ https://www.cacert.org (I'm an assurer) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Learn from Finale 2014 (seriously)?
Henning Hraban Ramm lilypon...@fiee.net writes: Am 2013-11-14 um 23:26 schrieb Phil Burfitt phil.burf...@talktalk.net: I may be stating the obvious...but I've always used b4\rest (or whatever note position you want the rest) in one voice and s4 in the other voices. Not that elegant, but simple. But doesn’t that play the b4 in MIDI? No. Pitched rests are silent. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Learn from Finale 2014 (seriously)?
Op Thu, 14 Nov 2013 09:52:06 +0100
Urs Liska u...@openlilylib.org schreef:
Hi all,
this has just appeared:
http://www.finalemusic.com/blog/quick-peeks-at-finale-2014-consolidate-rests/
and I think what they describe as inferior behaviour in Finale 2012
is (nearly) exactly what we have to do (OK, we don't have to manually
drag rests to an appropriate place but let LilyPond do this with
\oneVoice.
But I often have to do things like
{
\voiceOne d'4 \oneVoice r \voiceOne d'
}
\new Voice {
\voiceTwo d4 s d
}
which really is equivalent to the initial example of the Finale post.
Does anybody have an idea how one could improve this situation for
LilyPond?
https://github.com/wbsoft/lilymusic/blob/master/include/merge-rests.ily
--
Wilbert Berendsen
(http://www.wilbertberendsen.nl)
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
