Choises
Hello everybody out there!
I must write a score for several instruments. In this score, interprets
must several times choose between two alternatives. To symbolize these
choices, the staff is split in two, every staff being linked to the
other with an opening angle bracket (“<”). At the beginning of a new
line, staffs are also linked with an angle opening bracket. The end of
alternative is symbolized with a closing angle bracket (“>”). I have
created a hand-made example (without notes) you can see here:
https://cloud.le-bars.net/index.php/s/zIIqGlcSa3XCdi4
I am quite certain it can be done with Lilypond, but I do not have a
clue how to do it. Therefore, I have prepared some code available here:
http://lilybin.com/tjc9ai/3
I have also copied this code at the end of this message.
There are two instruments in this example, a flute and a clarinet
(clarinet is written in French, i.e. “clarinette”, in variable names).
For this two instruments, there is four section A, B, C and D. In
section B and C, they have two choices: Ba and Bb as well as Ca and Cb.
Therefore, fluteBa must be superposed over fluteBb, as well as fluteCa
over fluteCb, clarinetteBa over clarinetteBb and clarinetteCa over
clarinetteCb in the way presented in my hand-made example.
Well, I hope this is understandable. Does anyone have an idea how to do
this?
Best regards.
\version "2.18.2"
#(define (chiffr-triche grob)
(grob-interpret-markup grob
(markup #:override '(baseline-skip . 0)
(#:line ((#:center-column (#:number "9" #:number "8")))
\paper {
indent = 3\cm
short-indent = 1.5\cm
}
\layout {
\context {
\Score
\remove "Timing_translator"
\remove "Default_bar_line_engraver"
}
\context {
\Staff \RemoveEmptyStaves
\consists "Timing_translator"
\consists "Default_bar_line_engraver"
}
}
fluteA = {
\time 4/4
\relative c' {
\repeat unfold 12 {c8 d e f}
}
}
fluteBa = {
\bar "||"
\once \override Staff.TimeSignature.stencil = #chiffr-triche
\time 3/4
\relative c' {
\repeat unfold 12 {c8*2/3[d e]}
}
}
fluteBb = {
\bar "||"
\once \override Staff.TimeSignature.stencil = #chiffr-triche
\time 3/4
\relative c' {
\repeat unfold 12 {e8*2/3[d c]}
}
}
fluteCa = {
\bar "||"
\time 4/4
\relative c' {
\repeat unfold 12 {c8 d e f}
}
}
fluteCb = {
\bar "||"
\time 4/4
\relative c' {
%f8 e d c \bar "" \break
\repeat unfold 12 {f8 e d c}
}
}
fluteD = {
\relative c' {
c8 d e f e d c4~ c1 \bar "|."
}
}
clarinetteA = {
\time 4/4
\relative c' {
\repeat unfold 16 {e8 f g a}
}
}
clarinetteBa = {
\bar "||"
\once \override Staff.TimeSignature.stencil = #chiffr-triche
\time 3/4
\relative c' {
e8*2/3[f g] \bar "" \break
\repeat unfold 11 {e[f g]}
}
}
clarinetteBb = {
\bar "||"
\once \override Staff.TimeSignature.stencil = #chiffr-triche
\time 3/4
\relative c' {
g'8*2/3[f e] \bar "" \break
\repeat unfold 11 {g[f e]}
}
}
clarinetteCa = {
\bar "||"
\time 4/4
\relative c' {
\repeat unfold 8 {a'8 g f e}
}
}
clarinetteCb = {
\bar "||"
\time 4/4
\relative c' {
\repeat unfold 8 {e8 f g a}
}
}
clarinetteD = {
\relative c' {
f8 g a b a g f4~ f1 \bar "|."
}
}
\score {
<<
\accidentalStyle Score.modern-cautionary
\new Staff \with {
instrumentName = #"Flûte"
shortInstrumentName = #"Fl."
}
{
\fluteA
\fluteBa
\fluteCa
\fluteD
}
\new Staff \with {
instrumentName = \markup {\concat {"Clarinette en Si" \flat}}
shortInstrumentName = \markup {\concat {"Clar. Si" \flat}}
}
{
\clarinetteA
\clarinetteBa
\clarinetteCa
\clarinetteD
}
>>
}
--
Yoann LE BARS
http://le-bars.net/yoann/
Diaspora* : yleb...@framasphere.org
Scheme function to return pitchnames as markup/text
Though I remain baffled by Scheme and its use in LilyPond, my hope is to
build one or more functions/procedures that would transpose input music
and for each chord display the transposed chord's note names, with
control over the way the names are represented (as in Cb or F# instead
of ces and fis).
Here, I'm just asking for help with one part of the function-to-be: how
to turn notes in LilyPond music into note names as text (schematic of
the complete imagined function below).
Here's what I've tried so far, in LilyPond 2.19.8x, based closely on
working procedures found on this list. Once this is running right for
single notes I'll (hope to) get it to loop through all input music.
#(define-scheme-function
(pitchin)
(ly:music?)
(let* (
(note-datum (car (ly:music-property pitchin 'elements)))
(pitch-datum (ly:music-property note-datum 'pitch))
(out-notename (ly:pitch-notename pitch-datum)))
#{ \markup
\bold
$out-notename
#}
))
I get "syntax error, unexpected NUMBER_IDENTIFIER" on the $out-notename
line when calling notenamer with a note wrapped in braces, as in:
\notenamer {a}
Without the braces around the music, the error is "In procedure car in
expression (car (ly:music-property pitchin #)):Wrong type (expecting
pair): ()
Results are the same if I do "define-music-function" instead of
"define-scheme-function."
Many thanks for your attention and help,
Steve
PS: I have a working NoteNames reformatter but it seems to require
listing in a substitution table the specific notes of each and every
chord in each transposition. A custom function would allow display of
the chord note names in a columnar stack so if these markups were used
as text scripts they wouldn't either take too much space or collide with
the names of adjacent notes. Alternatively, chord note names could be
placed beneath ChordNames.
Re: Set a temporary tempo change
Am Di., 19. Nov. 2019 um 01:19 Uhr schrieb Aaron Hill : > > On 2019-11-18 1:44 pm, Thomas Morley wrote: > > why wrap it into a music-function? > > Only advantage seems to avoid a toplevel-definiton. Is it really an > > advantage? > > It's an advantage for \popTempo as it means *location* is properly set > to the use of \popTempo and not its definition. > > Mind you, \pushTempo need not be a function. Ok, I've overlooked that. Cheers, Harm
Re: Problem on the dynamics of the midi output
Thanks. One more question: is it possible to associate both the dynamics of
the upper and lower staves to the same voice without the "\new Dynamics {...}"
token?
For example, if I have:
\new PianoStaff << \new Staff="up" { c'4 c' r r }
\new Staff="down" { r4\ppp r c'\fff c' } >>
I would like to display "ppp" below the rest on the lower staff, but apply it
to c'4 in the midi output of the upper staff too. In other terms: a "global"
dynamics line with dynamics that affect both the staves and that I can choose
to place below the upper or the lower one.
ThanksIl lunedì 18 novembre 2019, 22:01:00 CET, Thomas Morley
ha scritto:
Am Mo., 18. Nov. 2019 um 02:37 Uhr schrieb Paolo Prete :
>
> Hello.
>
> I can't find a way to have a single sequence of dynamics that affects both
> upper and lower piano staves in the MIDI output.
> I tried the following snippet but I can't hear any variation of the dynamics
> in the midi file.
>
> %%%
>
> \score {
> <<
> \new PianoStaff <<
> \new Staff="up" { c'4 c' r r }
> \new Dynamics { s4\fff s s\ppp s}
> \new Staff="down" { r4 r c' c' }
> >>
> >>
> \layout { }
> \midi { }
\midi {
\context {
\Staff
\consists "Dynamic_performer"
}
}
> }
>
> %
Cheers,
Harm
Re: Set a temporary tempo change
On 2019-11-18 4:18 pm, Aaron Hill wrote: registerContextProperty = #(define-void-function (symbol type? description) (symbol? procedure? string?) (if (not (equal? #f (object-property symbol 'translation-doc))) (ly:error (_ "symbol ~S redefined") symbol)) (set-object-property! symbol 'translation-type? type?) (set-object-property! symbol 'translation-doc description) (set! all-translation-properties (cons symbol all-translation-properties)) symbol) And the useless return value should be omitted. registerContextProperty = #(define-void-function (symbol type? description) (symbol? procedure? string?) (if (not (equal? #f (object-property symbol 'translation-doc))) (ly:error (_ "symbol ~S redefined") symbol)) (set-object-property! symbol 'translation-type? type?) (set-object-property! symbol 'translation-doc description) (set! all-translation-properties (cons symbol all-translation-properties))) -- Aaron Hill
Re: Set a temporary tempo change
On 2019-11-18 1:44 pm, Thomas Morley wrote:
why wrap it into a music-function?
Only advantage seems to avoid a toplevel-definiton. Is it really an
advantage?
It's an advantage for \popTempo as it means *location* is properly set
to the use of \popTempo and not its definition.
Mind you, \pushTempo need not be a function.
You omitted throwing the error about redefining existing ones...
Feels safer to have it, but that's just me.
Certainly, there should be safer handling. How's this:
\version "2.19.83"
registerContextProperty = #(define-void-function
(symbol type? description)
(symbol? procedure? string?)
(if (not (equal? #f (object-property symbol 'translation-doc)))
(ly:error (_ "symbol ~S redefined") symbol))
(set-object-property! symbol 'translation-type? type?)
(set-object-property! symbol 'translation-doc description)
(set! all-translation-properties (cons symbol
all-translation-properties))
symbol)
#(define (false-or-moment? x) (or (equal? #f x) (ly:moment? x)))
#(define (false-or-moment-list? x) (and (list? x) (every
false-or-moment? x)))
\registerContextProperty tempoStack #false-or-moment-list?
"A stack to keep track of tempi."
pushTempo = { \context Score \applyContext #(lambda (ctx)
(let ((tempoStack (ly:context-property ctx 'tempoStack))
(tempo (ly:context-property ctx 'tempoWholesPerMinute #f)))
(ly:context-set-property! ctx 'tempoStack (cons tempo tempoStack
}
popTempo = #(define-music-function () ()
#{ \context Score \applyContext #(lambda (ctx)
(let ((tempoStack (ly:context-property ctx 'tempoStack)))
(if (null? tempoStack)
(ly:input-warning (*location*)
(_ "Tempo stack is empty. Did you forget to \\pushTempo?"))
(let ((tempo (car tempoStack)))
(ly:context-set-property! ctx 'tempoStack (cdr tempoStack))
(if (equal? #f tempo)
(ly:context-unset-property ctx 'tempoWholesPerMinute)
(ly:context-set-property! ctx 'tempoWholesPerMinute
tempo)) #})
\score {
{
\markLengthOn
\tempo "I. Default"
{ b'4 4 4 4 } \bar "||"
\pushTempo \tempo "II. Andante" 4=90
{ b'4 4 4 4 } \bar "||"
\pushTempo \tempo "III. Allegro" 4=140
{ b'4 4 4 4 } \bar "||"
\popTempo \tempo "Tempo II"
{ b'4 4 4 4 } \bar "||"
\popTempo \tempo "Tempo I"
{ b'4 4 4 4 } \bar "|."
}
\layout {} \midi {}
}
-- Aaron Hill
Re: Mac OS 10.15 Catalina (fonts)
On Tue, 19 Nov 2019 at 00:54, Flaming Hakama by Elaine < ela...@flaminghakama.com> wrote: > >> From: Aaron Hill >> To: lilypond-user@gnu.org >> >> Date: Sun, 17 Nov 2019 21:04:07 -0800 >> Subject: Re: Mac OS 10.15 Catalina (fonts) >> On 2019-11-17 8:50 pm, Tim McNamara wrote: >> > The default Catalina shell is zsh. You can use bash but you may have >> > to set it to that. >> >> Scripts should generally begin with an appropriate "shebang" to avoid >> confusion: >> >> #!/usr/bin/env bash >> >> I, for instance, run fish in my WSL environment, but I script almost >> exclusively in bash. >> >> >> -- Aaron Hill > > > Correct, one has to install bash on the newest mac OS Catalina. > Catalina includes the same shells as earlier versions of macOS; bash, tcsh, csh, sh, zsh, and ksh. The only difference is that the default has changed to zsh. You can set desired shell per user in Users & Groups / Advanced Options. All shells are located in /bin/ and can be used in a shebang as required. -- Sven Axelsson ++[>++>+++>++>++ ><-]>.+..>+.>+.<<-.>>+.>.<<. +++.>-.<<++.>>.<++.>>>++..>>.<.
Re: Mac OS 10.15 Catalina (fonts)
>
>
> From: Aaron Hill
> To: lilypond-user@gnu.org
>
> Date: Sun, 17 Nov 2019 21:04:07 -0800
> Subject: Re: Mac OS 10.15 Catalina (fonts)
> On 2019-11-17 8:50 pm, Tim McNamara wrote:
> > The default Catalina shell is zsh. You can use bash but you may have
> > to set it to that.
>
> Scripts should generally begin with an appropriate "shebang" to avoid
> confusion:
>
> #!/usr/bin/env bash
>
> I, for instance, run fish in my WSL environment, but I script almost
> exclusively in bash.
>
>
> -- Aaron Hill
Correct, one has to install bash on the newest mac OS Catalina.
So, if I expected help from anyone on this list, choosing that shell was a
poor decision.
And I should have included a shebang to be clearer in this example,
in which case the most up-to-date version through homebrew is
#!/usr/local/bin/bash
In any case, the point being that the script creates many examples, some of
which succeed, and some of which fail.
Here is one that succeeds as-is, changing the DynamicText.
But if you uncomment either the Script or NoteHead lines, it fails.
\version "2.19.83"
#(define-public (add-notation-font fontnode name music-str brace-str factor)
(begin
(add-music-fonts fontnode
name music-str brace-str
feta-design-size-mapping factor)
fontnode))
\paper {
#(define notation-fonts
(list
(list 'beethoven "beethoven" "beethoven")
))
#(begin
(for-each
(lambda (tup)
(add-notation-font fonts
(car tup) ; font identifier
(cadr tup) ; notation font
(caddr tup) ; brace font
(/ staff-height pt 20)))
notation-fonts))
}
\layout {
% This one works (for articulations)
\override DynamicText #'font-family = #'beethoven
% Uncomment either of these, and it fails
%\override Script #'font-family = #'beethoven
%\override NoteHead #'font-family = #'beethoven
}
\relative c' { c2.\pp \< d4--\p | e2.->\mf f4->\ff }
Thanks,
Elaine Alt
415 . 341 .4954 "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re: Bug on MIDI dynamics
Thanks Thomas. Your note fixed all.
I found the per-voice association casually, then I even googled "lilypond
dynamics per-voice" but could not find anything specific for 2.19: then,
without your suggestion, given that this default behaviour is not documented
and the official snippets use another default behaviour, it seemed a bug.
Il lunedì 18 novembre 2019, 22:09:49 CET, Thomas Morley
ha scritto:
Am Mo., 18. Nov. 2019 um 17:00 Uhr schrieb Paolo Prete :
>
> Hello,
>
> Regarding my previous question,
Please link to it.
> I just checked that there's a bug on the dynamics of the produced midi output
> for a piano staff.
> The bug can be reproduced on the 2.19 version. Please, check this snippet (
> from http://lsr.di.unimi.it/LSR/Item?id=357 ), with Lilybin
>
> http://lilybin.com/eg700v/1
>
>
> The same error doesn't occur if you compile the snippet with 2.18 version.
>
> 1) Is there a workaround for that?
> 2) Is there a particular version of the 2.19 branch that doesn't cause the
> bug?
>
> Thanks
> Paolo
I don't see any bug- nor error-description...
Dynamics are associated per Voice since 2.19.x.
In a Dynamics-context usually spacers are used, so it's pure graphic.
The voice-association seems to be a reasonable default.
If you want it different, add the "Dynamic_performer" to the context
of your choice in \midi {}
Probably a documentation-issue.
Cheers,
Harm
Re: Problem on the dynamics of the midi output
On Mon, Nov 18, 2019 at 1:00 PM Thomas Morley wrote:
>
> Am Mo., 18. Nov. 2019 um 02:37 Uhr schrieb Paolo Prete :
> >
> > Hello.
> >
> > I can't find a way to have a single sequence of dynamics that affects both
> > upper and lower piano staves in the MIDI output.
> > I tried the following snippet but I can't hear any variation of the
> > dynamics in the midi file.
> >
> > %%%
> >
> > \score {
> > <<
> >\new PianoStaff <<
> > \new Staff="up" { c'4 c' r r }
> > \new Dynamics { s4\fff s s\ppp s}
> > \new Staff="down" { r4 r c' c' }
> >>>
> > >>
> > \layout { }
> > \midi { }
>
>
> \midi {
> \context {
> \Staff
> \consists "Dynamic_performer"
> }
> }
>
> > }
> >
> > %
Works like a charm, thanks! Although I can now see why someone would
want the dynamics to map to velocity instead of volume.
Re: acciaccatura & mis-predicted
Thank you Jacques and Harm for your help. I will try to use the previous version. Best regards g.
Re: Flared hairpin flare
Am Mo., 18. Nov. 2019 um 07:08 Uhr schrieb Andrew Bernard
:
>
> Aaron.
>
> Thanks so much. I'll look into this. It will certainly be very helpful
> to me. But I realized it's simple enough to just say:
>
> %
>
> {
>\override Hairpin.stencil = #(elbowed-hairpin '((0 . 2) (0.01 .
> 0.6) (1 . 0)) #t)
> c''4^\> \repeat unfold 18 { c'' } c''\!
> }
>
> %
>
> I have a question - this seems to only work for hairpins one way, and
> so I have to change the hairpin direction to get what I what. I'm
> missing some point?
>
> Andrew
>
Hi Andrew,
the "type-model" for entering the values is a _crescendo_-hairpin.(*)
Though, you define (0 . 2) as first, (1 . 0) as last value of the thus
you a "revesed" Hairpin.
Likely you should enter '((0 . 0) (0.99 . 0.6) (1 . 2)) there.
(*) This is not mentioned anywhere :(
Should be added to the doc-string of ´elbowed-hairpin´ at least.
Cheers,
Harm
Re: Set a temporary tempo change
Am Mo., 18. Nov. 2019 um 16:55 Uhr schrieb Aaron Hill
:
>
> On 2019-11-18 6:24 am, David Kastrup wrote:
> > Aaron Hill writes:
> >> Not sure if this is really the right way to do things:
> >
> > It isn't. It maintains the "stack" in a global variable rather than
> > some context property, meaning that when several iterations interlock
> > (like with tempo being changed in several contexts or in polyrhythmic
> > situations), chaos will ensue.
>
> Ah... you're no fun. To misquote Willy Wonka, "A little [chaos] now and
> then is relished by the wisest men." (:
>
> But seriously, I was imagining only the simplest use case. So, here's
> yet again another take:
>
>
> \version "2.19.83"
>
> #(begin
>(set-object-property! 'tempoStack 'translation-type? list?)
>(set-object-property! 'tempoStack 'translation-doc
> "A stack to keep track of previous tempi.")
>(set! all-translation-properties
> (cons 'tempoStack all-translation-properties)))
>
> pushTempo = #(define-music-function () ()
Hi Aaron,
why wrap it into a music-function?
Only advantage seems to avoid a toplevel-definiton. Is it really an advantage?
Same for popTempo.
Cheers,
Harm
>(define (pushTempoHelper ctx)
> (let ((tempoStack (ly:context-property ctx 'tempoStack '()))
>(tempo (ly:context-property ctx 'tempoWholesPerMinute #f)))
>(set! tempoStack (cons tempo tempoStack))
>(ly:context-set-property! ctx 'tempoStack tempoStack)))
>#{ \context Score \applyContext $pushTempoHelper #})
> popTempo = #(define-music-function () ()
>(define (popTempoHelper ctx)
> (let ((tempoStack (ly:context-property ctx 'tempoStack '(
>(if (null? tempoStack)
> (ly:input-warning (*location*)
>"Unable to pop a tempo. Did you forget to \\pushTempo?")
> (let ((tempo (car tempoStack)))
>(set! tempoStack (cdr tempoStack))
>(ly:context-set-property! ctx 'tempoStack tempoStack)
>(if tempo
> (ly:context-set-property! ctx 'tempoWholesPerMinute tempo)
> (ly:context-unset-property ctx 'tempoWholesPerMinute))
>#{ \context Score \applyContext $popTempoHelper #})
>
> \score {
>{
> \markLengthOn
> \tempo "I. Default"
> { b'4 4 4 4 } \bar "||"
> \pushTempo \tempo "II. Andante" 4=90
> { b'4 4 4 4 } \bar "||"
> \pushTempo \tempo "III. Allegro" 4=140
> { b'4 4 4 4 } \bar "||"
> \popTempo \tempo "Tempo II"
> { b'4 4 4 4 } \bar "||"
> \popTempo \tempo "Tempo I"
> { b'4 4 4 4 } \bar "||"
> \popTempo \tempo "Tempo 0?!"
> { b'4 4 4 4 } \bar "|."
>}
>\layout {} \midi {}
> }
>
>
> I tried to follow the pattern in define-context-properties.scm, but
> there is no documentation in LM, NR, Extending nor Internals on this
> topic. David, would you kindly let me know if I am overlooking
> something?
Well, I'm not David ;)
You omitted throwing the error about redefining existing ones...
Feels safer to have it, but that's just me.
Cheers,
Harm
Re: acciaccatura & mis-predicted
Am Mo., 18. Nov. 2019 um 15:04 Uhr schrieb Gianmaria Lari
:
>
> I'm sure this is a trivial issue but I need help to understand why this
> code...
>
> \version "2.21.0"
> {
> \acciaccatura cis'8 d'1
> \acciaccatura cis'8 d'1
> }
>
>
> ... generates this log:
>
> []
>
> programming error: mis-predicted force, 108.120472 ~= 108.620856
>
> continuing, cross fingers
>
> programming error: mis-predicted force, 108.120472 ~= 108.620856
>
> continuing, cross fingers
>
> []
>
>
>
> The same code in lower octaves works correctly. For instance this one
>
>
> \version "2.21.0"
>
> {
>
> \acciaccatura cis8 d'1
>
> \acciaccatura cis8 d'1
>
> }
>
>
> ...works without generating errors. Any help?
>
> Apologies if I'm missing something obvious!
>
>
> Thank you, g.
As far as I can tell, this is a windows-only issue, never occurring on Linux.
Thus I can't help. You may want to search the archives, though, maybe
someone found a workaround.
Probably it's caused by the same problem analyized here:
https://lists.gnu.org/archive/html/lilypond-devel/2019-10/msg00266.html
Though, it will not help you much, I guess...
Cheers,
Harm
Re: Bug on MIDI dynamics
Am Mo., 18. Nov. 2019 um 17:00 Uhr schrieb Paolo Prete :
>
> Hello,
>
> Regarding my previous question,
Please link to it.
> I just checked that there's a bug on the dynamics of the produced midi output
> for a piano staff.
> The bug can be reproduced on the 2.19 version. Please, check this snippet (
> from http://lsr.di.unimi.it/LSR/Item?id=357 ), with Lilybin
>
> http://lilybin.com/eg700v/1
>
>
> The same error doesn't occur if you compile the snippet with 2.18 version.
>
> 1) Is there a workaround for that?
> 2) Is there a particular version of the 2.19 branch that doesn't cause the
> bug?
>
> Thanks
> Paolo
I don't see any bug- nor error-description...
Dynamics are associated per Voice since 2.19.x.
In a Dynamics-context usually spacers are used, so it's pure graphic.
The voice-association seems to be a reasonable default.
If you want it different, add the "Dynamic_performer" to the context
of your choice in \midi {}
Probably a documentation-issue.
Cheers,
Harm
Re: Problem on the dynamics of the midi output
Am Mo., 18. Nov. 2019 um 02:37 Uhr schrieb Paolo Prete :
>
> Hello.
>
> I can't find a way to have a single sequence of dynamics that affects both
> upper and lower piano staves in the MIDI output.
> I tried the following snippet but I can't hear any variation of the dynamics
> in the midi file.
>
> %%%
>
> \score {
> <<
>\new PianoStaff <<
> \new Staff="up" { c'4 c' r r }
> \new Dynamics { s4\fff s s\ppp s}
> \new Staff="down" { r4 r c' c' }
>>>
> >>
> \layout { }
> \midi { }
\midi {
\context {
\Staff
\consists "Dynamic_performer"
}
}
> }
>
> %
Cheers,
Harm
Re: Problem on the dynamics of the midi output
On Sun, Nov 17, 2019 at 5:36 PM Paolo Prete wrote:
>
> Hello.
>
> I can't find a way to have a single sequence of dynamics that affects both
> upper and lower piano staves in the MIDI output.
> I tried the following snippet but I can't hear any variation of the dynamics
> in the midi file.
>
> %%%
>
> \score {
> <<
>\new PianoStaff <<
> \new Staff="up" { c'4 c' r r }
> \new Dynamics { s4\fff s s\ppp s}
> \new Staff="down" { r4 r c' c' }
>>>
> >>
> \layout { }
> \midi { }
> }
>
> %
>
> In addition, I wonder if is there a way to obtain the same result without
> having to add a "Dynamics" separate context...
>
> thanks
Well I thought this would work, but evidently not.
%%% Begin
\version "2.19.83"
notesUp = { c'4 c' r r }
notesDown = { r4 r c' c' }
dynamics = { s4\fff s s\ppp s}
\score {
<<
\new PianoStaff <<
\new Staff="up" \notesUp
\new Dynamics \dynamics
\new Staff="down" \notesDown
>>
>>
\layout { }
}
\score {
<<
\new Staff = "up" << \notesUp \dynamics >>
\new Staff = "down" << \notesDown \dynamics >>
>>
\midi { }
}
%%% End
---
Knute Snortum
(via Gmail)
Re: Bug on MIDI dynamics
It appears to happen because the 2.19 version seems to associate the MIDI output per-voice instead of per-staff. As a (ugly) workaround I used this (setting and soon after unsetting a voice): LilyPond Score | | | | LilyPond Score LilyPond Score made using LilyBin. | | | It works, but I wonder if is there something better for fixing the problem, even as a workaround... Il lunedì 18 novembre 2019, 17:00:36 CET, Paolo Prete ha scritto: Hello, Regarding my previous question, I just checked that there's a bug on the dynamics of the produced midi output for a piano staff.The bug can be reproduced on the 2.19 version. Please, check this snippet ( from http://lsr.di.unimi.it/LSR/Item?id=357 ), with Lilybin http://lilybin.com/eg700v/1 The same error doesn't occur if you compile the snippet with 2.18 version. 1) Is there a workaround for that?2) Is there a particular version of the 2.19 branch that doesn't cause the bug? ThanksPaolo
Bug on MIDI dynamics
Hello, Regarding my previous question, I just checked that there's a bug on the dynamics of the produced midi output for a piano staff.The bug can be reproduced on the 2.19 version. Please, check this snippet ( from http://lsr.di.unimi.it/LSR/Item?id=357 ), with Lilybin http://lilybin.com/eg700v/1 The same error doesn't occur if you compile the snippet with 2.18 version. 1) Is there a workaround for that?2) Is there a particular version of the 2.19 branch that doesn't cause the bug? ThanksPaolo
Re: acciaccatura & mis-predicted
First example runs fine with 2.19.83:
Starting lilypond 2.19.83 [Untitled]...
Processing
`/var/folders/jc/xrpy67_x6_vcjfzpzds_9_6mgn/T/frescobaldi-26x60_kc/tmpajvkw5n9/document.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to
`/var/folders/jc/xrpy67_x6_vcjfzpzds_9_6mgn/T//lilypond-dkJh6X'...
Converting to `document.pdf'...
Deleting `/var/folders/jc/xrpy67_x6_vcjfzpzds_9_6mgn/T//lilypond-dkJh6X'...
Success: compilation successfully completed
Completed successfully in 0.7".
JM
> Le 18 nov. 2019 à 15:02, Gianmaria Lari a écrit :
>
> I'm sure this is a trivial issue but I need help to understand why this
> code...
>
> \version "2.21.0"
> {
> \acciaccatura cis'8 d'1
> \acciaccatura cis'8 d'1
> }
>
> ... generates this log:
>
> []
> programming error: mis-predicted force, 108.120472 ~= 108.620856
> continuing, cross fingers
> programming error: mis-predicted force, 108.120472 ~= 108.620856
> continuing, cross fingers
> []
>
>
>
> The same code in lower octaves works correctly. For instance this one
>
> \version "2.21.0"
> {
> \acciaccatura cis8 d'1
> \acciaccatura cis8 d'1
> }
>
> ...works without generating errors. Any help?
> Apologies if I'm missing something obvious!
>
> Thank you, g.
Re: Set a temporary tempo change
On 2019-11-18 6:24 am, David Kastrup wrote:
Aaron Hill writes:
Not sure if this is really the right way to do things:
It isn't. It maintains the "stack" in a global variable rather than
some context property, meaning that when several iterations interlock
(like with tempo being changed in several contexts or in polyrhythmic
situations), chaos will ensue.
Ah... you're no fun. To misquote Willy Wonka, "A little [chaos] now and
then is relished by the wisest men." (:
But seriously, I was imagining only the simplest use case. So, here's
yet again another take:
\version "2.19.83"
#(begin
(set-object-property! 'tempoStack 'translation-type? list?)
(set-object-property! 'tempoStack 'translation-doc
"A stack to keep track of previous tempi.")
(set! all-translation-properties
(cons 'tempoStack all-translation-properties)))
pushTempo = #(define-music-function () ()
(define (pushTempoHelper ctx)
(let ((tempoStack (ly:context-property ctx 'tempoStack '()))
(tempo (ly:context-property ctx 'tempoWholesPerMinute #f)))
(set! tempoStack (cons tempo tempoStack))
(ly:context-set-property! ctx 'tempoStack tempoStack)))
#{ \context Score \applyContext $pushTempoHelper #})
popTempo = #(define-music-function () ()
(define (popTempoHelper ctx)
(let ((tempoStack (ly:context-property ctx 'tempoStack '(
(if (null? tempoStack)
(ly:input-warning (*location*)
"Unable to pop a tempo. Did you forget to \\pushTempo?")
(let ((tempo (car tempoStack)))
(set! tempoStack (cdr tempoStack))
(ly:context-set-property! ctx 'tempoStack tempoStack)
(if tempo
(ly:context-set-property! ctx 'tempoWholesPerMinute tempo)
(ly:context-unset-property ctx 'tempoWholesPerMinute))
#{ \context Score \applyContext $popTempoHelper #})
\score {
{
\markLengthOn
\tempo "I. Default"
{ b'4 4 4 4 } \bar "||"
\pushTempo \tempo "II. Andante" 4=90
{ b'4 4 4 4 } \bar "||"
\pushTempo \tempo "III. Allegro" 4=140
{ b'4 4 4 4 } \bar "||"
\popTempo \tempo "Tempo II"
{ b'4 4 4 4 } \bar "||"
\popTempo \tempo "Tempo I"
{ b'4 4 4 4 } \bar "||"
\popTempo \tempo "Tempo 0?!"
{ b'4 4 4 4 } \bar "|."
}
\layout {} \midi {}
}
I tried to follow the pattern in define-context-properties.scm, but
there is no documentation in LM, NR, Extending nor Internals on this
topic. David, would you kindly let me know if I am overlooking
something?
-- Aaron Hill
Re: Set a temporary tempo change
Aaron Hill writes:
> On 2019-11-17 12:38 pm, Paolo Prete wrote:
>> Hello,
>> is it possible to revert a tempo change to the previous tempo setting,
>> without explicitly writing this previous one?
>> Something like (pseudo-code):
>> \tempo 4 = 120 { ...some music } \temporaryTempo 4 = 160 { ...
>> some other music } \unset \temporaryTempo
>
> Not sure if this is really the right way to do things:
It isn't. It maintains the "stack" in a global variable rather than
some context property, meaning that when several iterations interlock
(like with tempo being changed in several contexts or in polyrhythmic
situations), chaos will ensue.
>
>
> \version "2.19.83"
>
> #(define tempoStack '())
> pushTempo = #(define-music-function () ()
> (define (pushTempoHelper ctx)
> (let ((tempo (ly:context-property ctx 'tempoWholesPerMinute #f)))
> (set! tempoStack (cons tempo tempoStack
> #{ \context Score \applyContext $pushTempoHelper #})
> popTempo = #(define-music-function () ()
> (define (popTempoHelper ctx)
> (let ((tempo (car tempoStack)))
> (ly:context-set-property! ctx 'tempoWholesPerMinute tempo)
> (set! tempoStack (cdr tempoStack
> #{ \context Score \applyContext $popTempoHelper #})
>
> \score {
> {
> \markLengthOn
> \bar "||" \tempo "Andante" 4=90
> \repeat unfold 2 { b'4 4 4 4 }
> \bar "||" \pushTempo \tempo "Allegro" 4=140
> \repeat unfold 2 { b'4 4 4 4 }
> \bar "||" \popTempo \tempo "a tempo"
> \repeat unfold 2 { b'4 4 4 4 }
> }
> \layout {} \midi {}
> }
>
>
>
> -- Aaron Hill
>
>
--
David Kastrup
acciaccatura & mis-predicted
I'm sure this is a trivial issue but I need help to understand why this
code...
\version "2.21.0"
{
\acciaccatura cis'8 d'1
\acciaccatura cis'8 d'1
}
... generates this log:
[]
programming error: mis-predicted force, 108.120472 ~= 108.620856
continuing, cross fingers
programming error: mis-predicted force, 108.120472 ~= 108.620856
continuing, cross fingers
[]
The same code in lower octaves works correctly. For instance this one
\version "2.21.0"
{
\acciaccatura cis8 d'1
\acciaccatura cis8 d'1
}
...works without generating errors. Any help?
Apologies if I'm missing something obvious!
Thank you, g.
Re: Set a temporary tempo change
On 18/11/19 01:51, Paolo Prete wrote: > Aaron, > > that's great. > I propose to the ML to add the function to the official release. It's > very helpful when you want to make the midi output more realistic, with > frequent tempo changes A lot of music I play has "tempo primo". Personally I don't care about midi, but this stack mechanism seems almost perfect for implementing that, too ... Cheers, Wol
