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
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
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
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
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!
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,
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
>
>
> 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
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
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
Thank you Jacques and Harm for your help. I will try to use the previous
version.
Best regards g.
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 .
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,
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:
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
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.
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.
>
>
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,
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
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...
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
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
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
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
24 matches
Mail list logo
