Re: fingering and midi
Thomas Morley writes:
> Nevertheless some observations/thoughts:
> (1)
> deleting FingeringEvent from this list makes the initial reported code
> work as expected
> (2)
> obviously StringNumberEvents and StrokeFingerEvent are not even
> mentioned, why? What makes them different?
Can't historically be on chords (they'd get ignored).
> (3)
> has it something to do with the known mess of Fingering_engraver and
> New_fingering_engraver.
> (4)
> has it something to do with stopping wrapping all in event-chords?
> Because fingering can occur in the 'articulations of a note-event and
> in the elements of an event-chord? See:
> { \displayMusic -2 }
articulate is from before Issue 2240 time and is written that way. It
has been "adapted" by calling event-chord-wrap! and thus does its job
using pre-2240 expression handling (rhythmic events are always in an
EventChord).
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: fingering and midi
2017-10-02 23:08 GMT+02:00 Heikki Tauriainen :
> On Mon, 2017-10-02 at 14:55 +0200, David Kastrup wrote:
>>
>> Looks like a bug in the implementation of
>> commit 327fc82bafec17c249b78b8be19a71ff83b0a32c
>
> No, this looks like an even older bug since the result is the same even
> without this particular change.
>
> From a quick glance at the script's ac:getActions function it looks
> like that the shortening factor which the script will determine for
> each note (by looking at a list of events) could end up being 1:1 if
> the list of events includes any FingeringEvents (which are only one
> among multiple kinds of events with similar behavior), depending on the
> order of the events in the list. This could also explain why the
> output changes when changing the order of the events in the input.
>
> The handling of FingeringEvents appears to been this way since
>
> commit d4c5b03afa8384ee50a7b9536485bc26d14033aa
> Author: Peter Chubb
> Date: Mon May 2 13:52:03 2011 +0100
>
> Eliminate faulty barcheck warning in articulate.
>
> --
> Heikki Tauriainen
Yep, so far my own findings are the same.
I'd be interested why it was changed this way. Couldn't find anything
on the tracker or in the archives, though.
Any link would be nice...
Nevertheless some observations/thoughts:
(1)
deleting FingeringEvent from this list makes the initial reported code
work as expected
(2)
obviously StringNumberEvents and StrokeFingerEvent are not even
mentioned, why? What makes them different?
(3)
has it something to do with the known mess of Fingering_engraver and
New_fingering_engraver.
(4)
has it something to do with stopping wrapping all in event-chords?
Because fingering can occur in the 'articulations of a note-event and
in the elements of an event-chord? See:
{ \displayMusic -2 }
Cheers,
Harm
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: fingering and midi
On Mon, 2017-10-02 at 14:55 +0200, David Kastrup wrote: > > Looks like a bug in the implementation of > commit 327fc82bafec17c249b78b8be19a71ff83b0a32c No, this looks like an even older bug since the result is the same even without this particular change. >From a quick glance at the script's ac:getActions function it looks like that the shortening factor which the script will determine for each note (by looking at a list of events) could end up being 1:1 if the list of events includes any FingeringEvents (which are only one among multiple kinds of events with similar behavior), depending on the order of the events in the list. This could also explain why the output changes when changing the order of the events in the input. The handling of FingeringEvents appears to been this way since commit d4c5b03afa8384ee50a7b9536485bc26d14033aa Author: Peter Chubb Date: Mon May 2 13:52:03 2011 +0100 Eliminate faulty barcheck warning in articulate. -- Heikki Tauriainen ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: DOC: Correcting spelling of Harmonia Sacra in NR 1.1.4 Shape note heads
Hello, On Sat, 30 Sep 2017 17:14:02 -0500, Karlin High wrote: > This is a nitpick. The places in the documentation that reference the > "Harmonia Sacra" songbook by Joseph Funk have the spelling Harmonica > Sacra. Harmonia does not have a "c" here. A few references are below. > There are enough of them that a Google search for "Joseph Funk > Harmonica Sacra" gets auto-corrected. > > http://harmoniasacra.org/index.html > http://gameo.org/index.php?title=Harmonia_Sacra > https://www.amazon.com/Harmonia-Sacra-Joseph-Funk/dp/1932676155 > > The attached patch has proposed corrections. Translated docs would be > affected; I do not know the process for that. Possible actions: > > * Forget it. Anyone who would be bothered by this is probably beyond help. > * Fix directly in git like other typos > * Go through review and tracker like other patches > -- > Karlin High > Missouri, USA If in doubt ' * Go through review and tracker like other patches'. Thanks. https://sourceforge.net/p/testlilyissues/issues/5209/ has now been created for this. James ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: fingering and midi
Thank you Ben and David for the help and the information.
g.
On 2 October 2017 at 14:55, David Kastrup wrote:
> Ben writes:
>
> > On 10/2/2017 6:17 AM, Gianmaria Lari wrote:
> >> This code works as expected...
> >>
> >> The following code is pretty the same except I added the fingering
> >> to the notes...
> >>
> >> \version "2.19.65"
> >> \score {
> >> \articulate
> >> \fixed c'' { d^.-1 c^.-1 d^.-1 c^.-1} %with fingering
> >> \layout {}
> >> \midi { }
> >> }
> >>
> >>
> >> but the generated codes is no more 'staccato'.
> >>
> >> Is this normal?
> >> Best regards, g.
> >>
> >
> > Hello,
> >
> > If you reverse the order of fingering / articulation, it works just
> > fine on my end.
>
> Looks like a bug in the implementation of
> commit 327fc82bafec17c249b78b8be19a71ff83b0a32c
> Author: Heikki Tauriainen
> Date: Sat Aug 8 09:22:42 2015 +0300
>
> articulate.ly: update documentation, add support for portato
>
> This changeset updates the articulate.ly script documentation on the
> supported
> articulations with a description of ac:staccatissimoFactor, and adds
> ac:portatoFactor for shortening notes marked \portato, and slurred
> notes marked
> \staccato. The default value for ac:portatoFactor is 3/4 (to match the
> current default shortening factor for notes marked \portato when not
> using
> articulate.ly).
>
> Don't see an obvious candidate for the problem immediately.
>
> --
> David Kastrup
>
> ___
> lilypond-user mailing list
> lilypond-u...@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: fingering and midi
Ben writes:
> On 10/2/2017 6:17 AM, Gianmaria Lari wrote:
>> This code works as expected...
>>
>> The following code is pretty the same except I added the fingering
>> to the notes...
>>
>> \version "2.19.65"
>> \score {
>> \articulate
>> \fixed c'' { d^.-1 c^.-1 d^.-1 c^.-1} %with fingering
>> \layout {}
>> \midi { }
>> }
>>
>>
>> but the generated codes is no more 'staccato'.
>>
>> Is this normal?
>> Best regards, g.
>>
>
> Hello,
>
> If you reverse the order of fingering / articulation, it works just
> fine on my end.
Looks like a bug in the implementation of
commit 327fc82bafec17c249b78b8be19a71ff83b0a32c
Author: Heikki Tauriainen
Date: Sat Aug 8 09:22:42 2015 +0300
articulate.ly: update documentation, add support for portato
This changeset updates the articulate.ly script documentation on the
supported
articulations with a description of ac:staccatissimoFactor, and adds
ac:portatoFactor for shortening notes marked \portato, and slurred notes
marked
\staccato. The default value for ac:portatoFactor is 3/4 (to match the
current default shortening factor for notes marked \portato when not using
articulate.ly).
Don't see an obvious candidate for the problem immediately.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
