Re: Doc: Add a section about handling MIDI dynamics with multiple voices (issue 302930043 by ht.lilypond.developm...@gmail.com)
On 2016/07/11 16:39:01, Carl wrote: I think the current behavior of changing dynamics in identically-named but distinct voices is flawed, so I think it should be a known issue, not in the main documentation. I agree that bugs should not be documented as the rules about the behavior. However, can it be definitely said in this case whether this is actually a bug? Without any specification available to compare the implementation with, the answer to this question could differ between people, each of whom has their own expectations about how they'd like things to work. For example, I'd say that the initialization of a new Dynamic_performer at the start of every new Voice, which implicitly "resets" the MIDI volume level to the default level, could equally well be considered a bug (from the point of view of a *user* who'd prefer worrying as little as possible about how contexts internally work) simply because this makes it so much more difficult to write single-staff polyphony which would produce MIDI output "matching" the typeset output, even though the behavior makes perfect sense from an implementation point of view. (It is probably apparent at this point that this is the viewpoint that I had in mind when I decided to write the patch to the documentation.) It could even be argued that sharing dynamics between identically named Voices provides a workaround for this user problem, since by using identically named Voices the shared dynamics do not need to be duplicated in each separate Voice in the LilyPond input. However, you could well be right that this sharing of dynamics between identically named voices currently works only by accident (since the initialization of a new Voice will still reset the dynamic level), just like moving Dynamic_performer to the Staff context to make Voices within the Staff share their dynamics works only for Voices without an explicit name. I suspect all of this behavior is due to the Staff_performer logic, which tries to distribute notes and dynamics into separate classes by the names of their associated Voices - maybe this should be done using some other criterion (such as an internal Voice ID, unique to each Voice instance). I think that it's useful to know what the default value is. But I also think we should have a comment that indicates it is defined in scm/midi.scm It would probably also be useful to give the name of the variable that holds the default value, because the user can specify any desired default value by changing the variable. As Dan already commented, the default value is hard-coded in the C++ code - it doesn't come from any Scheme-level definition. I fully agree that instead of using a hard-coded default value which does not match any of those defined in scm/midi.scm, the Dynamic_performer implementation should simply be changed to query for the default value from the default absolute volume map using one of the keys defined in scm/midi.scm (and I agree that "mf" is probably a reasonable choice). I think that the behavior indicated in your example should be documented as a Known Issue, which means we recognize it as a bug. And we should have an issue as well (MIDI volume levels leak between identically named voices). So just to confirm, in your opinion the rule about how dynamics are (or are not) shared between voices are better described just as a known issue? I guess it will then make sense to also simplify the example as well to no longer demonstrate this corner case. https://codereview.appspot.com/302930043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: additional entry in lilypond.org/productions.html?
Am 10.07.2016 um 19:11 schrieb Federico Bruni: Il giorno ven 8 lug 2016 alle 12:36, Marc Hohl ha scritto: I have written some musicals for children and adolescents in the past and have two more musicals in the pipeline, to be released at the end of 2016. The sheets are done with LilyPond and LaTeX and available for free, but the musicals are only available in German language. You can see my work at http://www.singspielschmiede.de All musicals were shown on stage at the local music school where I work. I don't know whether this stuff is good/suitable enough to get mentioned on the Productions site under lilypond.org. What do you think? I think that it should be definitely added. Thank you! Is the LilyPond source available and hosted somewhere? Of course one can get the LP source from me, but it is not hosted anywhere. The same holds for the sheets. There are excepts free for download, and if anyone is interested, he or she can contact me to get a link to the full stuff. I decided to use this "strategy" to get in touch with the potential users and to see how much people are interested in my projects. The Productions page has now a long column of concerts on the left and a short column of published sheet music on the right. I think that "published" in this case means just publicly available? I mean, Mutopia is not a publishing company. Yes, probably ... So I would add links to Lilypond source projects, like: https://github.com/nsceaux/nenuvar and others... +1 Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: additional entry in lilypond.org/productions.html?
Am 12.07.2016 um 10:00 schrieb Marc Hohl: >> The Productions page has now a long column of concerts on the left and a >> short column of published sheet music on the right. I think that >> "published" in this case means just publicly available? I mean, Mutopia >> is not a publishing company. > > Yes, probably ... > "Published" also means "freely available", possibly together with the sources. Commercial and/or closed source editions are not eligible to be listed there. [Note that this does *not* express any opinion on my behalf, it's just the official policy] Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Add a section about handling MIDI dynamics with multiple voices (issue 302930043 by ht.lilypond.developm...@gmail.com)
> I suspect all of this behavior is due to the Staff_performer logic, > which tries to distribute notes and dynamics into separate classes by > the names of their associated Voices - maybe this should be done using > some other criterion (such as an internal Voice ID, unique to each Voice > instance). As I mentioned, I already have a private branch that removes the mess from Staff_performer and lets Dynamic_performer link notes to their dynamic. I haven’t tested it with your example, but I expect it to work more sensibly. Dynamics shouldn’t affect notes outside of the dynamic performer’s context. > implementation should simply be changed to query for the default value > from the default absolute volume map using one of the keys defined in > scm/midi.scm (and I agree that "mf" is probably a reasonable choice). If this plan is accepted, you could conscientiously document “mf” as the default now. I volunteer to make the change. If someone would create a ticket and assign it to me, it would help me remember. — Dan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 4048: Improve crescendo performance with unspecified dynamics (issue 302910043 by nine.fierce.ball...@gmail.com)
In short: LGTM. The rest of this comment is just continuing discussion on some of the points in your previous response. On 2016/07/12 05:01:16, Dan Eble wrote: > What are the main user-level justifications for increasing the > complexity of the Dynamic_performer It also improves an example I saw elsewhere recently (I don't remember where, but I think it was yours), something like mf < ... < ... < ... < ... f. The volume no longer saturates early. Sorry about this, that example was not really meant as something that I suggested as a problem that I'd wish to have fixed (the example was only there to show how a previous patch of yours to "add \!'s" to all dynamic span boundaries already improved the behavior from what it used to be) - and the new behavior is even better since it avoids saturating the volume altogether. The regression tests show no differences. I wasn't thinking about regression tests here, but rather about the existing input files that a user might have that could start behaving differently from what they used to (for example, that the volume level at the end of a sequence of crescendos followed by a sequence of descrendos, all with unspecified volumes, will now always return to the starting level regardless of the number of crescendo and descrendo spans). I'm not arguing for or against any particular heuristic of handling unspecified (de)crescendos, only that any changes in behavior might be seen differently by different users, and whatever heuristics there are should preferably be documented in a detailed enough level so that the intended behavior becomes clear. I'm of course speaking strictly from the mindset of a (likely a very small group of) users who have (due to the lack of reference documentation) gone through the trouble of trying to learn the rules about how LilyPond handles MIDI dynamics by studying the source code. While such users might be annoyed about the changes in the rules if there's nothing mentioned about the changes anywhere, they have only themselves to blame for relying on undocumented behavior in the first place... So I believe you can safely ignore my concerns about missing user-level documentation about the changes - I don't think there will be any users that are going to complain about the changes. Well, the level of detail in the documentation should depend on the use case for MIDI output. True - however, I'm not certain whether there's any clear consensus among the user/developer base about what the use case for LilyPond's MIDI output actually is, besides the obvious thing that in practice the MIDI backend is considered to be of secondary importance to the majority of people (at least to the core developers - since v2.14, which introduced the "velocity as MIDI volume" interpretation of volume, I think that the fixes and enhancements to the MIDI code have mostly come from outside developers). I've been told very clearly that "It can serve as a proofhearing aid or a practice aid. It is not intended to serve as a substitute for a player when recording. For that, LilyPond produces sheet music fit for running through a human" (http://lists.gnu.org/archive/html/lilypond-devel/2013-11/msg00194.html). I think this is just the personal opinion of one of the core developers. I can only symphathize with your sentiments in that discussion. In my opinion, if the above really were the only accepted use case for MIDI output, then I'm baffled about why the developers of the MIDI backend ever bothered with handling MIDI dynamics in the first place, and why, for example, the articulate.ly script (even though it was made by an outside developer) got accepted into the official releases. Funnily enough, had LilyPond not had any support for MIDI dynamics when I started using it, I'd probably have never got involved with LilyPond development at all myself, to try to work around or fix bugs where the MIDI output backend "tried too much (performance-wise)" and failed. I don't think that these minor changes to MIDI output in cases where the user didn't care enough to specify a dynamic are much to brag about. I think that removing the internal programming errors in MIDI dynamic handling is a good thing since these errors could have been a source of user confusion. Maybe this would be still worth mentioning? https://codereview.appspot.com/302910043/diff/40001/lily/dynamic-performer.cc#newcode101 lily/dynamic-performer.cc:101: Real max_target_vol) Assuming that context properties do not change in the course of the performance does not seem very lilypondish. It is true that I have not tried to handle the possibility rigorously, but I thought it better to write this interface this way. It's small potatoes compared to the rest. OK, this was just a thought (possibly raised since the equalizer settings remaining the same was mentioned in the code comments, so I began to wonder how strongly this is actually assumed throughout the implementation - in the c