lilypond-auto
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lilypond-auto] Issue 3878 in lilypond: MIDI lyrics start at 0 even


From: lilypond
Subject: Re: [Lilypond-auto] Issue 3878 in lilypond: MIDI lyrics start at 0 even when music doesn't
Date: Mon, 24 Mar 2014 08:26:15 +0000


Comment #25 on issue 3878 by address@hidden: MIDI lyrics start at 0 even when music doesn't
http://code.google.com/p/lilypond/issues/detail?id=3878

Regarding comment #23: after rereading the code, I tend to agree. There are a few things I can think of worth double-checking: a) if the beginning does not evaluate to an exact time tick, can rounding etc lead to a situation where we still generate material before start_tick? b) if there is a basically content-less Staff, does it not mess up the start-time calculation?
c) does this work with skipTypeSetting and its ilk?

Regarding midiOffset: it is an additional feature that pins down the Midi start time: no second-guessing or fiddling to make things match. That's not just "saving a little effort", it is creating a well-defined Midi timing instead of an implicit one. That's important for synchronizing Midi in any manner with different material.

I don't see that it makes for complexity, either: if it is set, the starting tick calculation just takes that value. As I said: that is an independent issue and can be done independently (and the name "midiOffset" is not appealing to me as well, particularly not so if we otherwise may have a non-zero value automatically. Perhaps "midiStart"?). The point of that is that we have a "good and convenient" default and an "exact and predictable but pedantic" override. Since we don't get to have both at the same time, having the latter as an option sounds reasonable to me.

Even though countdowns/etc should allow this issue for making it into master before the next unstable release, I lean towards committing the revert first and then base the patch (basically #1 apart from not including the revert) towards the result: the implementation is basically independent from the previous faulty one.

Ok?

--
You received this message because this project is configured to send all issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings



reply via email to

[Prev in Thread] Current Thread [Next in Thread]