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: Missing NR documentation for customizing the behavior of articulations in MIDI
On Saturday, 2016-07-09 at 12:38 +0100, James Lowe wrote: > > The changes.tely commit is here > > http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=d92 > 22eec25ca8143e7e84a5af61aaa98acec5e6a > > and, I suspect that Devon Schudy (the author of the edit) was > reflecting > his changes he made in this commit: > > http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=a42 > a4f9c507f42456b3ac361788397881b86b1a0 > > which does contain 'midi-extra-velocity' in the diffs (I am not > programmer BTW), so I expect this is what the changes.tely reflects > here. Thanks, I knew about the origin of these changes (this was actually one of the side issues that I had noticed during the review of your clean- up work of the MIDI documentation last year). > I guess Devon, his good self, would know the answer to this. Yes, I agree that the author would probably be the most qualified person to answer questions about the feature, however I'm not sure whether he's currently active in LilyPond development. Since I've not very familiar with this feature myself, I only decided to (finally, cleaning up my list of unreported issues...) report this issue about missing documentation to just have it in the public record. Thanks, -- Heikki Tauriainen ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Doc: Missing NR documentation for customizing the behavior of articulations in MIDI
Hi, The post-2.18 changes to the default handling of articulations in MIDI (without using articulate.ly) are currently mentioned only near the bottom of the Changes document. The options available for customizing the behavior deserve (in my opinion) a place in the NR so that the documentation remains discoverable and does not get lost when the Changes document is eventually replaced with a new version. I have also the following questions about the current information in the Changes document to which I don't know the answers myself. * Are the names of the new properties (midiLength and midiExtraVelocity) which control the behavior of articulations correct in the Changes document? Searching the files in the source tree for either of these strings produces no hits outside the Changes document; the definitions of the articulations in ly/script-init.ly (mentioned in the Changes document as a source for examples) use the names midi-length and midi-extra-velocity instead. The naming of the properties should be made consistent between the implementation and the documentation. * In the Changes document it is stated that "[the] behavior is customizable through [...] properties of ArticulationEvent". I'm wondering whether this is supposed to mean that the properties can be controlled from within LilyPond input using \override and \revert, \set, or some other syntax - if so, an example about this syntax would be very useful. The only way that I've found to work to customize the behavior is to use the make-articulation function (as in ly/script-init.ly), which will change the behavior of all notes with a given articulation. However, adjusting, for example, the "extra velocity" of just single articulated notes could be interesting, for example, to add variety to the MIDI output. (This can of course be simulated by defining new articulations and using them, but I'm wondering whether this could be achieved by temporarily adjusting the properties of the default articulations.) -- Heikki Tauriainen ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Documentation missing for extra \header fields available for customizing PDF metadata
On Sat, 2015-08-08 at 15:59 +0600, Henning Hraban Ramm wrote: > > There’s also a list of header fields that are used by the Mutopia > project, see http://www.mutopiaproject.org/contribute.html#update > An updated documentation could point at that, too. > > And maybe there are other projects/processors that use some fields? > > (Thanks again for working on „my“ MIDI title itch! I owe you > something.) No problem – this has also been a small personal itch of mine for some time, your request just encouraged me to finally try to do something about it. Don't hold your breath yet, though, as I'm still not certain whether the patch will pass the scrutiny of the core developers... -- Heikki Tauriainen ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Documentation missing for extra \header fields available for customizing PDF metadata
Hi,
While examining the source code on how \header blocks are used to
extract information for PDF metadata (to implement the enhancement
#4539), I discovered that LilyPond actually supports quite an extensive
(optional) mechanism for customizing PDF metadata independently of the
information usually specified in the fields (title, subtitle, composer
etc.) of a \header block, through the use of extra \header fields.
However, I can't find any mention of this customization mechanism, nor
examples of using any of the extra fields, in any of the current
(v2.19.24) manuals. (The most relevant piece of documentation about
the supported \header fields that I could find is the "Default layout
of bookpart and score titles" example in Section 3.2.1 of the Notation
Reference (v2.19.24) – this example claims to list "all" of the
available fields.)
I'd consider documenting the extra fields which can be used to
customize the metadata specifically for PDF files a useful addition to
the manuals. Knowledge about the possibility of customizing the
metadata could be useful in the case where the fields of a \header
block contain complex LilyPond markup code, which doesn't translate
into plain text form in a "satisfactory" way automatically.
In short, the implementation appears to support a number of extra
\header fields which can be used (if defined in a \header block) to
override the values of the fields listed in the documentation
specifically for PDF output. For example, the "pdftitle" \header field
appears to be available for specifying a title for the PDF metadata
independently of the value of the "title" field (which is normally used
to generate a title for the PDF metadata if there's no "pdftitle"
override present), for example, as
\header {
title = "Title"
pdftitle = "PDF Title"
}
(The title from the PDF metadata may be shown in a special way to the
user by the PDF viewer application: for example, evince 3.16.1 will use
the PDF title as the primary window title.)
Quick experimenting suggests that the value for "pdftitle" appears to
be first sought from a \book header, and then from a top-level \header,
although I didn't try to cover all the possible cases of nesting
various \header blocks. (Overriding the "pdftitle" field in \bookpart
or \score headers doesn't seem to have any effect, which seems
reasonable since book parts and scores don't map into separate PDF
files.)
The full list of fields which appear to be supported for customizing
PDF metadata is defined in the "handle-metadata" function in
scm/framework-ps.scm as lines of the form
(metadata-lookup-output 'pdftitle 'title "Title")
where the first argument to "metadata-lookup-output" looks like the
\header field name that can be used to customize the value of the
\header field given in the second argument specifically for PDF output.
As I've modeled the \header field queries for enhancement #4539 (
https://code.google.com/p/lilypond/issues/detail?id=4539), albeit in a
reduced form, after the functionality which was already available for
PDF output, #4539 (if it gets accepted) will add a new extra \header
field "midititle" which can be used to override the name of a MIDI
sequence (which will, similar to PDF output, get its name from the
"title" field after #4539 if no override is present) for MIDI output.
The "midititle" override will have significance in \header blocks down
to the "score" level because each score with a \midi block will produce
a separate MIDI file.
Regards,
Heikki Tauriainen
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Documentation for issues 3601 (based on 3581), 4042 (NR: "MIDI output", Section 3.5)
Hi,
In response to
<http://lists.gnu.org/archive/html/lilypond-devel/2014-08/msg00060.html>,
here's some new documentation for Section 3.5 ("MIDI output") of the
Notation Reference (v2.19.11). The main goal of the proposed additions
is to describe the MIDI context properties implemented in issues 3581
(with issue 3601 about the missing documentation) and 4042. (I'm the
author of the code patches in those issues.)
To support this goal, I'll also propose changes to some existing
sections of the documentation: these changes include an attempt to (at
least partially) document the Score.midiChannelMapping context property,
and an expanded description of MIDI channels.
The changes proposed (in plain text) to the documentation are
interleaved with my comments and questions. If it'd be more useful to
format the actual changes in some other way, please tell me what I need
to do. (I'm already sorry about any procedural mistakes I've probably
made here because the changes likely already qualify as "larger
contributions" mentioned in the Contributor's guide, however from the
previous discussion I understood that it would still be OK to just send
these suggestions to the bug list. This is the first time I've ever
proposed any changes to the documentation...)
Best regards,
Heikki Tauriainen
==
Based on my understanding of the LilyPond implementation, the fourth
paragraph in Section 3.5 "MIDI output" ("The MIDI output allocates a
channel...") is not strictly accurate as the allocation of MIDI channels
depends on the value of the Score.midiChannelMapping context property:
using a separate channel for each staff is only the default setting.
As the MIDI section of the Notation Reference doesn't currently mention
the Score.midiChannelMapping context property (it is listed only in
Appendix A.17), which nevertheless plays a part in the allocation of
MIDI channels for MIDI output, I propose the following changes to the
documentation:
1.
Expand the fourth paragraph of Section 3.5 into a separate
subsection about MIDI channels, and move it between sections 3.5.1
("Creating MIDI files") and 3.5.2 ("MIDI Instruments").
(Why place it after 3.5.1:) Section 3.5.1 gives all the
information that is needed for generating MIDI files,
allowing users to already start experimenting with MIDI
without going (yet) into any technical details about the
structure of MIDI files in the documentation.
(Why place it before 3.5.2:) The MIDI channel mapping
affects the behavior of all MIDI related context
properties (probably most importantly, the MIDI
instrument). Assuming a basic understanding of the MIDI
channel mappings before describing any of the MIDI related
context properties will help in documenting them in a more
concise way.
Of course, these are just suggestions; feel free to ignore, edit, or
move around any of the proposed changes.
2.
Move also the "Changing MIDI output to one channel per voice" in the
snippet of the current section 3.5.1 to the new subsection.
Proposed text for the new subsection:
BEGIN DOCUMENTATION
3.5.x MIDI channels
When generating a MIDI file from a score, LilyPond will automatically
assign every note in the score a MIDI channel on which it should be
played on a MIDI device. A MIDI channel has a number of controls
available to select, for example, the instrument used to play the notes
on that channel, or request the MIDI device to apply various effects to
the sound produced on the channel. At all times, every control on a
MIDI channel can have only a single value assigned to it (which can be
modified, however, for example, to switch to another instrument in the
middle of a score). This section describes how LilyPond maps notes to
MIDI channels, and the options available to change the default behavior.
By default, LilyPond will try to reserve a separate MIDI channel for
every staff defined in a score: in other words, all notes in the voices
contained within the staff will share the same MIDI channel. However,
because the MIDI standard supports only 16 channels per a MIDI device
(where one of the channels is reserved for drums - see Section
"Percussion in MIDI" for more information), this limit for the number of
channels limits also the number of notes which can be played, for
example, using different instruments at the same time. Trying to use
too many MIDI channels will result in some of the existing channels
being reused, which may lead to output that does not match the
expectations.
To work around the limitation in the maximum possible number of MIDI
channels, LilyPond supports a number of different modes for MIDI channel
allocation, selected using the Score.midiChannelMapping context
property. This context property can be assigned one of the following
values:
